Cannot interact with non-GUI HID interface
jhaenchen opened this issue · comments
Is there any new info about how I should use HID devices over Bluetooth? It seems oh so very reasonable to use the HID protocol to do a million different things, many of which have nothing to do with audio streams or keyboard inputs.
chrome.hid won't allow you to interact with HID pages associated with keyboard or mouse input, but they will allow everything else. Can we allow a similar filtering system for web bluetooth?
Totally blacklisting the HID protocol seems like overkill to me. A softphone is an easy example of where this functionality would be useful.
Many hardware vendors will use HID over USB and simply port that to Bluetooth using the HID GATT. Blocking HID from WebBluetooth limits its ability to be backwards compatible with typical devices.
IIRC, Android blocks access to HID GATT because of security concerns. I think that validates Web Bluetooth's decision to also block access to it.
A Web API that specifically targets HID and takes appropriate security measures seems like a better alternative.
@g-ortuno Do you see the issue, though for my use case?
The Jabra Speak 510 is an HID that offers multiple HID usage pages. Chrome.HID, the web API I assume you refer to, will not allow interactions with keyboard and mouse usage pages but will allow other page access. For me, this is reading button pushes to start and stop the call from the input report of the Jabra. Over USB, this process works well. On Bluetooth, however, I cannot discover the HID device. I must instead go through WebBluetooth and use the HID GATT service to implement the same functionality. There is no other way as far as I can tell, to interact with these devices.
I have no idea how many other hardware manufacturers use the same shortcut of HID over USB => HID over Bluetooth but it seems like an obvious approach to save time.
Blocking access to the HID GATT service may prevent softphone applications from becoming fully fledged web apps.
This could extend to popular apps like Discord and Skype and Slack, for example. Seems like a big limitation to me.
Hi @g-ortuno ,
If I can add my voice here, our Logitech Unifying for Chrome app uses chrome.hid API we co-developed to communicated with our unifying receiver using HID vendor. It would be great indeed to allow readonly access to top-level collections like consumer page, and read-write access to vendor page.
I'm pessimistic in the probability of success of standardization of a W3C version (say web-hid), considering the fact that we are not even done pusing web-bluetooth to Edge and Safari team! If we Logitech can help further, of course we'll do!
@g-ortuno I think it's also interesting to see where WebUSB decided to allow HID at a higher level interface than the typical USB WICG/webusb#29
This is a very similar situation to WebBluetooth's.
@jhaenchen, I think you are misinterpreting my comments on the WebUSB issue. That API does not allow connections to HID interfaces either. My suggestion there was that the existing web input APIs should expand to account for more types of input device, such as the telephony devices you mention.
Deleted off-topic comments.
@reillyeon As I understand it, Chrome did go with oostap1's first (or third) approach from that link: "Implement new WebUSBHID interface for Chrome and provide to Chromium as spec/patch. It might be like chrome.hid on top of usbhid hid user space library." chrome.hid does just that, and I have used chrome.hid to interact with some telephony functionalities, though I can't say for sure i was using telephony usage pages to do so (it may have been button pushes and LED setting).
The problem is that chrome.HID is built on the assumption that you're interacting with the device over USB. I suppose in a perfect world chrome.HID would be an interface that could interact with any authorized device be it USB or Bluetooth GATT. As of now there seems to be no way to interact with HID over bluetooth, and I see no way for chrome.HID to be such a solution without an implementation by the WebBluetooth team.
I would consider it a very good design indeed for these protocols to play nice with each other, allowing us to build technologies that use devices from a variety of sources. These are not, after all, fundamentally different use cases between USB and Bluetooth, just different means of connecting you to your device.
PS is there any way this could remain open? It seems clear to me that this issue is not quite settled.
chrome.hid is not a web API since it is restricted to Chrome Apps and predates WebUSB by years so it isn't an implementation of the first approach there. To my knowledge there has been no movement on the second approach. The third approach is what I recommend to developers building devices they intend on using with WebUSB.
It's unfortunate that the work to make chrome.hid work reliably with Bluetooth devices was never done.
To be clear, what would need to be done to Web Bluetooth to unblock the HID GATT service is to implement support for parsing the HID messages encoded in GATT messages and applying similar filtering to what is done in the chrome.hid API. This behavior would need to be carefully specified so that it could be implemented consistently across browsers.
@reillyeon @g-ortuno I honestly think it would be worthwhile. How can a general bluetooth API block one of the most common protocols for interacting with devices, especially the only one shared with USB?
seems there are new options on the horizon: WebHID API / repository
in this comment from 04.04.2019 it is mentioned that this should come to Chromedev in near future..
more information: