-
Notifications
You must be signed in to change notification settings - Fork 428
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
Leds config is reset after some time on logitec G515 lightspeed tkl #2791
Comments
Updating to 1.1.4 might solve the problem and it is worth doing that first if possible. Kill Solaar and run as |
no debug output when it falls back to default mode on keyboard |
hmmm same behaviour $ solaar -dddd -w hide
|
At what time in the log did the leds reset? |
the last details are from startup, then no more log entries and then after some time or sometimes when pressing a key it resets, no logs at that time |
@pfps happy to test on my device with dev builds to support this keyboard ;) |
If nothing at all shows up at the time of the reset then there isn't anything that Solaar can do. Solaar responds to events that it sees, such as notifications from devices. Devices are supposed to send a notification when they need to have their configuration resent and Solaar responds to these notifications by sending commands to the device to implement the settings Solaar has for the device. Solaar also responds to udev notifications, but that's more about new devices being connected to removed. |
Pitty... But i see the point... |
could it be that there is some kind of persistence flag missing in the initial config message to the keyboard? Do you know of anyone who is more in depth into the logitec hid++ protocol? I am specifically "nervous" about this line at the end of solaar show: 1: G515 LS TKL |
That problem might be solved in 1.1.14. Most settings are transient and that cannot be changed. Some settings are persistent and that cannot be changed. A very few device features have both transient and persistent parts. Solaar generally uses the persistent part if both are available and do the same thing. |
this log is from 1.1.14 |
also when turning off/on the keyboard it gets correct colors but as soon as i press a key most of the times it resets to blue wave |
When the keyboard is turned off and then on again Solaar sees this an resends the settings, that that is expected. If the keyboard resets to default when a key is pressed this indicates that there is something unusual going on in the keyboard. Solaar can't do anything here as well. To reiterate, Solaar can only work correctly if a device behaves well. If the device changes its behaviour without notifying Solaar then Solaar can't reimpose the user's settings for the device. It appears that this is happening here. It may be that the device is in some sort of weird state, like a demo mode, but Solaar doesn't have any knowledge of this kind of behavior. So unless there is a log from |
understood and agreed, do you have ANY contact on the hid++ reverse engineering? I'd be happily sharing my laptop for analysis ;) |
Logitech has made available information on HID++ at https://drive.google.com/drive/u/0/folders/0BxbRzx7vEV7eWmgwazJ3NUFfQ28?resourcekey=0-dQ-Lx1FORQl0KAdOHQaE1A. But that, and any reverse engineering, can only find out information about HID++ messages. If the device changes behaviour without any message, then there is nothing that can be done by Solaar. The only hope would be to change something that affects the device's behaviour. |
I just noticed some weird output from |
solaar -V : solaar 1.1.14+202501291749 solaar -ddd show:
<\details> |
OK, there is some problem as indicated by the output
But that turns out to be benign and doesn't cause any problems. Nonetheless it should be fixed. |
PR #2799 should fix the problem in To clone and use Solar from its GitHub repository
Run Solaar as bin/solaar from this directory. To run PR #2799, first clone Solaar if you have not already done so and cd to the clone directory. The first time you download the pull request, fetch it into a new branch and checkout that branch, as in:
To download a new version of the pull request, fetch it and then set your pull branch to the new fetch, as in:
|
that fixed the error in the logs...
|
PR #2799 was only to fix the problem in The PR didn't actually work correctly. A true fix is going to require access to a device with lighting, which won't be possible for me until the end of the week. The problem with the reset will have to wait until after that, but you could try the following just to get another data point. Quit Solaar and then run it as |
As I don't have access to the device I need to know a bit more about it and what you have done. Is your issue that the keys change color after they become red or is it that some other lighting effect occurs? |
ok so i did a bin/solaar -ddd which outputs heavily, then turned off and on the keyboard which activates the desired led configuration, after some time (its really not predictable, sometimes its just 5 secs, this time it was a minute) it falls back to the default (i think power saving) mode which is a blue wave led config with "wasd" being pinky color. There is no output in the console for the time this happens :( |
There are two features that control LEDs on the device
with three settings: LED Control, LEDs Primary, and Per-key Lighting. I had thought that the first feature was involved, but it looks as if the problem is with the second. I don't see anything related to PER KEY LIGHTING V2 that could be causing the lighting to be reset. Part of the problem is that there is no way to read the current state of PER KEY LIGHTING and there is no signalling from the device to Solaar related to PER KEY LIGHTING. One thing I can think of is that there is an interaction between the two features, so try changing the LEDs Primary setting to something else and see what changes, if anything. The other is that there is some sort of demo mode for the device and that is overriding settings but there is no documentation for anything like this. The only other thing to try is to attach the device to a Windows machine, run the Logitech software for it, and see how the device works there. |
removed the per key setup and used a simple static yellow led setup, but same behaviour, after some time it resorts to the "demo power saving" mode. Last resort i will try it on a windows machine and see if it works there |
I have the same problem that after a certain time the power saving mode is activated and the RGB mode selected by Solaar is deactivated. Output of
|
@crian Is this the color of the keys, or the color of some other LEDs? Also, please try with PR #2799. If the problem persists, quit out of Solaar and run it as To clone and use Solar from its GitHub repository
Run Solaar as bin/solaar from this directory. To run PR #2799, first clone Solaar if you have not already done so and cd to the clone directory. The first time you download the pull request, fetch it into a new branch and checkout that branch, as in:
To download a new version of the pull request, fetch it and then set your pull branch to the new fetch, as in:
|
I will test it later. |
@pfps I reseted the keyboard to the default settings in GHub and tested it with the PR. In GHub, you can disable the idle effect. Here is the output auf
|
@crian but that approach (deactivate idle and save profile on board) means that solaar does not do anything right? |
OK, maybe there is something special going on with an idle state. I haven't seen this behaviour before. The issue is going to be how to deactivate the idle state as I don't have any information on this at all. |
@pfps I've never owned a keyboard with Ghub before. Is this idle feature something new? Edit: When I did a Google search for this problem, I found this: https://gist.github.com/Elijas/abd2d61f8789cd3ed6d357a297411dd8 And on openrgb I've found this: https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/4238 @eitzenbe It's not that complicated. Create a new profile in Ghub and then select your RGB settings. You can then load this profile into the onboard memory. |
Yeah but i wanted no effect and only customised colouring of keys... This works on board on windows, but on solaar / Linux the keyboard turns dark if effect is turned off in the profile |
New devices have newer features, which tend to be more complex than older ones. I don' t know how many devices have this capability or when it was introduced. |
Looking at various bits of documentation and extrapolating from your experience it appears that the G515 (and maybe similar keyboards) have an interaction between two features. Per key lighting sets up the colours for the keys. RGB Effects is in charge of power saving behaviour. So when the device is active the keys follow the behaviour for per key lighting but when the device is in power saving mode the keys follow behaviour in rgb effects, but not a behaviour that Solaar currently controls or sees. A partial solution would be to just prevent the device from going into power saving mode, or delay going into power saving mode. That would require a new Solaar setting. A full solution would add control of power-saving lighting. Implementing either in Solaar is going to require a bit of programming but also potentially several interactions with someone who has the device. If either of you are willing to test out patches to Solaar both can be done. |
I'm happy to help you with testing. That's not a problem. I assume that all newer Logitech keyboards support this idle feature. This can also be seen on screenshots from GHub of the G915X models. In idle mode you can set a separate RGB effect in GHub. You can also dim the lighting to x% after x minutes. |
Happy to provide alpha test environment ;)
17.02.2025 17:22:19 Christian S. ***@***.***>:
…
[Bild][crian][https://avatars.githubusercontent.com/u/5225319?s=20&v=4]*crian* left a comment (pwr-Solaar/Solaar#2791)[#2791 (comment)]
I'm happy to help you with testing. That's not a problem.
I assume that all newer Logitech keyboards support this idle feature. This can also be seen on screenshots from GHub of the G915X models.
In idle mode you can set a separate RGB effect in GHub. You can also dim the lighting to x% after x minutes.
Strangely enough, these features are not supported by an onboard profile. That's why Solar has no problems when using one.
—
Reply to this email directly, view it on GitHub[#2791 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/ABKNTSFNDIOQ3ICUQLSSJTD2QIEDNAVCNFSM6AAAAABWDC35JOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRTGU3TMMJTGM].
You are receiving this because you were mentioned.
|
Information
Solaar version: solaar 1.1.13+dfsg-1
Distribution: Kubuntu 24.10
Kernel version: Linux 6.11.0-9-generic x86_64 GNU/Linux
Output of solaar show:
2025-01-29 14:44:39,112,112 ERROR [MainThread] logitech_receiver.base: (16) device 1 error on feature request {09EA}:
7 = invalid function
Describe the bug
i have configured single key led colors and they appear on keyboard but after some time (differing from 5 to 60 seconds) the keyboards "falls back" to the default blue breathing color mode
To Reproduce
Steps to reproduce the behavior:
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Happy to beta test any dev version
The text was updated successfully, but these errors were encountered: