RFC: WIP: Add ability to register device connection/disconnection callback #299
No reviewers
Labels
No labels
3rdparty
Android
API
Author does not respond
bsd
bug
build system/CI
ci-virtual-device
CMake
Contributions Welcome
Core
dependencies
device-specific
documentation
don't_merge
duplicate
enhancement
Example
Haiku
hidraw
hotplug
info required
invalid
libusb
macOS
Misc
Not an issue
question
Release
Test
Test GUI
Windows
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-libusb/hidapi!299
Loading…
Reference in a new issue
No description provided.
Delete branch "device_notify"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I have implemented two new methods:
These could be used to receive notification about HID device connection or disconnection.
I did implement it only for Windows via CM_Register_Notification that is available since Windows 8. Not sure about other platforms.
Any comments/objections are welcomed.
There is some things to do:
interface_notify_callback()device add/remove thread safe.notify_contextonhid_exit()Lets make it for the feature branch: https://github.com/libusb/hidapi/tree/connection-callback
This is linked to hotplug support: https://github.com/libusb/hidapi/issues/238
The function names may need some discussion. Maybe hid_device_callback can be named as hid_device_hotplug_callback. And hid_register_callback can be named as hid_register_hotplug_callback.
@mcuee I did some renames:
hid_device_callback->hid_hotplug_callback_fnhid_register_callback->hid_hotplug_register_callbackhid_unregister_callback->hid_hotplug_deregister_callbackNow it looks much more like libusb hotplug notifications implementation.
I have added dynamic load of
CM_Register_Notification/CM_Unregister_Notificationfromcfgmgr32.dllsince MinGW-w64 doesn't have them it in its headers: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/include/cfgmgr32.hFirst test seems to be positive. With hotplug of my Microchip PICkit 2 programmer (single HID device as seen by HIDAPI) and Logitech USB Receiver (6 HID devices as seen by HIDAPI)
click for full run log
Then I tested with a Bluetooth Mouse (Logitech M557 Mouse) and it seems to work fine as well. It will show up as 6 HID devices as well by hidapi.
click to expand
@DJm00n This seems to work pretty well under Windows. Just wondering if you can add for other backend as well (eg: Linux hidraw, libusb or macOS). I have the systems to test for these platforms (Windows laptop, Raspberry Pi 400 Linux and Mac Mini M1 macOS).
Related libusb issue: https://github.com/libusb/libusb/issues/86
This is a large (even though important) change.
Please target it agains https://github.com/libusb/hidapi/tree/connection-callback branch, instead of master, for now.
For reference, I have created code for a similar purpose for Linux and macOS here: https://github.com/z3ntu/devnotifier_test (it's made for use with Qt5 but this can easily be removed again I think).
On Linux it does seem to work fine but on macOS I am told it doesn't work on actual Macs - I have only tested it on a VM where it does work.
@DJm00n Have a look at the feedback here: https://github.com/libusb/hidapi/issues/238#issuecomment-1003718857
Maybe this one can be considered for next next release like 0.13?
Too many stubs. Need to design/implement for all platforms, before we can release it. It is all doable.
I have done an implementation for this functionality on MacOS previously that worked well, using the
IOHIDManagerSetDeviceMatchingfunction really makes the implementation pretty short & sweet.My implementation is currently using objective-c but I am more than happy to port it to C if it would be beneficial for getting this feature implemented?
A reliable hotplug detection for MacOS would be of big help!
Such a PR would be one further step on the road to this feature. Than there would be an implementation for two of the four hidapi backends.
Yes, it would.
I still have some comments regarding the API/design (thread-safety and consistency/syncronisation with
hid_enumerateneeds to be considered), they (the comments) just not ready-enough to be written down by me.But not to stale the support from the community - lets have this merged into a future branch as this PR suggests, and we'll apply all suggestions/improvements on top of it before merging the future branch into master.
Glad to hear it, I finally had some time to build an example this week, it can be seen here.
It shows how to make dictionaries that will match on any combination of
vendor id,product id,usage pageandusage idand execute provided device addition and device removal callbacks.With the default configuration the callbacks will be called on app startup, with any devices already connected to the computer that fit the matcher dictionary, not just new events while it is running.
I am happy to find some time in the future to work on the actual hidapi implementation aswell
Indeed this will be good -- to rebase to git HEAD and in the feature branch.
https://github.com/libusb/hidapi/tree/connection-callback
@Youw
It seems to me that the feature branch has not been updated to merge the changes here.
Updated
Hmm, it does not seem to be updated. It seems to be the same as master branch.
https://github.com/libusb/hidapi/tree/connection-callback
That's what I meant - I've updated connection-callback to be in sync with master.
As for DJm00n:device_notify - yes it is not yet updated.
I have spent some time to rebase @DJm00n's branch to the new connection-callback as well as fixing the nullptr read issue from https://github.com/libusb/hidapi/issues/238#issuecomment-1003718857; located here https://github.com/libusb/hidapi/compare/connection-callback...andyvorld:hidapi:device_notify
Not really sure on how to maintain authorship with @DJm00n, or someone else as I am not really experinced in developing with the windows api; just got this to build and run the basic
test.c, for use with some of my personal projects.Try pushing your changes directly to https://github.com/DJm00n/hidapi/tree/device_notify or open a PR against it.
I'm sure @DJm00n will accept it as soon as he can, and all your changes/efforts will be visible in this PR.
UPD: yeah, and thanks for doing it.
Opened the PR on @DJm00n's branch.
@andyvorld thank you for your work. I have manually rebased my changes under current
upstream/masterbranch and also cherry-picked your b8642132f85c4dafafd8f5cd1435e06fec13fc11 fix.Also, your 80e3e0136dbe5ca83ae49851b8b92c4df67c8daf change was a bit broken - so I did proper changes instead while rebasing.
I've done this to avoid unnecessary noise in the git history.
@DJm00n could you explicitly merge
libusb:connection-callbackbranch into yourlibusb:connection-callback(with a merge commit)? otherwise the diff on Github is not what is should begithub action for macos-cmake and ubuntu-cmake failed due to compiler warning treated as error. Interestingly macos-automake passed.
Run log under Windows. I run hidtest.exe. Then I unplug the Logitech USB Receiver and then plug it back in.
@DJm00n
I am thinking that for the first run the devices should not be considered as newly plug-in. In fact for this Acer laptop, only the Microsoft Bluetooth Mouse and the Logitech USB Receiver are external devices.
BTW, the above is talking about the lack of hotplug feature for libusb Windows backend. Since we only use libusb under Linux and BSDs but not Windows, the above libusb issue does not really matter.
I think there is a flag on
hid_hotplug_register_callback, the basic test program hasHID_API_HOTPLUG_ENUMERATEon it. Setting it to 0 seems to not enumerate already connected devices.Thanks. Yes this is the one.
Yeah, it is not only a compiler - we explicitly set "more warnings and warnings-as-errors" only for CMake builds for our CI.
Yup.
Happy to see progress on this 😍
Once merged to the feature branch i can open a MacOS implementation PR against it.
What's remaining before the merge to feature branch?
@mini-ninja-64 its missing some mutex protection of the callback list on register/unregister/notify
@ -428,3 +465,3 @@return -1;return token_value;return interface_number;interesting why MinGW doesn't inline this function (failed CI)
lets make it
static- it wouldn't really affect performance, but at least one compiler will have less complainsAs promised - merged into dev branch, so the community may work on the implementation for other backends.
I've opened a separate ticket for the "mutex problem".