Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot interact with non-GUI HID interface #393

Closed
jhaenchen opened this issue Apr 25, 2018 · 13 comments

Comments

@jhaenchen
Copy link

commented Apr 25, 2018

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.

@jhaenchen

This comment has been minimized.

Copy link
Author

commented Apr 26, 2018

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.

@g-ortuno

This comment has been minimized.

Copy link
Contributor

commented Apr 27, 2018

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.

@g-ortuno

This comment has been minimized.

Copy link
Contributor

commented Apr 27, 2018

A Web API that specifically targets HID and takes appropriate security measures seems like a better alternative.

@g-ortuno g-ortuno closed this Apr 27, 2018

@jhaenchen

This comment has been minimized.

Copy link
Author

commented Apr 27, 2018

@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.

@jhaenchen

This comment has been minimized.

Copy link
Author

commented Apr 27, 2018

This could extend to popular apps like Discord and Skype and Slack, for example. Seems like a big limitation to me.

@jracle

This comment has been minimized.

Copy link

commented Apr 27, 2018

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!

@jhaenchen

This comment has been minimized.

Copy link
Author

commented Apr 27, 2018

@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.

@WebBluetoothCG WebBluetoothCG deleted a comment from hilowshiy Apr 27, 2018

@WebBluetoothCG WebBluetoothCG deleted a comment from jracle Apr 27, 2018

@reillyeon

This comment has been minimized.

Copy link
Contributor

commented Apr 27, 2018

@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.

@jhaenchen

This comment has been minimized.

Copy link
Author

commented Apr 30, 2018

@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.

@jhaenchen

This comment has been minimized.

Copy link
Author

commented Apr 30, 2018

PS is there any way this could remain open? It seems clear to me that this issue is not quite settled.

@reillyeon

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2018

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.

@jhaenchen

This comment has been minimized.

Copy link
Author

commented May 3, 2018

@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?

@s-light

This comment has been minimized.

Copy link

commented Jun 12, 2019

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:

@s-light s-light referenced this issue Jun 12, 2019
3 of 3 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.