sendReport() fails with DOMException

[ciriousjoker]

It says DOMException: Failed to write the report.
However, I am connected to the device (it keeps sending ordered numbers every 300ms).

The exception also has a name: "NotAllowedError".
What am I supposed to do with that?? I am the administrator, I enabled webhid and I'm running Chrome Dev. What else am I supposed to do?

[ciriousjoker]

This occurs with any device, for example my Logitech MX Master 2S. I receive its HID commands for the button gestures, sidescrolling etc., but I can't send anything.

[ciriousjoker]

I'm currently reading this post:
https://discourse.wicg.io/t/human-interface-device-hid-api/3070/3

And this guy states that "HID access to devices that generate trusted input events" is blocked. Back in my test case, that probably means that I can't access keyboards & mouses?

I can't read any keystrokes from my Ducky keyboard (for both devices in the device chooser) and I also don't get mouse data aside from sidescrolling and the extra buttons (no left/right click or scrollwheel scrolling).

[inexorabletash]

The author of that Discourse post is the writer of this proposal and implementer in Chrome, and so is authoritative. The behavior you're observing is as expected.

[ciriousjoker]

Here's my device:

Now it isn't classified as a Keyboard/Mouse anymore, but sendReport() still fails. It's still classified as an "Input device" though.

But if "input devices" in general are prohibited, then how am I able to create a custom gamecontroller that uses sensor data?
For example, if I decided to use a camera module together with an esp32 to send the average color in a picture to the pc as an input each second, how can I use sendReport() to tell my device to turn off for example.

EDIT:
Crossposted here:
https://discourse.wicg.io/t/human-interface-device-hid-api/3070/14?u=ciriousjoker

[nondebug]

I already replied to your WICG discourse post but I'd like to follow up here too.

This is probably due to Chrome's security policy disallowing access to top-level HID collections with "protected" HID usages, here's the relevant source for the usage check:

https://source.chromium.org/chromium/chromium/src/+/master:services/device/public/cpp/hid/hid_usage_and_page.cc;l=9

The HID report descriptor has a nested structure, where top-level collections (usually) correspond to categories of device functionality. For instance a device that provides both mouse and keyboard functionality would likely expose these as separate top-level HID collections. Each collection has a (usage page, usage ID) pair that describes its functionality. Devices that use Generic Desktop / Mouse IDs will be recognized as mice, Generic Desktop / Keyboard as keyboards, etc.

The policy in Chrome is extra cautious about certain types of devices due to privacy and security concerns. With the low-level device access provided by WebHID it's trivial to implement a keylogger that can record passwords and other sensitive data, bypassing the OS's normal input focus restrictions. To prevent this sort of input logging, WebHID blocks access to any input, output, or feature reports defined in a top-level HID collection with IDs that would allow the device to be treated as a mouse or keyboard input.

This may be too restrictive, for instance there's no reason to restrict access to feature reports if they aren't treated specially by the OS. We may be able to modify the policy to allow access to protected collections while still blocking mouse and keyboard inputs.

To better understand which device functionality is being blocked, I'll need the HID report descriptor from the device. Please file a bug in the Chromium bug repo and include:

• Vendor and product IDs
• A link to the product page (is it this one?)
• The HID report descriptor

[cnlohr]

@nondebug I know I am necro'ing this thread but I can't find anything about this elsewhere on the internet. Is there any extra debugging possible to get chrome to provide additional feedback about what is working or not working?

Also, I note that the commit you have linked is no longer in the tree. It seems something has gone on with this recently? (I'm on Chrome Version 124.0.6367.60)

[cnlohr]

Aah!!! In case anyone comes across this in the future, there is additional information here: chrome://device-log/

EDIT: It turns out it was snap's fault. I had to run chrome with the following properties:

/snap/chromium/current/usr/lib/chromium-browser/chrome --user-data-dir=~/ChrUnsnapped --class="ChrUnsnapped"

[beaufortfrancois]

Here are some Dev tips for debugging WebHID at https://developer.chrome.com/docs/capabilities/hid#dev-tips