Repository navigation
Logitech G522 LIGHTSPEED support #488
Description
Activity
Thank you for requesting support for a new headset!
To implement support for a specific headset, we need to reverse-engineer and test on that device. Only people who own the headset can implement support for it.
Want to help?
- Check our Development Wiki to get started
- Use Wireshark to capture USB traffic from the official software
- Post your findings (screenshots, data) here - we're happy to help!
See ADDING_A_DEVICE.md for detailed instructions.
#477 seems like the lightspeed series made significant changes ...
Did you try "headsetcontrol -o json" after you updated the ID ?Same issues likely as in #477
I did update the firmware this week via the g hub on my macbook.Tested with LogitechG533 this time. The test with G535 is similar.
{ "name": "HeadsetControl", "version": "continuous-23-g8d16611-modified", "api_version": "1.4", "hidapi_version": "0.14.0", "device_count": 1, "devices": [ { "status": "partial", "device": "Logitech G533", "vendor": "Logitech", "product": "G522 LIGHTSPEED - Wireless Mode", "id_vendor": "0x046d", "id_product": "0x0b18", "capabilities": [ "CAP_SIDETONE", "CAP_BATTERY_STATUS", "CAP_INACTIVE_TIME" ], "capabilities_str": [ "sidetone", "battery", "inactive time" ], "battery": { "status": "BATTERY_UNAVAILABLE", "level": -1 }, "errors": { "battery": "Operation timed out" } } ] }It seems to allow sidetone adjusting, though!
headsetcontrol -s 50 Found 1 supported device(s): Logitech G533 (G522 LIGHTSPEED - Wireless Mode) [0x046d:0x0b18] Successfully set sidetone!
I just checked and the battery did not work sadly. Sidetone and inactive time worked according to the console. I could test the inactivity and it was not successful. I've set it to one minute and it did not shut off after even 5 minutes.
The changes I made to test it were the 2 for the array length as well as the Product ID within the
LogitechGProX2Lightspeedclass.
And from the merged PR you've sent me, I don't think I've missed any other configuration I should have done.static constexpr std::array<uint16_t, 2> SUPPORTED_PRODUCT_IDS { 0x0b18, 0x0af7};
headsetcontrol -o json
{ "name": "HeadsetControl", "version": "continuous-25-gabfb248-modified", "api_version": "1.4", "hidapi_version": "0.14.0", "device_count": 1, "devices": [ { "status": "partial", "device": "Logitech G PRO X 2 LIGHTSPEED", "vendor": "Logitech", "product": "G522 LIGHTSPEED - Wireless Mode", "id_vendor": "0x046d", "id_product": "0x0b18", "capabilities": [ "CAP_SIDETONE", "CAP_BATTERY_STATUS", "CAP_INACTIVE_TIME" ], "capabilities_str": [ "sidetone", "battery", "inactive time" ], "battery": { "status": "BATTERY_UNAVAILABLE", "level": -1 }, "errors": { "battery": "Operation timed out" } } ] }headsetcontrol -b
Found 1 supported device(s): Logitech G PRO X 2 LIGHTSPEED (G522 LIGHTSPEED - Wireless Mode) [0x046d:0x0b18] Battery: Status: BATTERY_UNAVAILABLE Error: [battery] Operation timed out
I'm not sure how much my device differs, but I currently sync configurations towards the headset via the logitech hub and they stay even if I switch operating systems or turn off the device. Thus I didn't have any issues in that regard.
I will try to find some time on this weekend to help out with gathering wireshark data for the battery/inactivity/sidetone.
Any update on this?
Hello there. I've obtained this headset a few days ago and I think I can help improve current support for G522.
I've already captured a number of packets with wireshark and done some tests with sending raw packets with headsetcontrol --dev, all successful so far.
Before any coding, PRs and stuff, I'm planning with Claude and he made some (imho reasonable) suggestions, so let me quote him:
The protocol is "Centurion", the same one the repo already uses for the G PRO X 2.
ghub-startup.json shows G HUB discovering the headset's features, and the packet layout is what lib/devices/protocols/logitech_centurion_protocol.hpp already implements. The only difference is the framing: the G522 uses 0x50 0x23 where the G PRO X 2 uses 0x51.
Suggested split
- PR 1: lights on/off, voice prompts, and possibly reading sidetone back, all in the existing G522 driver style. Small and easy to review.
- PR 2: EQ presets (replaying the captured bytes) and parametric EQ, once the gain encoding is confirmed.
- Optional refactor: move the G522 onto LogitechCenturionProtocol with the 50 23 framing, so feature numbers are discovered rather than hardcoded and can't break if a firmware update reorders them. That's worth raising with the maintainer before starting.
ghub-startup.json contains (as it's name spills) the captured packets when launching G Hub.
What Claude proposes for a refactor and re-using the LogitechCenturionProtocol sounds interesting from an engineering/organising perspective. Do you have any feedback on this perhaps ?
Splitting these improvements into multiple/smaller PRs is my own idea, but if you'd like me to first extensively wireshark all I can and then send over a much bigger PR containing everything, let me know. Some things on the G522 don't 100% match the current headsetcontrol philosophy (for example preset light effects, custom light zones, effects that do not support brightness vs effects that do support it, etc), so if I let Claude run loose he proposes much larger modifications, which I suspect is perphaps not (yet) desirable.
Also, running make format in a freshly cloned project as is, produces several modifications, should these belong to the same PR or the PR should contain only G522-related stuff ?
I think porting the G522 to centurion is the way to go here. Can only be done by a guy who owns the headset. So go for it
I agree
Description
I will try gather as much information as possible via the wiki on the weekend.
I've already tried adding the deviceId towards the cpp code in the logitech G535 file with no effect, will try out some others on the weekend first before going the wireshark route.
Headset Name
Logitech G522 LIGHTSPEED
Device information
Detailed Device Information
New Device Implementation Checklist