I just learned about the WebHID API and tried to use it for touchpad input; I've previously been able to use touchpad input through Windows raw input API. I was using this page, https://nondebug.github.io/webhid-explorer/ initially, to no avail. I even started editing a copy of the page, but eventually understood that Chrome simply blocks certain devices or device features. (I also tried a gamepad, and the gamepad didn't get blocked.)
Of course this kind of policy is understandable and necessary for security. Now, many people have a touchpad (a digitizer, as HID calls it) in their laptops, and modern touchpads are multi-touch and sensitive, making for a potential medium for rich interaction (for games, at the very least), especially for laptops whose screens are not touch-sensitive.
So I hope you reconsider allowing digitizer access under certain restrictions, sooner or later. The criteria that I'd conceive are to have user choice for blocking its access, and having an option (turned on by default, and recommended so) to always block digitizer reports when the script's document gets inactive (e.g. the browser's window is inactive, or the user is focusing controls like the address bar) or hidden (e.g. not the current tab, or the window is minimized).
P.S.: for touchpads in particular, it would be also great if there was a mode where its usual function as a pointing device is blocked (more or less comparable to existing full-screen modes), to better allow for custom usage of touchpad input.
P.S.: much of the same reasoning could be reapplied for VR-dedicated input devices, such as hand or other body trackers.
I just learned about the WebHID API and tried to use it for touchpad input; I've previously been able to use touchpad input through Windows raw input API. I was using this page, https://nondebug.github.io/webhid-explorer/ initially, to no avail. I even started editing a copy of the page, but eventually understood that Chrome simply blocks certain devices or device features. (I also tried a gamepad, and the gamepad didn't get blocked.)
Of course this kind of policy is understandable and necessary for security. Now, many people have a touchpad (a digitizer, as HID calls it) in their laptops, and modern touchpads are multi-touch and sensitive, making for a potential medium for rich interaction (for games, at the very least), especially for laptops whose screens are not touch-sensitive.
So I hope you reconsider allowing digitizer access under certain restrictions, sooner or later. The criteria that I'd conceive are to have user choice for blocking its access, and having an option (turned on by default, and recommended so) to always block digitizer reports when the script's document gets inactive (e.g. the browser's window is inactive, or the user is focusing controls like the address bar) or hidden (e.g. not the current tab, or the window is minimized).
P.S.: for touchpads in particular, it would be also great if there was a mode where its usual function as a pointing device is blocked (more or less comparable to existing full-screen modes), to better allow for custom usage of touchpad input.
P.S.: much of the same reasoning could be reapplied for VR-dedicated input devices, such as hand or other body trackers.