search

pwr-Solaar / Solaar

Linux device manager for Logitech devices
https://pwr-solaar.github.io/Solaar
GNU General Public License v2.0
5.38k stars 401 forks source link

Slow scrolling with mouse #1433

Closed GASOLINE closed 2 years ago

GASOLINE commented 2 years ago

Since the last update (1.1.1, Fedora 35) the slow scrolling with mouse is back when PC comes back from sleep.

pfps commented 2 years ago

Have you taken the action in the "Known Issues"?

GASOLINE commented 2 years ago

Have you taken the action in the "Known Issues"?

* Some Linux drivers view or modify the setting Scroll Wheel Resolution to implement smooth scrolling. If Solaar changes this setting after the driver is set up scrolling can be either very fast or very slow. To fix this problem click on the icon at the right edge of the setting to set it to "Ignore this setting". The mouse has to be reset (e.g., by turning it off and on again) before this fix will take effect.

Does not make a difference.

pfps commented 2 years ago

Please provide ouput of `solaar show' and a screenshot of the Solaar main window with the mouse settings showing.

GASOLINE commented 2 years ago

Please provide ouput of `solaar show' and a screenshot of the Solaar main window with the mouse settings showing.

As requeste solar.txt solar d

pfps commented 2 years ago

The output of solaar show indicates that the scroll wheel is in the high-resolution state. So there does not appear to be anything that Solaar can influence that would be causing slow scrolling.

A couple of things to do to see whether Solaar is causing the problem.

Quit out of Solaar. Turn the mouse off for a few seconds and then back on again. Is scrolling still slow? If not, does starting Solaar make the mouse slow? If not, then Solaar is not likely the cause of the slowness. If so, then Solaar might be the cause and more analysis need to be done.

Was scrolling still slow when the mouse was turned on? This would normally indicate that there is something wrong with how the mouse is handled. However it appears that recent versions of Fedora do not completely tear down connections to peripherals when they go off-line. You should make sure that Solaar is not being autostarted and then reboot your system. While the system is rebooting turn the mouse off and on again. If the problem persists then Solaar can't be the cause. If the problem went away then start up Solaar. If the problem comes back then Solaar is likely a cause and more analysis will have to be done.

brintal commented 2 years ago

@pfps As requested in the other issue (https://github.com/pwr-Solaar/Solaar/issues/1061)

1.) Toggle ON - before Power OFF When the toggle was just turned ON through the GUI, everything works fine. Scroll Wheel is fast enough and behaves exactly as configured in the GUI. togglON_beforePowerOff togglON_beforePowerOff.txt

2.) Toggle ON - after Power OFF After the physical power button of the MX Master 2S was turned off and on again, the scroll wheel speed is wrong (very slow). Scroll Wheel resolution set in the GUI is NOT applied anymore. The output of solaar show shows "Low resolution mode" although the Switch in the GUI is still set to ON. togglON_afterPowerOff togglON_afterPowerOff.txt

3.) Toggle IGNORE - before Power OFF The IGNORE setting in the GUI doesn't really change anything. As long as the switch was set to ON beforehand, the scroll wheel continues to behave correctly even though IGNORE is selected. Also solaar show still shows "High resolution mode" togglIGNORE_beforePowerOff togglIGNORE_beforePowerOff.txt

4.) Toggle IGNORE - after Power OFF After physically switching the mouse off and on again, the same undesirable result: slow wheel scrolling speed. The (disabled) switch on the GUI is still in ON-position and the solaar show output states "Low resolution mode" togglIGNORE_afterPowerOff togglIGNORE_afterPowerOff.txt

Hence there is a clear mismatch between what is shown in the GUI and the output of solaar show.

One more observation: After the physical switch was turned off and on again, the scroll speed behaves wrong. Just closing the solaar window and opening it again does not do anything, the error persists even though the switch is set to the ON position. BUT: If I explicitly click on "Quit Solaar" and open the application again, then the scroll speed works again!

solaar -ddd does not yield anything except this (then the GUI opens):

─$ solaar -ddd                                                                                                 130 ↵
15:13:20,787     INFO [MainThread] root: language en_US (UTF-8), translations path None
15:13:20,987    DEBUG [MainThread] logitech_receiver.diversion: rule Key assuming action "pressed" for "Brightness Down"
15:13:20,987    DEBUG [MainThread] logitech_receiver.diversion: rule Key assuming action "pressed" for "Brightness Up"
15:13:20,991    DEBUG [MainThread] solaar.ui.tray: using Ayatana AppIndicator3
15:13:20,998     INFO [MainThread] solaar.upower: connected to system dbus, watching for suspend/resume events
brintal commented 2 years ago

Another find:

Apparently the values configured in solaar get applied again, by running solaar config 1 on the command line (1 being the device ID from the solaar show output). Dumping the following in /etc/crontab seems to be an acceptable workaround for me: image So far I didn't notice any negative sideffects except that it might take up to 1 minute after waking up the computer for the scrollwheel to work correctly. But that is so much better than always having to open the solaar GUI and toggle the switch off and on again.

pfps commented 2 years ago

The Solaar GUI is a persistent application. What is needed to see what is going on is first quitting out of Solaar and then running with -ddd. This will produce a lot of ouput - the useful part is what is output around the time the problem occurs.

brintal commented 2 years ago

Sorry, before I tried to start solaar -ddd while another solar instance was running in the background. There wasn't any output then.

Now I shut down Solaar completely, let it run with solaar -ddd and then reproduced the error. The log: debug.txt

At 16:32:20 the mouse was turned off with the physical off switch At 16:32:25 it was turned back on. The output after that was just me moving and scrolling to verify the reproduction of the error. Btw: I can consistently reproduce the issue. It doesn't seem to be a race condition in my case.

pfps commented 2 years ago

TL;DR: Solaar appears to have both wheel settings in non-ignore mode. Please try with resolution in ignore mode. In any case it appears that Solaar (this Solaar process anyway) isn't modifying the wheel resolution when the mouse is turned on.

Interaction with Logitech devices is by command type, device number, offset, and command. The commands are (roughly) 0 - capabilities, 1 - get state, and 2 - set state.

The command type is 11. Your MX is device 01. The HiRes Wheel feature on your MX is offset 0E. So communication with that feature is shown in the log as 11 01 0E. The next two hex digits are the command and a number to pair up commands and replies.

Responses from the MX to commands from other programs or spontaneous messages from the MX.

16:32:05,396    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E20 02000000000000000000000000000000]

Probably the reponse to a command asking for wheel status.

16:32:05,438    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E10 02000000000000000000000000000000]

Probably the reponse to a command asking for wheel capabilities

16:32:05,446    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E00 080C0000000000000000000000000000]
16:32:05,462    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E20 10000000000000000000000000000000]

Solaar asks for the state of the HiRes Wheel (for direction setting):

16:32:06,157    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) <= w[11 01 0E1E 00000000000000000000000000000000]

The MX says low resolution and not inverted.

16:32:06,176    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E1E 00000000000000000000000000000000]

Solaar again asks for the state of the HiRes Wheel (for the resolution setting):

16:32:06,197    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) <= w[11 01 0E1B 00000000000000000000000000000000]

The MX says low resolution and not inverted.

16:32:06,216    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E1B 00000000000000000000000000000000]

Solaar commands the device to change to high resolution and not inverted.

16:32:06,216    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) <= w[11 01 0E2C 02000000000000000000000000000000]

The MX says it changed to high resolution and not inverted.

16:32:06,236    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E2C 02000000000000000000000000000000]

Solaar asks for the state of the HiRes Wheel (for direction setting):

16:32:25,729    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) <= w[11 01 0E1F 00000000000000000000000000000000]

The MX says low resolution and not inverted.

16:32:25,744    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E1F 00000000000000000000000000000000]

This appears to be a response to some other program setting the HiRes Wheel to high resolution. Solaar does not get to see the command.

16:32:25,752    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E20 02000000000000000000000000000000]

Solaar again asks for the state of the HiRes Wheel (for the resolution setting):

16:32:25,763    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) <= w[11 01 0E19 00000000000000000000000000000000]

The MX says high resolution and not inverted.

16:32:25,778    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E19 02000000000000000000000000000000]

More responses from the MX to commands from other programs or spontaneous messages from the MX. Probably the reponse to a command asking for wheel capabilities

16:32:25,786    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E00 080C0000000000000000000000000000]
16:32:25,866    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E10 00000000000000000000000000000000]
16:32:25,882    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E20 10000000000000000000000000000000]

Probably the reponse to a command from Solaar asking for wheel status.

16:32:26,109    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (18) => r[11 01 0E1F 00000000000000000000000000000000]

Probably the reponse to a command to set high resolution mode.

16:32:26,109    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (18) => r[11 01 0E20 02000000000000000000000000000000]

Probably the reponse to a command from Solaar asking for wheel status.

16:32:26,112    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (18) => r[11 01 0E19 02000000000000000000000000000000]

Probably the reponse to a command asking for wheel capabilities

16:32:26,112    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (18) => r[11 01 0E00 080C0000000000000000000000000000]
16:32:26,118    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (18) => r[11 01 0E10 00000000000000000000000000000000]
16:32:26,120    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (18) => r[11 01 0E20 10000000000000000000000000000000]

This looks like a case where neither setting is on ignore (because otherwise Solaar would not ask for the current state). Please try again with the resolution setting on ignore.

There is also some other program changing the setings. It looks as if the input driver is doing some changing. The other program is sending commands that make it hard to figure out what is going on

brintal commented 2 years ago

I did the same steps with the switch on ignore: debug_ignore.txt 21:30:25 -> power off 21:30:30 -> power on

pfps commented 2 years ago

In this log Solaar is only sending two commands to the device. Both of them are asking for information and do not set anything on the device. Something else appears to changing the scroll wheel resolution. (It is hard to determine precisely what is going on as this other program appears to be sending commands that make responses look like spontaneous notifications.)

My belief is that some other program is misbehaving. The only other possibility I can see is that the device is misbehaving.

The relevant interactions with the device are shown below. The first two lines are Solaar asking for the state of the wheel. The next lines are responses or notifications from the device. The sequence is likely as follows:

21:30:30,768    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E20 02000000000000000000000000000000]
21:30:30,800    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E00 080C0000000000000000000000000000]
21:30:30,872    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E10 00000000000000000000000000000000]
21:30:30,888    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (19) => r[11 01 0E20 10000000000000000000000000000000]
21:30:31,115    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (18) => r[11 01 0E1E 00000000000000000000000000000000]
21:30:31,115    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (18) => r[11 01 0E20 02000000000000000000000000000000]
21:30:31,116    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (18) => r[11 01 0E00 080C0000000000000000000000000000]
21:30:31,123    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (18) => r[11 01 0E10 00000000000000000000000000000000]
21:30:31,125    DEBUG [ReceiverListener:hidraw4] logitech_receiver.base: (18) => r[11 01 0E20 10000000000000000000000000000000]
pfps commented 2 years ago

You could try setting both scroll wheel settings to ignore and see if the problem persists. If so, you could try not having Solaar running at all and see if the problem persists.

brintal commented 2 years ago

I think there is a misunderstanding (probably on my part). why would disabling the very feature which I want to work consistently, change anything for the better? The whole reason for me using solaar is because the scroll speed was so slow before. Slow scrolling speed is apparently the "default" behavior with my setup. Solaar is fixing that issue for me. Just not reliably enough.

pfps commented 2 years ago

Some modern input drivers implement what is called smooth scrolling. They do this by determining the device capabilities and modifying the scrolling resolution on some devices. If both Solaar and the driver are reading and modifying the resolution there is the possibility of something going wrong. (I can't be more precise here because I don't know the internal logic of the driver.) This is the reason for the ignore capability in Solaar.

GASOLINE commented 2 years ago

Another find:

Apparently the values configured in solaar get applied again, by running solaar config 1 on the command line (1 being the device ID from the solaar show output). Dumping the following in /etc/crontab seems to be an acceptable workaround for me: image So far I didn't notice any negative sideffects except that it might take up to 1 minute after waking up the computer for the scrollwheel to work correctly. But that is so much better than always having to open the solaar GUI and toggle the switch off and on again.

solaar config 1 in my crontab did the trick for me. Thanks.

pfps commented 2 years ago

OK, I guess.

brintal commented 2 years ago

I don't see how this issue is resolved. Yes there is a hacky workaround but IMO solaar should be able to handle that itself. Even if "something else" is the culprit, IMO solaar should be smart enough to make sure its configured settings are actually applied. There are several issues on this topic now and it's very clear it happens in a variety of systems.

Is it not possible to have some kind of hook executed on the mouse wakeup event and then monitoring the state for a while to make sure the settings are applied and, if necessary, reapplied of another process messes up the settings.

pfps commented 2 years ago

This does not seem to be possible. Some input drivers examine and modify the scroll wheel resolution. It is currently unknown when they do this and what they do with the information they get. In this state of affairs all that Solaar can do is get out of the way.

You could, if you want, try to figure out what the drivers or other processes are doing and try to figure out why things are going wrong when Solaar is not running. But the next step is not to get Solaar to fix up the problem. The next step is to fix the driver or other process.

horrovac commented 6 months ago

Sorry if this is necrobumping, but I have another hacky workaround for this: what resets the scroll wheel speed seems to be the kernel module hid_logitech_hidpp (the HID++ module). Removing this module and blacklisting it seems to have solved the issue for me for the time being.