search

JSubelj / g910-gkey-macro-support

GKey support for Logitech G910 Keyboard on Linux
GNU General Public License v3.0
99 stars 31 forks source link

Driver breaks RGB support #53

Closed aquova closed 1 year ago

aquova commented 3 years ago

I first want to say thank you for this project. This seems to be the only project around that offers working macro binding support for this keyboard. Unfortunately, whenever support is active, active RGB support (as provided by OpenRGB, keyleds, etc.) becomes disabled. I suspect this is due to the project needing to claim the interface in order to read keypresses. Is it possible to avoid having to do this? I'm not sure if using something like hidapi would allow for both to co-exist.

Nereuxofficial commented 3 years ago

Same here. If you look at the wiki, you will find this page at the bottom of which you can find the mention of g810-led, which seems like they are aware of this problem

suabo commented 2 years ago

I had OpenRGB already installed and remember that i didn't really liked it but anyways if I start it now the keyboard doesn't show up even after rescan of devices. I even stopped the service and couldn't bring the device up in OpenRGB. Can you confirm this behavior?

I also have installed g810-led and the command g910-led --list-keyboards shows the device.

I have to look into this more deeply, but maybe i can get it working.

suabo commented 2 years ago

I did a little bit of research on this topic and found a python hidapi But there is also another thing with the current pyusb integration i want to test with claiming of the usb device when only reading data. I will report on that here.

I uninstalled g810-led and disabled the service for g910-gkeys and rebooted to get OpenRGB detecting the keyboard again.

suabo commented 2 years ago

I found that if you detach_kernel_driver you also need to re-attach it after.

if dev.is_kernel_driver_active(USB_IF) is False:
    usb.util.release_interface(dev, USB_IF)
    dev.attach_kernel_driver(USB_IF)

That way you could at least stop the service to make adjustments in OpenRGB. I think since the driver is designed to run all the time (as a service) this was simply overlooked in the first place. To provide a better compability with other drivers and apps accessing the device i will implement the re-attachment in the next time.

If you don't detach the kernel driver you can't i/o to the keyboard. There is just an exception stating Device is busy. I also played around with the usb timeout and the interval for the reading loop to get some better performance corresponding to #16

There will be no way around using hid to allow a simultaneous access from the driver and OpenRGB without the need to stop the driver to run OpenRGB. I need to figure out if i want to keep support for libusb via pyusb or replace it. Any suggestions?

suabo commented 1 year ago

With the update to 0.3.0 you will be able use OpenRGB if service is not running/stopped. pyhidapi needs to get integrated to fully support OpenRGB on runtime since we now claim the interface exclusive for the driver. I have a new issue for that topic #73 so i will close this issue now.