Add RGB lighting persistence and software LED power management for G515

[ksanislo]

When Solaar claims SW control of RGB effects (0x8071), the firmware's built-in power management is disabled. This adds:

• Software idle dimming via SetRgbPowerMode after configurable timeout
• Activity monitoring via /dev/input/event* to wake LEDs on keypress
• SetSWControl(mode=3, flags=5) re-send on wake to re-claim LED pipeline
• LED Idle Timeout setting (0-600s, default 300s) exposed in the GUI
• Proper color restore sequence after wake from idle dim

Tested on G515 LIGHTSPEED TKL. Wake sequence matches LGHUB behavior observed via USB capture analysis.

[ksanislo]

There is one minor difference here in compared to the official app. The official app does a short timeout before lowering the RGB values to 50%, then waits for the full timeout to trigger the lighting shutdown sequence, and this only gives a single config parameter for the final shutdown and doesn't bother with the initial idle state dimming or any idle effects. I can rework that patch to match the official app, or we can call it good as-is, whatever your preference would be. I didn't know how many config values you'd want to see get added for this kind of thing.

Also, this also works on other devices that implement the same feature set, not just the G515. This is also tested and operates properly with my G502 X PLUS mouse.

[pfps]

Can you provide the output of solaar show for the mouse?

[pfps]

It looks as if some style checks have failed, please look at the details in the checks area.

[ksanislo]

Sorry about that, I was intending to fix the problems I had running the linter run before I pushed, then completely spaced it off at the end anyway. I've also included another commit with the G502 X PLUS output.

I wanted to ask what you thought about how the timeout implementation was done in here still though. Since this is doing it solely in software, I just threw in an adjuster for it as a changeable parameter, but I didn't tie it to either of the timeout values which are saved into the device. I'm open to anything from just accepting whatever is saved in the device and using that, either for a single timeout operation, or duplicating the two-stage idle timeout from software only, or taking things all the way and tying everything together and actually updating the timeout values on the device and providing the proper settings for them like G hub offers. I just didn't want to go overboard on features without getting your option on things first.

[pfps]

I don't have much to say on the timeout yet, as I haven't tried out the PR on my keyboard. The only advice I have is not to worry about being the same as the Logitech software.

[ksanislo]

I found a flaw in my original idle detection in that it could lose the ability to monitor for input when playing games that take over exclusive control of the input devices. Instead, I reworked this to find and use the relevant hidrawX device directly to monitor for activity, which avoids the problem.

I also went with a two-stage dimming similar to the onboard firmware, as reducing the brightness where possible should help save battery life. Since we have to do this under full software control, I made it a nicer smooth fade to the "idle" brightness instead of a harsh jump. There's still a hard cut to the idle animation if you choose that option instead of just dimming. The sleep timer power down is also timed to start 30s prior to the actual set value, so the device will have finished the fade out and go to sleep at the set time instead of starting the fade from that point.

Overall, I'm pleased with the basic state of this for my own use, at least for the moment. If you'd care to see any additional features supported, I'd be happy to implement a more complete set of what this hardware is capable of, as there's still a whole lot more that can be added in.

[pfps]

When I have some per-key lighting the keyboard snaps to all-red when the idle timeout hits and then fades later. When I touch the keyboard it flashes to red and then the per-key lighting kicks in. Is that what you see?

[pfps]

Solaar already hears all the hidraw events on the device, so you shouldn't need to have a separate connection. It would be nice to just tap into that, but some work is needed, probably mostly in base.py.

[pfps]

It appears that either the LED Primary is in charge or the Per-key Lighting is in charge. Do you find that as well? If so it might be a good idea to have the LED Control setting generalized somehow.

[pfps]

It might take a while to iron out all the idle stuff. Would it be possible to make a PR with just the code that turns off firmware control?

[ksanislo]

per your questions/comments

1. When I have some per-key lighting the keyboard snaps to all-red when the idle timeout hits and then fades later. When I touch the keyboard it flashes to red and then the per-key lighting kicks in. Is that what you see?

I actually never tested per-key lighting. I will go back and actually look into this further. It's likely that there is going to be more manual SW control required to pull off per-key than what I implemented.

2. Solaar already hears all the hidraw events on the device, so you shouldn't need to have a separate connection. It would be nice to just tap into that, but some work is needed, probably mostly in base.py.

Solaar's existing hidraw connection is only to the control interface, it seems that we have to actually pick up the regular keyboard/mouse input interface to see keyboard and mouse activity from the user, as the hidraw we already have open doesn't provide that information.

3. It appears that either the LED Primary is in charge or the Per-key Lighting is in charge. Do you find that as well? If so it might be a good idea to have the LED Control setting generalized somehow.

Yeah, they're set via separate methods in the keyboard, and in the real app you basically have to just pick one method or the other. I've only ever bothered playing with the full color at once method, but I'll make it a point to figure out how to better support per-key next.

4. It might take a while to iron out all the idle stuff. Would it be possible to make a PR with just the code that turns off firmware control?

Unfortunately, due to the limitations of how this keyboard works, they're not really separate things. When you switch to SW control to make the lighting color stay persistent, you get the side effects that require full manual control for everything else with it.

[pfps]

Yes, separating out the idle stuff means that there is no dimming, etc., but it's going to be much easier for me to check out the code that turns off firmware control by itself. The idle stuff is going to require a lot of checking out.