-
-
Notifications
You must be signed in to change notification settings - Fork 4
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
G935 support #52
Comments
Is your G935 connected wirelessly? Getting this to work is going to be tricky. The error you see is because the script tries to find the USB endpoint of the device, which if connected via Bluetooth is not going to exist. This issue is similar to the G915 (wireless version of G815), because the USB endpoint registered in the system is not actually the one of the keyboard, but it is the one of the USB dongle doing the connection. Is it possible to connect the headphones via USB cable? If yes it would be interesting if the USB endpoint can be found correctly or not. You can do it like this:
It should show some output of the headphones registering in the kernel. In general it is sadly quite tricky to add support for devices "remotely" since so far I have always needed to also reverse engineer the Windows driver in order to get command sequences needed to switch the device into host mode. |
It is connected wireless with a dongle. dmesg output:
|
Thank you for the dmesg, it is sadly the exact same problem / situation as with the G915 (#25). Connecting to the USB dongle probably fails, because one or more of these parameters at the start of the script are not correct: usbConfiguration = 0
usbInterface = (1, 0)
usbEndpoint = 0
disableGKeysInterface = 1
usbUseWrite = True Sadly I cannot tell you which ones are needed for your device, every device is different, it is essentially a guessing game. Once that works, it should be possible to find the correct HID endpoint and connect to it. If you are lucky, the headphones will directly send raw data to that endpoint. If not (like it is the case with the G915) then I usually have to send one or more commands to the device to make it send the raw commands. Sadly as I already mentioned above, I had to find those out by reversing the Windows driver as Logitech does not document them publicly. |
I managed to get the USB info by running import usb.core
print(usb.core.find(idVendor=0x046d, idProduct=0x0a87)) Output
Using interface 3 seems to work usbConfiguration = 0
usbInterface = (3, 0)
usbEndpoint = 0
disableGKeysInterface = 3
usbUseWrite = True
Unfortunately only the mute and volume controls seem to be picked up.
Oddly when toggling the LEDs or changing sidetone settings with other software like HeadsetControl the headset sends something back:
is there a method to finding the correct commands? or just poking around in a debugger? |
Oh this is interesting, so Interfaces 0 - 2 are Audio, which makes sense and 3 is a HID device. Does anything happen when you press the GKeys? In the case of the G915 the GKeys are mapped to F1-Fn by default is that also the case for you?
Depends on the device. If your headset is supported by Logitech Ghub (not LGS), then my setup was a Windows VM with Logitech Ghub installed in it and Wireshark with the USB plugin (you have to check the USB thingy in the installer). Then you have to listen on the USB port of the device and launch Ghub. It will then send a bunch of data back and forth. Most important is the launch sequence and when you press any of the GKeys. You can copy the bytes sent directly into the debugger script and check if it is working. EDIT: how does the headset get listed in |
evtest only triggers when using the volume wheel while newDeviceDebugger additionally shows mic mute events.
I'll check later if I can see something with wireshark |
Progress :) Using wireshark I found commands being sent from the host Traffic
putting these into the newDeviceDebugger actually seems to work and I can see the G buttons being pressed from my testing only this packet seems to be required: disableGKeys = [
b'\x11\xff\x05\x2a\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00',
] which leads to these results:
|
oh nice good job, this is exactly what I need! Does mute / unmute actually work, as in does it trigger the mute / unmute system wide? If not, this could be added quite easily. EDIT: does the mute button not send two packages? Usually there is a "pressed" and a "release" package |
I have pushed the initial implementation to the |
I tested the G935 branch and it works like a charm. Mute/unmute doesnt work, flicking up the microphone mutes it but there is no way to unmute it after that. Also if its not too hard to implement it would be great if the disableGKeys command can be sent everytime the headset connects (in case you turn the headset off or change batteries) |
Another small nitpick: The order of the G buttons does not represent the physical layout, it should be G3, G2, G1, Mute |
Sorry this might be a dumb question, but are you talking about the headphone mute or the microphone mute?
This seems to be a known issue since forever and it looks like only hacky solutions exist. (see here for reference).
Ok understood not a big issue, but weird given that all their keyboards do it.
Sadly tricky to implement in the current codebase as this behavior does not exist with wired keyboard. A quick hack could be doable, but I fear that it might cause issues with existing users, so the proper way would be to implement an alternative mode for headphones (where I then could also treat the mute / unmute separately as currently mute is done by the kernel driver for all supported keyboard.
Do you mean just the order of the buttons in the UI or does G1 in the UI not map to the physical G1 button? |
They both mute the microphone which is why I suggested making the button configurable.
Actually it all works as expected until you disable G keys.
It is mapped correctly, just the order in the UI is wrong |
Alright ok now I understand.
Does mute / unmute after G keys disabled work at all? If yes, then that is the kernel driver doing it, which means remapping those buttons is not trivial. if no, then it should be fixable.
Understood, well that is currently hard coded. :V |
with G keys disabled unmute doesnt work at all, mute only works when moving the microphone up, which is probably a firmware thing |
ok one last question, does the mute button (the one you would like to remap) do anything after sending disableGKeys? |
no it just sends data but doesnt mute or unmute the microphone |
Alright understood, I will add the mute button as G4 then so you can remap it. (the names are hard coded for now, renaming them will require implementing a separate mode for that, which I currently don't have the time to do) EDIT: ah damn I just realized that I cannot do that with the current logic, because there is no releaseEvent, so the moment you press the button it will get registered as you holding down the button all the time. |
I pushed version 1.0.5 with initial support. For full support you will have to be a bit patient as I currently don't have the time to do it. |
Awesome. |
I am trying to get output from a G935.
G935 is a headset that has buttons on the side which can be remapped in the Logitech software just like any other G-Key.
Unfortunately the newDeviceDebugger just throws an error:
same output for --info
I also tested with my G815 which works without issues.
To me it seems like the G935 connects just like a keyboard since volume up and volume down "keypresses" are correctly being recognized in other software
The text was updated successfully, but these errors were encountered: