Adds support for a new G PRO X2 variant#478
Adds support for a new G PRO X2 variant#478ChrisLauinger77 wants to merge 1 commit intoSapd:masterfrom
Conversation
Adds a new device ID for a previously unsupported variant of the Logitech G PRO X2.
|
I added the deviceID as described and compiled it. |
|
after reboot - it times even out .... |
|
No other way but to capture the packets the original software sends using wireshark |
Does it really need to be wireshark on windows ? I have a macbook ... |
When I remember it right on a Mac it was difficult because of the kernel protections. Best thing there is to use a virtual machine with windows and pass through the usb device to it |
Alright - VM it is then |
|
Try again:
|
|
better ? |
|
maybe also valueable info: |
|
@ChrisLauinger77 do you know at which battery percentage you were on your latest capture? and was it loading or discharging? |
|
52% not plugged in. So discharging |
|
Not 100% sure but could be The response should be then: |
|
|
made a capture during charging - saw also in UI that it went from 52% to 54% |
|
Cant really see the battery status in there, is interrupt IN included too? You can also try repeadtly |
|
|
Looked into it but cannot find it, you probably need to run it with a loop over longer time and while opening the driver application |
|
Hmm ... I get on windows where the driver application is running (headsetcontrol is the artefact from this PR) |
|
when I use the released version of headsetcontrol I get |
|
With other versions too? Not sure what could have caused that in code |
No success on windows with 2 versions. I could also try older releases ... |
|
I checked it a bit The Windows issue is that this device variant (0x0af7) exposes completely different HID usage pages than the other G PRO variants. From your --dev --list output: But the LogitechGPro class hardcodes usagepage=0xff43, usageid=0x0202 for battery/inactive time (which doesn't exist on your device at all) On Windows, the code tries to match that usage page first, fails, then falls back to opening the first enumerated HID endpoint (the 0x000c consumer controls one), which is wrong that's why --dev --send fails with "Failed to send". On Linux it doesn't matter because all three entries resolve to the same /dev/hidraw3, so the timeout there is a separate protocol issue (probably the battery command itself being different). Could you run --dev --list on Windows too? I'd like to see what usage pages/interfaces it enumerates there they might differ from Linux. That would tell us which usagepage/usageid to set for this variant. |




Adds a new device ID for a previously unsupported variant
of the Logitech G PRO X2.