robatwilliams/awesome-webhid

Curated list of resources relating to the WebHID (Human Interface Device) API

awesome-webhid's Issues

Comply with "The awesome manifesto"

https://github.com/sindresorhus/awesome/blob/master/awesome.md

• Only awesome is awesome
• Awesome badge
• Comment on why something is awesome
• Make it clear what the list is about
• Pay attention to grammar
• Choose an appropriate license
• Include contribution guidelines
• Stylize your list properly

Add various links from recent browser history

Search for usb, hid, bluetooth, keyboard

Only those that are awesome.

Comply with "sindresorhus/awesome" requirements

https://github.com/sindresorhus/awesome/blob/master/pull_request_template.md

• Has been around for at least 30 days.
  That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
• It's the result of hard work and the best I could possibly produce.
• Non-generated Markdown file in a GitHub repo.
• Includes a succinct description of the project/theme at the top of the readme. (Example)
• The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
• Not a duplicate.
• Only has awesome items. Awesome lists are curations of the best, not everything.
• Includes a project logo/illustration whenever possible.
  • Either centered, fullwidth, or placed at the top-right of the readme. (Example)
  • The image should link to the project website or any relevant website.
  • The image should be high-DPI. Set it to maximum half the width of the original image.
• Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
• Includes the Awesome badge.
  • Should be placed on the right side of the readme heading.
    • Can be placed centered if the list has a centered graphics header.
  • Should link back to this list.
• Has a Table of Contents section.
  • Should be named Contents, not Table of Contents.
  • Should be the first section in the list.
  • Should only have one level of nested lists, preferably none.
• Has an appropriate license.
  • That means something like CC0, not a code licence like MIT, BSD, Apache, etc.
  • WTFPL and Unlicense are not acceptable licenses.
  • If you use a license badge, it should be SVG, not PNG.
• Has contribution guidelines.
  • The file should be named contributing.md. Casing is up to you.
• Has consistent formatting and proper spelling/grammar.
  • The link and description are separated by a dash.
    Example: - [AVA](…) - JavaScript test runner.
  • The description starts with an uppercase character and ends with a period.
  • Consistent and correct naming. For example, Node.js, not NodeJS or node.js.
• Doesn't include a Travis badge.
  You can still use Travis for list linting, but the badge has no value in the readme.

My device is not visible for webHid, but works fine with node-hid

Hi,
Like in title: hid.requestDevice({filters: [{ }]}) display only my mouse and keyboard in prompt for selection device, but usb.requestDevice show it well. Also node-hid detect it and works fine with my device.

My device (UPS):
Bus 003 Device 007: ID 0001:0000 Fry's Electronics MEC0003

Cheers Patryk

Simulating an HID device

Weird question, weird place to be.

I want to create a virtual HID device within the Chrome browser, to simulate HID events and receive them in the page.

Use case:
I'm building a controller on a browser on a mobile phone which will send gamepad-like inputs to the host browser.

How can I "understand" inputs from my phone controller and "simulate" actual gamepad inputs on the browser?

Question on connect/disconnect events

Hi,

as you have quit a bit of knowledge on WebHID, you could maybe answer my question.

O'm currently working on a Single Page App utilizing WebHID to interact with a custom device. Everything works well, so far (see BLExy videos on youtube for reference).

What I don't get to work are the disconnect events on navigator.hid, which is an issue, as I'm not able to recognize removal of the USB device and sending reports simply fails (HIDDevice instance is left behind with open property set to true).

I'm using latest Chrome 78 in Linux x64.

I hope you could drop a hint on how to detect device disconnection.

Cheers Marcus

Submit to the master list of awesome lists

Wait at least 30 days after creating a list before submitting it, to give it a chance to mature.

Needs to comply with list guidelines first (#2)

Candidate devices: various gamepads

https://bugs.chromium.org/p/chromium/issues/detail?id=890096#c6

• Dualshock 3 connected over USB
• Dualshock 4 connected over USB
• Xbox Wireless Controller connected over Bluetooth
• Nintendo Switch Pro connected over USB

Add introduction and key points

See spec & explainer from WICG. Short intro, don't explain the whole thing.

• why it's different from WebUSB, Web Bluetooth
• it's an abstraction (events, input/output/feature reports) over lower-level read/write APIs, usage pages
• protected usages - keyboard, ...
• WebBluetoothCG/web-bluetooth#393

Anything else from discussions?

• https://discourse.wicg.io/t/human-interface-device-hid-api/3070
• https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/OaDCpCaEe_4/3taK3m75DAAJ

Limitations on Windows platform?

• https://developers.google.com/web/fundamentals/native-hardware/build-for-webusb/
• WICG/webusb#143