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

Exclusion #40

Open
JamesB7 opened this issue Nov 3, 2020 · 4 comments
Open

Exclusion #40

JamesB7 opened this issue Nov 3, 2020 · 4 comments

Comments

@JamesB7
Copy link

JamesB7 commented Nov 3, 2020

Hello,

I'm the creator of the HIDSharp library for C# USB HID communications. I use this library in a product I'm contracted to create, Evolv's EScribe Suite.

Since Windows does not provide any form of exclusion for USB HID devices, I do it manually using global mutexes, with handoffs, etc. This allows different aspects of the (multiprocess) product to coordinate and not conflict as far as USB HID communications go. (This also works on Mac and Linux.) Of course, this problem does not exist with WebUSB, since USB access is not shared.

Is there any equivalent for Chrome? I could easily extend my HIDSharp library to support however Chrome may implement this (Windows mutexes, or whatnot), and update our desktop applications. Our ECigStats software downloads statistics upon connect, and my web implementation does the same, so if both are present, it does not work too well. We have other pieces of software that also need exclusion.

Does Chrome provide anything of this sort, named mutexes or whatnot (prefixed by the origin or something would be fine)? It need not be specific to WebHID, I just haven't found anything at all of this kind.

Thank you!

James

@inexorabletash
Copy link
Member

Would https://wicg.github.io/web-locks/ be a fit here? They're origin-scoped named mutexes, supported in Chrome for the last several years.

@JamesB7
Copy link
Author

JamesB7 commented Nov 3, 2020

Hmm... If the locks can be manipulated from desktop software, I could update said software to also take and check the web lock. That's the real question, I suppose, whether said locks are backed predictably by an OS resource of some kind.

@inexorabletash
Copy link
Member

The locks are internal to the browser. Sorry, I misinterpreted your use case.

@JamesB7
Copy link
Author

JamesB7 commented Nov 3, 2020

That's too bad. Between web instances it would work well actually. Problem is we have both desktop and web software, and HID doesn't have any OS-level exclusion. Hmm. I'll see if I can come up with any alternate approach. Thanks for the idea though :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants