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

NUT for Windows USB (HID?) drivers may not fully access the hardware by default #1646

Open
jimklimov opened this issue Sep 2, 2022 · 1 comment
Labels
packaging USB Windows Windows-not-on-par-with-POSIX Aspect of Windows builds known to be dysfunctional compared to POSIX builds; fix needed to be on par
Milestone

Comments

@jimklimov
Copy link
Member

jimklimov commented Sep 2, 2022

A specific practical issue to track in context of NUT for Windows effort, so related to some others with broader scope such as #1507 and #1636. It may also relate to packaging e.g. #1485 and older discussions like #1145 and #1050 that touch on issues with latest published NUT v2.6.5 based MSI.

This one is about the hunch that relative failures of USB driver testing seen in development of the Windows branch, such as seeing only device metadata like name/vendor/... but not detailed Report Descriptors with data of interest, were because either further Windows kernel drivers (libusb0.sys, libusbk, etc.) are needed to intercept USB HID devices and/or tap into system's handling of those (as a HID Battery by default), or native means of libusb-1.0 might be utilized (tell it which backend to use).

Looking at https://github.com/libusb/libusb/wiki/Windows#known-restrictions maybe my problems seeing device data stem from not installing libusb-win32 right (or libusbK at all) on the testbed. There should be a kernel level driver to access the device so Windows HID battery support does not preempt a NUT driver, probably.
See also https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/supported-usb-classes

@jimklimov jimklimov changed the title NUT for Windows USB drivers may not fully access the hardware by default NUT for Windows USB (HID?) drivers may not fully access the hardware by default Sep 4, 2022
@jimklimov
Copy link
Member Author

Another data point: as investigated in #1690 the Windows OS may by default bind its own driver (e.g. "HID Battery") to the device, so precluding libusb from fully using it; as that issue elaborates in #1690 (comment) comment, the Zadig tool can be used to force the use of a low-level driver we want for specific connections (VID:PID pairs) - possibly until an OS update though, hear-say goes that such overrides may not survive the OS changes if those provide "newer" handlers.

It is also anticipated that completing the NUT for Windows installer quest would provide these VID:PID bindings (written to the OS by the installer with its elevated privileges) same as we have for udev etc. in the POSIX codebase builds.

@jimklimov jimklimov added this to the 2.8.4 milestone Apr 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
packaging USB Windows Windows-not-on-par-with-POSIX Aspect of Windows builds known to be dysfunctional compared to POSIX builds; fix needed to be on par
Projects
Status: Todo
Development

No branches or pull requests

1 participant