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

Add Windows quirks to documentation and potential Windows libusb backend #61

Open
Hoernchen opened this issue Aug 3, 2019 · 3 comments
Labels
documentation Improvements or additions to documentation enhancement New feature or request libusb Related to libusb backend Windows Related to Windows backend

Comments

@Hoernchen
Copy link

Using hidapi on windows is constrained by multiple issues, i.e. the inability to gain exclusive access to many devices (see signal11/hidapi#231) and no access to mouse & keyboard devices (signal11/hidapi#313) . The latter is important since it affects fancy keyboards that offer lighting effects, and the most obvious approach would be to use hidapi, while this actually requires dealing with zadig and libusb.

Things like this should be added to the docs, so Windows users don't need to rediscover these issues all the time.

@Youw Youw added the documentation Improvements or additions to documentation label Aug 29, 2019
@CalcProgrammer1
Copy link

CalcProgrammer1 commented Jun 3, 2020

I have a modified version of the libusb-backend hidapi.c that compiles on Windows. It is able to control RGB lighting devices in keyboards and mice if the appropriate interfaces have the WinUSB driver with zadig. It's basically just a hack to remove the linux-specific stuff in the libusb backend and could use some cleanup, but this method does work if you wish to use the hidapi library in your code and still access these devices in Windows.

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/dependencies/hidapi/hidapi.c

My OpenRGB project uses the Linux and MacOS native versions of hidapi just fine, but the Windows version does not work for whatever reason. It detects some devices but can't control them. If I use my hacked up libusb hidapi.c in place of the released library, it works just fine.

I was looking at the Redragon K556 keyboard software in API Monitor to see why that software has no problems controlling an RGB keyboard with the HID driver but my implementation requires WinUSB. This is what I'm seeing when I change settings:

image

I don't see an obvious call to any hid_write or hid_set_feature_report equivalent function in the Windows HID library. I am monitoring HID.dll and the wrapper DLL that the keyboard software uses.

@mcuee
Copy link
Member

mcuee commented Jun 13, 2021

Actually I think it may not be a bad idea to have a libusb based Windows backend (using Zadig and WinUSB driver) to take away some of the limitations of the Windows HID driver. Some users may want to use that way.

@Youw
Copy link
Member

Youw commented Jun 14, 2021

Agree, that would be a good option.

The usage of POSIX API would need to be replaced for libusb backend implementation of hidapi (preferably by C11 imho).

@mcuee mcuee changed the title Add Windows quirks to documentation Add Windows quirks to documentation and potential Windows libusb backend Jun 14, 2021
@mcuee mcuee added the enhancement New feature or request label Jun 23, 2021
@mcuee mcuee added the libusb Related to libusb backend label May 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request libusb Related to libusb backend Windows Related to Windows backend
Projects
None yet
Development

No branches or pull requests

4 participants