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
solaar doesn't apply settings #855
Comments
Line 177 is a CHANGE_HOST request to change hosts (hopefully to the current host). But it may be that any CHANGE_HOST request causes the device to try to change hosts, which may take a while, so some requests may be lost, which is causing the timeout and may be causing the other problems. |
PR #856 likely fixes this problem. Please give it a try. To run PR #856, 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, pull it into your branch for the request, as in:
|
That does the trick. No more timeouts and the settings are applied correctly to the devices. I have a side-question on the CHANGE_HOST feature: As you see in my screenshot above, the Change Host choice is empty. This is still the case with PR #856. If I select the current host in the menu, the mouse reconnects and then again is in a state where the GUI shows correct settings but the mouse doesn't act like it. Is that expected behaviour? |
@lukasmichel No, that's not expected behaviour. The current value should show, but that may not be specific to CHANGE_HOST. I expect that the problem with selecting the current host is the same as the problem you encountered previously - changing to the current host causes the mouse to not respond for a while. I'll see what can be done about both of these, but I may need your help to further diagnose the problems. |
Sure, I can help with that. |
There is a new version of #856 that should fix the remaining problems reported here. |
It's better than before, but not completely fixed. The current host is now selected on solaar startup and selecting it in the drop-down menu doesn't try to reconnect, so that's fine. |
I just made a few more tests. It does not always happen that the settings are not applied in that scenario.
|
This exposes a problem with the underlying model of settings in Solaar that needs a slight upgrade to keep track of the device value and the Solaar value so that the device value is not written too often. I'll work on a fix. |
It turns out that there was a simple fix (or at least that what it looks like to me). Please try out the newest version of PR #856 The problem was that the Solaar GUI had the "other host" value for CHANGE_HOST and when the "this host" value was read from the device the GUI wrote it back, which may have been causing problems. But there is a situation that still might be problematic. If you switch back and forth too fast, the receiver may not notice that the mouse was disconnected and that its values might have changed. After each host switch away and back there should be a debug line like |
@lukasmichel Have you had a chance to test the latest version of the PR? |
I just tested it. Everything looks fine. Changing between two hosts in quick succession is fine and trying to change to an offline host also works now. I also saw the debug line you mentioned above in the debug output. |
Excellent, thanks. |
Information
uname -srmo
):Linux 5.7.8-arch1-1 x86_64 GNU/Linux
solaar -d show
:Describe the bug
Since the implementation of the feature CHANGE_HOST in 5a4205d, solaar doesn't apply the persistent settings correctly to the mouse (tested with MX Master 2S and MX Anywhere 2) anymore, e.g. the DPI are not set correctly and button remappings are not executed. The GUI shows the correct values, but the mouse does not behave like when set with those values. When changing the settings from the GUI works fine.
Additionally, solaar takes longer to start up than before.There is a delay between showing the GUI and listing the devices, a delay after recognition of each devices and an additional delay until battery info is available.
To Reproduce
Steps to reproduce the behavior:
Screenshots
Screenshot of the solaar GUI
Additional context
solaar -dd
for g1c2b347 (the last working version): https://gist.github.com/lukasmichel/aa69434d6182685f854a532a3d2f1c17solaar -dd
for gde0894b: https://gist.github.com/lukasmichel/a1686324925a49108e6d97deb42e8211Please note the delay after line 181 and line 330
Other than that, I don't know where to look for the described bug.
The text was updated successfully, but these errors were encountered: