search

pwr-Solaar / Solaar

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

After wake up mouse scroll is slow #1061

Closed GASOLINE closed 3 years ago

GASOLINE commented 3 years ago

Information



**Describe the bug**
After wake up from PC (Fedora 33 in my case) the scrolling is slow. It does this already for few versions of Fedora. When I start pairing in Solaar and immediatly stop pairing the mousescrolling is back at it's original speed.

**To Reproduce**
Steps to reproduce the behavior:
See above
pfps commented 3 years ago

This appears to be a bug that has recently been fixed (but I can't seem to find the original issue). Try cloning Solaar from this repository and running Solaar from the clone directory (as bin/Solaar). For more information see https://pwr-solaar.github.io/Solaar/installation

GASOLINE commented 3 years ago

This appears to be a bug that has recently been fixed (but I can't seem to find the original issue). Try cloning Solaar from this repository and running Solaar from the clone directory (as bin/Soaar). For more information see https://pwr-solaar.github.io/Solaar/installation

Thanks, I'll give that a try.

gwm commented 3 years ago

just found this issue, and a "metoo" on Ubuntu 20.10. I can't reliably reproduce this (it does not happen on every wakeup) but occasionally my MX Master 3 scroll goes slow. The mitigation in my case is to toggle the "Wheel Resolution" switch in Solaar off and then on again. Annoying and if I find a reliable reproducer I'll let you know.

pfps commented 3 years ago

My belief is that the problem happens when the mouse turns itself "off" and all current settings are lost. Older versions of Solaar did not correctly re-initialize the mouse so its settings remain at their default until changed in Solaar.

This problem should be fixed in the version of Solaar in this repository. See above for a pointer to how to install this version.

pfps commented 3 years ago

Is the problem active in the current version of Solaar from this repository?

gwm commented 3 years ago

I will test.

gwm commented 3 years ago

I've installed an update from solaar git ppa repo going from 1.0.2 to 1.0.4...

I will run with this for the rest of the week to see if the problem occurs.

pfps commented 3 years ago

The problem is easily checkable. Just power your mouse off and on again. If it comes back slow, then the problem is still active, otherwise not. You can make the problem very obvious by changing your dpi to something like 4000 before powering off.

pfps commented 3 years ago

The commit that fixes this problem is from 22 November 2020.

skitt commented 3 years ago

The commit that fixes this problem is from 22 November 2020.

That would be https://github.com/pwr-Solaar/Solaar/commit/808a7198234c62566da33b22f8fcbfc8a1fe9c2b, right?

pfps commented 3 years ago

Yes, that's the change.

thx1111 commented 3 years ago

Testing this on Arch Linux, I have tried 1.0.5rc2.r0.g8d01e28-1 from 2021 Feb 20

On a Logitech M525 mouse, first changing the scroll rate with solaar config xxxxxxxx hi-res-scroll true, confirming the faster scroll rate, and the configuration setting, then turning the mouse off, then back on, I find the scroll rate is reverted to the slower rate.

And, if I just wait long enough for the mouse to time-out and go "offline", when I move the mouse again, the scroll rate will also have reverted to the slower rate.

However, if I subsequently run only solaar config xxxxxxxx, the faster scroll rate is enabled, without actually specifying the setting or the value.

$ solaar config xxxxxxxx
Wireless Mouse M525 (M525) [4013:xxxxxxxx]

# Scroll Wheel High Resolution
# High-sensitivity mode for vertical scroll with the wheel.
#   possible values: on/true/t/yes/y/1 or off/false/f/no/n/0
hi-res-scroll = True

I suppose that the config routine is not being run automatically when the mouse powers on. Should it be? Does the Unifying Receiver actually detect that the mouse has just powered on? Is there some additional parameter on this mouse that needs to be configured to have it configured automatically?

GASOLINE commented 3 years ago

My belief is that the problem happens when the mouse turns itself "off" and all current settings are lost. Older versions of Solaar did not correctly re-initialize the mouse so its settings remain at their default until changed in Solaar.

This problem should be fixed in the version of Solaar in this repository. See above for a pointer to how to install this version.

I already have the latest version via Fedora 33. I'll wait for version 1.0.5.

pfps commented 3 years ago

In the currrent version (1.0.5rc2) or from this repository, the GUI version of Solaar should correctly set up and maintain the mouse speed. If you are only running the GUI and the mouse speed becomes slow after the mouse has not been used for a while, then this is an unknown bug. To diagnose it, please run Solaar as bin/solaar -d and post the output around the time that the mouse powers on.

If you just run solaar config then what happens is that the saved configuration is first pushed to the mouse, then the setting change is performed, and finally the saved configuration is updated. When the mouse powers down it forgets all of these changed settings. (There are some settings that persist, but I expect the M525 doesn't have any of these settings.) The receiver does not store the changed settings either. This is a hardware feature that can only be overcome by running some software that applies the changed settings whenever the mouse wakes up, such as Solaar.

If you want to have the changed settings applied automatically without having the Solaar GUI running, you will have to arrange to run solaar config xxx whenever the mouse wakes up.

pfps commented 3 years ago

@GASOLINE It would probably be useful for you to try the current version of Solaar from this repository to check that your problem is indeed fixed. Otherwise, version 1.0.5 might not fix your problem. You should be able to install 1.0.5rc2 temporarily by simply running pip install --user solaar==1.0.5rc2. Then run Solaar via ~/.local/bin/solaar (after killing any running Solaar process). To remove this version of Solaar just run pip uninstall solaar.

GASOLINE commented 3 years ago

@GASOLINE It would probably be useful for you to try the current version of Solaar from this repository to check that your problem is indeed fixed. Otherwise, version 1.0.5 might not fix your problem. You should be able to install 1.0.5rc2 temporarily by simply running pip install --user solaar==1.0.5rc2. Then run Solaar via ~/.local/bin/solaar (after killing any running Solaar process). To remove this version of Solaar just run pip uninstall solaar.

Ok, I tested Fedora package. And the 1.0.4 and 1.0.5beta version manual installed. Does not make a difference. Also tried without Solaar but than I have the exact same behaviour. So it seems related to Kernel/Fedora/XFCE ???

https://bugzilla.redhat.com/show_bug.cgi?id=1701322 (Also for MX Master 2)

pfps commented 3 years ago

I don't see how the kernel would be involved, but maybe there is something going on there.

To see whether Solaar is involved run either from this repository or some 1.0.5 version. First kill any running Solaar processes. Then run with the -d flag. If the problem occurs, paste the output from around that time.

The problem that was recently fixed is that Solaar did not correctly send all settings to devices when they reconnected after going into power-saving mode. Devices do not remember most changed settings when they go into power-saving mode so when they reconnect they are in their default mode. You can trigger this behaviour by turning your mouse off and on again.

The current version of Solaar logs this activity as a line like

... INFO [ReceiverListener:...] logitech_receiver.status: <Device(...)> pushing device settings [..., <Setting([feature:choice] ...:dpi=...)>, ...]
thx1111 commented 3 years ago

@pfps Aha! Many thanks for your thorough explanation! Then everything is working as expected for me.

A revision to the output of solaar --help, concerning the GUI, would be very helpful, for instance, to read:

  -w {show,hide,only}, --window {show,hide,only}
                        start GUI with window showing / hidden / only (no tray icon)
                        leave running to automatically reconfigure a device coming online

I expect many people would not know that, generally, the receiver and paired devices do not retain settings on power-down, or especially, even when simply sleeping. So a clue, from the "usage", should be much appreciated.

pfps commented 3 years ago

I think I'll add something to the documentation instead.

thx1111 commented 3 years ago

But then, I will say, for me, and I expect, for many people, when using a new command, the first place to look for information will be the man page - and solaar does not have a man page. And then, the next place to look for information will be "command --help".

I'm not sure what you mean by "the documentation instead", but I expect that you are referring to the online web page. Of course, all the information should be there, regardless of where else it may be found - but - that will be very tedious to discover, in comparison to simply running solaar --help. Tell me that you don't often skip reading the detailed instructions with a new toy!

Adding the term "GUI" explicitly, and then, also adding one additional line, to the usage, is not expensive. Certainly, it would have pointed me in the right direction. Otherwise, the user is left with too much uncertainty, and too many guesses.

pfps commented 3 years ago

There a lots of things that could be added to the help message. The question is where to stop. One possibility is to add a pointer to the github documentation.

thx1111 commented 3 years ago

The solaar usage verbiage should "stop" a little further along the path, with a few more clues for the user. It is not "writing a book", and it is just not expensive to add a few more words and a few more lines. Even "cryptic" is infinitely better than "silent".

You may not be able to appreciate how much you know about how solaar works. In comparison, new users simply don't know how much they don't know, and otherwise have no indication or expectation that they need to find more information.

But yes, a link to the github README.md would be ok, if the comments about needing to continuously run solaar, or equivalent, to automatically reconfigure a device coming online, are included. Alternatively, a link to the Solaar usage page may be a better choice and provide more thorough information. However, that page also needs to be revised, to include the information about continuously running solaar for automatic reconfiguration, and the fact that most receivers and devices do not keep state, and lose state when sleeping or when powered off.

gwm commented 3 years ago

ok. so with version 1.0.5rc2 I can still reproduce the issue on my MX Master 3. As mentioned before, the problem is mostly fixed in that I am not seeing slow scroll re-enabled after the mouse "sleeps" and wakes again. However, if I power off the mouse (physical switch under mouse) and power it back on, the mouse reverts to slow scroll and I need to "fix" it by toggling the "Scroll Wheel Resolution" slider on-> off-> on.

I am running the GUI. I have the the icon in the taskbar and usually have the gui open (in case I need the "fix"). I am running on Ubuntu 20.10.

Below is a paste of the output from solaar -d 

qqs43472@blue:~$ solaar -d
09:59:47,194     INFO [MainThread] root: language en_GB (UTF-8), translations path None
Solaar depends on a udev file that is not present
For more information see the Solaar installation directions
at https://pwr-solaar.github.io/Solaar/installation
09:59:47,353     INFO [MainThread] solaar.upower: connected to system dbus, watching for suspend/resume events
09:59:47,422     INFO [MainThread] solaar.ui.notify: starting desktop notifications
09:59:47,489     INFO [MainThread] solaar.listener: starting receiver listening threads
09:59:47,491     INFO [MainThread] solaar.listener: receiver event add DeviceInfo(path='/dev/hidraw4', vendor_id='046D', product_id='C52B', serial='', release=None, manufacturer=None, product=None, interface=2, driver='logitech-djreceiver', bus_id=3, isDevice=None)
09:59:47,499     INFO [ReceiverListener:hidraw4] logitech_receiver.listener: started with <UnifyingReceiver(/dev/hidraw4,20)> (20)
09:59:47,499     INFO [ReceiverListener:hidraw4] solaar.listener: <UnifyingReceiver(/dev/hidraw4,20)>: notifications listener has started (20)
09:59:47,503     INFO [ReceiverListener:hidraw4] logitech_receiver.receiver: <UnifyingReceiver(/dev/hidraw4,20)>: receiver notifications enabled => ('wireless', 'software present')
09:59:47,507     INFO [ReceiverListener:hidraw4] solaar.listener: status_changed <UnifyingReceiver(/dev/hidraw4,20)>: present, No paired devices. (0) 
09:59:47,512     INFO [ReceiverListener:hidraw4] logitech_receiver.receiver: <UnifyingReceiver(/dev/hidraw4,20)>: found new device 1 (4082)
09:59:47,512     INFO [ReceiverListener:hidraw4] solaar.listener: connection Notification(10,1,41,04,328240) for <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)> (mouse)
09:59:47,513     INFO [ReceiverListener:hidraw4] solaar.listener: status_changed <UnifyingReceiver(/dev/hidraw4,20)>: present, 1 paired device. (0) 
09:59:48,421     INFO [ReceiverListener:hidraw4] logitech_receiver.status: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)> pushing device settings [<Setting([feature:toggle] MX Master 3:hires-smooth-invert=None)>, <Setting([feature:toggle] MX Master 3:hires-smooth-resolution=None)>, <Setting([feature:range] MX Master 3:smart-shift=None)>, <Setting([feature:toggle] MX Master 3:thumb-scroll-mode=None)>, <Setting([feature:toggle] MX Master 3:thumb-scroll-invert=None)>, <Setting([feature:choice] MX Master 3:dpi=None)>, <Setting([feature:map choice] MX Master 3:reprogrammable-keys=None)>, <Setting([feature:map choice] MX Master 3:divert-keys=None)>, <Setting([feature:choice] MX Master 3:change-host=None)>]
09:59:48,945     INFO [ReceiverListener:hidraw4] solaar.listener: status_changed <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: paired online, {'LINK ENCRYPTED': True, 'BATTERY LEVEL': 100, 'BATTERY STATUS': NamedInt(0, 'discharging'), 'BATTERY NEXT LEVEL': 50, 'BATTERY VOLTAGE': None, 'BATTERY CHARGING': False, 'ERROR': None} (0) 
09:59:48,946     INFO [ReceiverListener:hidraw4] solaar.listener: status_changed <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: paired online, {'LINK ENCRYPTED': True, 'BATTERY LEVEL': 100, 'BATTERY STATUS': NamedInt(0, 'discharging'), 'BATTERY NEXT LEVEL': 50, 'BATTERY VOLTAGE': None, 'BATTERY CHARGING': False, 'ERROR': None} (0) 
09:59:48,947     INFO [ReceiverListener:hidraw4] logitech_receiver.notifications: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: spurious BATTERY status Notification(11,1,08,10,0404C078050000000000000000000000)
09:59:48,966  WARNING [ReceiverListener:hidraw4] logitech_receiver.notifications: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: unknown WHEEL Notification(11,1,0E,20,02000000000000000000000000000000)
09:59:48,967     INFO [ReceiverListener:hidraw4] logitech_receiver.notifications: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: WHEEL: ratchet: 0
09:59:48,967     INFO [ReceiverListener:hidraw4] logitech_receiver.notifications: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: WHEEL: res: 0 periods: 15 delta V:7192
09:59:48,968  WARNING [ReceiverListener:hidraw4] logitech_receiver.notifications: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: unknown WHEEL Notification(11,1,0E,20,D0000000000000000000000000000000)
09:59:59,336     INFO [ReceiverListener:hidraw4] solaar.listener: connection Notification(10,1,41,04,728240) for <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)> (mouse)
09:59:59,336     INFO [ReceiverListener:hidraw4] solaar.listener: status_changed <UnifyingReceiver(/dev/hidraw4,20)>: present, 1 paired device. (0) 
09:59:59,337     INFO [ReceiverListener:hidraw4] solaar.listener: status_changed <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: paired offline, {'BATTERY LEVEL': 100} (0) 
09:59:59,338     INFO [ReceiverListener:hidraw4] logitech_receiver.notifications: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: DJ connection: False Notification(20,1,42,01,0000000000000000000000)
09:59:59,340     INFO [ReceiverListener:hidraw4] solaar.listener: status_changed <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: paired offline, {'BATTERY LEVEL': 100} (0) disconnected
10:00:03,186     INFO [ReceiverListener:hidraw4] solaar.listener: connection Notification(10,1,41,04,B28240) for <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)> (mouse)
10:00:03,186     INFO [ReceiverListener:hidraw4] solaar.listener: status_changed <UnifyingReceiver(/dev/hidraw4,20)>: present, 1 paired device. (0) 
10:00:03,187     INFO [ReceiverListener:hidraw4] logitech_receiver.status: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)> pushing device settings [<Setting([feature:toggle] MX Master 3:hires-smooth-invert=False)>, <Setting([feature:toggle] MX Master 3:hires-smooth-resolution=True)>, <Setting([feature:range] MX Master 3:smart-shift=5)>, <Setting([feature:toggle] MX Master 3:thumb-scroll-mode=False)>, <Setting([feature:toggle] MX Master 3:thumb-scroll-invert=False)>, <Setting([feature:choice] MX Master 3:dpi=1000)>, <Setting([feature:map choice] MX Master 3:reprogrammable-keys={'195': 195, '196': 196, '80': 80, '81': 81, '82': 82, '83': 83, '86': 86})>, <Setting([feature:map choice] MX Master 3:divert-keys={'195': 0, '196': 0, '215': 0, '82': 0, '83': 0, '86': 0})>, <Setting([feature:choice] MX Master 3:change-host=1:blue)>]
10:00:03,728     INFO [ReceiverListener:hidraw4] solaar.listener: status_changed <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: paired online, {'BATTERY LEVEL': 100, 'LINK ENCRYPTED': True, 'BATTERY STATUS': NamedInt(0, 'discharging'), 'BATTERY NEXT LEVEL': 50, 'BATTERY VOLTAGE': None, 'BATTERY CHARGING': False, 'ERROR': None} (0) 
10:00:03,728     INFO [ReceiverListener:hidraw4] solaar.listener: status_changed <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: paired online, {'BATTERY LEVEL': 100, 'LINK ENCRYPTED': True, 'BATTERY STATUS': NamedInt(0, 'discharging'), 'BATTERY NEXT LEVEL': 50, 'BATTERY VOLTAGE': None, 'BATTERY CHARGING': False, 'ERROR': None} (0) 
10:00:03,729     INFO [ReceiverListener:hidraw4] logitech_receiver.notifications: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: DJ connection: True Notification(20,1,42,00,0000000000000000000000)
10:00:03,730     INFO [ReceiverListener:hidraw4] solaar.listener: status_changed <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: paired online, {'BATTERY LEVEL': 100, 'LINK ENCRYPTED': True, 'BATTERY STATUS': NamedInt(0, 'discharging'), 'BATTERY NEXT LEVEL': 50, 'BATTERY VOLTAGE': None, 'BATTERY CHARGING': False, 'ERROR': None} (0) connected
10:00:03,752     INFO [ReceiverListener:hidraw4] solaar.listener: status_changed <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: paired online, {'BATTERY LEVEL': 100, 'LINK ENCRYPTED': True, 'BATTERY STATUS': NamedInt(0, 'discharging'), 'BATTERY NEXT LEVEL': 50, 'BATTERY VOLTAGE': None, 'BATTERY CHARGING': False, 'ERROR': None} (1) powered on
10:00:03,752     INFO [ReceiverListener:hidraw4] logitech_receiver.notifications: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: spurious BATTERY status Notification(11,1,08,10,0404C078050000000000000000000000)
10:00:03,752  WARNING [ReceiverListener:hidraw4] logitech_receiver.notifications: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: unknown WHEEL Notification(11,1,0E,20,02000000000000000000000000000000)
10:00:03,752     INFO [ReceiverListener:hidraw4] logitech_receiver.notifications: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: WHEEL: res: 0 periods: 15 delta V:7192
10:00:03,753     INFO [ReceiverListener:hidraw4] logitech_receiver.notifications: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: WHEEL: ratchet: 0
10:00:03,753  WARNING [ReceiverListener:hidraw4] logitech_receiver.notifications: <Device(1,4082,MX Master 3 Wireless Mouse,C6CBE828)>: unknown WHEEL Notification(11,1,0E,20,D0000000000000000000000000000000)
^CThread 0x00007f90964e6640 (most recent call first):
  File "/usr/share/solaar/lib/hidapi/udev.py", line 357 in read
  File "/usr/share/solaar/lib/logitech_receiver/base.py", line 267 in _read
  File "/usr/share/solaar/lib/logitech_receiver/base.py", line 238 in read
  File "/usr/share/solaar/lib/logitech_receiver/listener.py", line 177 in run
  File "/usr/lib/python3.8/threading.py", line 932 in _bootstrap_inner
  File "/usr/lib/python3.8/threading.py", line 890 in _bootstrap

Thread 0x00007f90aa4f5640 (most recent call first):
  File "/usr/lib/python3.8/threading.py", line 302 in wait
  File "/usr/lib/python3.8/queue.py", line 170 in get
  File "/usr/share/solaar/lib/solaar/tasks.py", line 62 in run
  File "/usr/lib/python3.8/threading.py", line 932 in _bootstrap_inner
  File "/usr/lib/python3.8/threading.py", line 890 in _bootstrap

Thread 0x00007f90ab1b7640 (most recent call first):
  File "/usr/lib/python3/dist-packages/Xlib/protocol/display.py", line 561 in send_and_recv
  File "/usr/lib/python3/dist-packages/Xlib/protocol/rq.py", line 1381 in reply
  File "/usr/lib/python3/dist-packages/Xlib/protocol/rq.py", line 1369 in __init__
  File "/usr/lib/python3/dist-packages/Xlib/ext/record.py", line 220 in __init__
  File "/usr/lib/python3/dist-packages/Xlib/ext/record.py", line 239 in enable_context

Thread 0x00007f90ab9f8640 (most recent call first):
  File "/usr/lib/python3/dist-packages/Xlib/protocol/display.py", line 561 in send_and_recv
  File "/usr/lib/python3/dist-packages/Xlib/protocol/display.py", line 217 in next_event
  File "/usr/lib/python3/dist-packages/Xlib/display.py", line 187 in next_event
  File "/usr/share/solaar/lib/logitech_receiver/diversion.py", line 82 in determine_active_program

Current thread 0x00007f90bcd4d740 (most recent call first):
  File "/usr/share/solaar/lib/solaar/gtk.py", line 123 in _handlesigint
  File "/usr/lib/python3/dist-packages/gi/_ossighelper.py", line 92 in signal_notify
  File "/usr/lib/python3/dist-packages/gi/overrides/Gio.py", line 43 in run
  File "/usr/share/solaar/lib/solaar/ui/__init__.py", line 158 in run_loop
  File "/usr/share/solaar/lib/solaar/gtk.py", line 168 in main
  File "/usr/bin/solaar", line 60 in <module>
solaar: exit due to keyboard interrupt
pfps commented 3 years ago

I have the same mouse, but I'm not experiencing the same problems. But I am seeing indications that some driver is trying to set the hires scroll mode. Fortunately in Fedora it is being set to hires, not lowres. I tried setting to scrolling lowres in Solaar and turning the mouse off and on and, yes, it came back in hires mode. Looking at the detailed trace on my machine, Solaar first set it to lowres mode and then something else set it to hires mode.

So the problem is that some driver (or some other software, but probably a driver) is fiddling with the scroll resolution. I have no idea where this is being done and no idea of how to change it.

@FFY00 Do you know what software is changing the scroll resolution of the MX Master 3 mice and how to control it?

gwm commented 3 years ago

anecdotally, I think 1.0.5rc2 is a bit worse for this than 1.0.4. I've noticed this behaviour a couple times now when mouse wakes up from sleep.

pfps commented 3 years ago

As far as I can tell, Solaar isn't involved at all in this issue, except that it is timing related, i.e., both Solaar and some other piece of software are modifying and the last one wins. If 1.0.5rc2 is faster, then it will loose more often.

FFY00 commented 3 years ago

@FFY00 Do you know what software is changing the scroll resolution of the MX Master 3 mice and how to control it?

Yes, the kernel. My suggestion here: don't touch anything. I have said in the past that I don't think we should be exposing this option.

pfps commented 3 years ago

One question is why Ubuntu is forcing the setting to low, resulting in very slow scrolling. But that's a question for the Ubuntu people. As there does not appear to be any Solaar involvement with this issue, I'm closing it.

thx1111 commented 3 years ago

Yes, the kernel.

Aha! Another "discoverability" failure with the Linux User Interface, and a deficiency in the Solaar documentation.

A little searching reveals "xinput" - which has its own documentation problems. For one, the leading "--" on the option names, apparently, is ignored and can be dropped, but only when only one option is being used, since most options take an argument.

So, xinput list. Then determine which xinput device ID number corresponds to which mouse you are trying to configure, when you have more than one mouse with the exact same name, by "trial and error", with xinput disable <X> and xinput enable <X>.

Look through the output of xinput list-props <X> <Y>. Try to guess which setting corresponds to the scroll rate.

Then read here, https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/merge_requests/12, and - if I understand correctly, realize that libinput provides no mechanism for setting the scroll rate.

Consider that libinput only works with X11 and Wayland, and not with the virtual terminal. gpm would need to address scroll rate setting itself but doesn't actually seem to support scrolling. Wayland does not provide device configuration utilities as a matter of policy, so no help there, no matter what configuration libinput supports. Regardless, X11 and xinput are at the mercy of libinput, which is pretty much dominated by the same people in Wayland and so suffers from the same attitudes.

Further searching and reading suggests that whatever kernel mechanism is suppose to reconfigure the scroll wheel when the mouse returns from sleep is buggy and does not always succeed.

Please, anyone who knows more about this scroll wheel setting mechanism in the kernel, please, do tell.

As far as I can tell, Solaar isn't involved at all in this issue, except that it is timing related, i.e., both Solaar and some other piece of software are modifying and the last one wins. If 1.0.5rc2 is faster, then it will loose more often.

In the meantime, when the mouse comes online, solaar might consider gratuitously configuring the mouse a second time, after a short delay, so that it always wins the timing race.

FFY00 commented 3 years ago

Aha! Another "discoverability" failure with the Linux User Interface, and a deficiency in the Solaar documentation.

The failure you mention here is simply a failure in communication between the Solaar project and the kernel upstream, as well as a lack of documentation.

Then read here, https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/merge_requests/12, and - if I understand correctly, realize that libinput provides no mechanism for setting the scroll rate.

This is parallel, this setting isn't meant to change the scaling, just to provide more resolution. See my explanation below.

Further searching and reading suggests that whatever kernel mechanism is suppose to reconfigure the scroll wheel when the mouse returns from sleep is buggy and does not always succeed.

Have you considered that perhaps you just don't understand what is going on? Instead of claiming the code is buggy... The issue right now is that Solaar overrides this setting without the kernel knowing and, naturally, the calculations done by the kernel are off.

Please, anyone who knows more about this scroll wheel setting mechanism in the kernel, please, do tell.

This HID++ feature enables us change the resolution in the mouse wheel events. It allows the kernel, as the piece of software that interprets the data(!), to tell the device to for eg. instead of reporting 8 steps per wheel rotation, to report 32 steps, if it is capable. The kernel will configure the device this way and then report 1 step for each 4 steps on the normal axis, REL_WHEEL, for backwards compatibility, and will report more steps in the high resolution axis, REL_WHEEL_HI_RES. Applications that have support for the high resolution wheel, can use REL_WHEEL_HI_RES, older applications can use REL_WHEEL.

That was a really crude explanation, you can read more information here: https://who-t.blogspot.com/2018/12/high-resolution-wheel-scrolling-on.html https://who-t.blogspot.com/2020/04/high-resolution-wheel-scrolling-in.html

In the meantime, when the mouse comes online, solaar might consider gratuitously configuring the mouse a second time, after a short delay, so that it always wins the timing race.

No, Solaar should remove this feature and let the kernel manage it itself... causing no issues to users.

thx1111 commented 3 years ago

Have you considered that perhaps you just don't understand what is going on? Instead of claiming the code is buggy...

I'm not claiming anything about the kernel, only summarizing comments that I have found from a web search of the issue. Personally, I'm not having an issue with my own mouse, as long as solaar is kept running.

No, Solaar should remove this feature and let the kernel manage it itself... causing no issues to users.

The citations that you provide are from Peter Hutterer and make reference to Wayland and libinput. In general, the Wayland community is quite hostile toward any request for, any submission of, or any outside attempt to provide, user tools for display, or other device, configuration. While I appreciate the sentiment that mouse scroll rate configuration should be handled at a low level, by the HID drivers, you have not offered a description of any user tool and procedure for actually setting or changing the mouse scroll wheel rate.

I can say, from my own work resolving a wheel rate bug in the HID driver when using an older Microsoft mouse, where very large rotations were required to produce a single wheel step response, that, when functioning properly, there is an automatic scroll wheel rate setting mechanism that will "just work", whether or not the mouse itself provides the "high resolution" wheel feature. However, as I understand, that is not the issue being discussed here. Instead, the issue seems to be the ability to reconfigure the scroll wheel rate to accommodate user preference - and then, have the setting stay that way.

If you know of some user tool and procedure for accomplishing this result, please share.

FFY00 commented 3 years ago

The citations that you provide are from Peter Hutterer and make reference to Wayland and libinput.

And? The blog posts simply explain how this mechanism work, which is what you asked.

In general, the Wayland community is quite hostile toward any request for, any submission of, or any outside attempt to provide, user tools for display, or other device, configuration.

Yes, and there is reasoning for this, if you ever bothered actually listening and/or trying to understand their side.

While I appreciate the sentiment that mouse scroll rate configuration should be handled at a low level, by the HID drivers, you have not offered a description of any user tool and procedure for actually setting or changing the mouse scroll wheel rate.

Because that shouldn't happen, user tools are not interpreting the HID data so they are not the ones that should be configuring this. What user tools could configure is scaling of wheel events, but that should happen at the higher wayland compositor level, so ask your desktop environment or windows manager for that configuration, not the low level libinput stack.

gwm commented 3 years ago

Its all very well to say that Solaar should not expose this functionality but as far as I can see it is not exposed anywhere else so if it goes from Solaar I'm left with a mouse that is permanently in low-res scroll mode. And saying it is causing no issue to users is ignoring the many users who are affected by this...

FFY00 commented 3 years ago

This functionality is not meant to be exposed to users, it is meant to be used by the drivers. The issue right now is Solaar overriding it, leaving the kernel misbehaving. Please disable the Solaar autostart and reboot your system, does the issue persist?

And saying it is causing no issue to users is ignoring the many users who are affected by this...

The only users affected by this are Solaar users.

gwm commented 3 years ago

wow. yes, and ppl use solaar because they want the functionality that isn't exposed anywhere else such as rapid scrolling... not sure why this has to be so confrontational...

FFY00 commented 3 years ago

Nobody can write software that will behave properly if users are gonna override low-level device settings that they shouldn't. The same users that are complaining about the input software being buggy and not behaving are the ones that are screwing up with the low-level device settings used by the driver. I don't know how I am able to give the requested support in these cases. If you don't want to follow the recommendations, go ahead, but there is no way we can fix the issue for you.

pfps commented 3 years ago

I'm finally seeing this issue. I'm going to remove this setting from Solaar. If this problem affects you please try PR #1128

To download and work with Solar

git clone https://github.com/pwr-Solaar/Solaar.git
cd Solaar

Run Solaar as bin/solaar from this directory.

To run PR #1128, 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:

git fetch origin pull/1128/head:pull_1128
git checkout pull_1128

To download a new version of the pull request, fetch it and then set your pull branch to the new fetch, as in:

git checkout pull_1128
git fetch origin pull/1128/head
git reset --hard FETCH_HEAD
lolautruche commented 3 years ago

Hello there :wave:

I was having the same issue and was able to "fix" it by toggling the resolution switch in Solaar. Unfortunately, with the removal of the switch, I'm no longer able to fix the problem, so I reverted to stable 1.0.5 using the stable PPA. I understand that the problem may not be in Solaar itself. However, it would be nice that we find where the problem is coming from.

In my case, using the latest git build, if I switch off my mouse, it resets to its default values, including the slow resolution. But as I cannot toggle the switch anymore, I don't know how to re-enable the "smooth resolution". Reading the thread, I understand that the problem might come from the kernel itself. Maybe the mouse firmware should be updated somehow?

Thanks for all the great work! :+1:

pfps commented 3 years ago

@lolautruche Please try out PR #1135. This adds the setting back in, which is what you need, but also allows users to tell Solaar to ignore settings, which is what users with recent Linux drivers need.

Klap-in commented 3 years ago

Is it doable to recognize that specific version of the driver, such that a special setting is maybe not needed?

pfps commented 3 years ago

It may be doable, but I don't know whether it is worthwhile.

brintal commented 2 years ago

Is there any feasible solution to this problem yet? I'm still having the issue that the scroll wheel is extremely slow after the mouse is turned off and on again. Toggling the "Scroll Wheel Resolution" switch in Solaar fixes it but I have to do this everytime my PC goes to sleep which is incredibly annoying.

I'm using Pop OS 21.10 (aka Ubuntu 21.10) with a Logitech MX Master 2S. My Solaar is Version 1.0.4 (latest one in the ubuntu repo)

pfps commented 2 years ago

The resolution should be to update to a recent version of Solaar. Solaar was enhanced to permit settings to be completely ignored, thus eliminating a race condition between Solaar and the input drivers. Try using one of the PPAs mentioned in https://github.com/pwr-Solaar/Solaar However, there is a report #1433 that this doesn't work. If you experience the problem on version 1.1.1 or above, please try the actions suggested there.

brintal commented 2 years ago

@pfps Thank you but none of that works. Is it possible to toggle that setting from the command line somehow? Then I could at least write myself a small shell script and run that automatically.

pfps commented 2 years ago

If you are seeing the problem in version 1.1.1 with scroll wheel resolution set to ignore then there is something that needs to be addressed. Please provide output of solaar show in #1433. Also run Solaar as solaar -ddd and post its output around the time that the problem occurs.

sleeksorrow commented 2 years ago

If I understood all the comments correctly you are assuming a race condition between kernel handling the resolution and solaar overwriting it without the kernel knowing. So I should not have this at all without solaar running.

But what if I have this issue without using solaar at all and have the issue? Fact is: I didn't use solaar at all and had this issue since a long time and it drives me mad. I just now look into using solaar to hopefully fix/work around this issue.

Using Logitech M720 on Unifying Receiver under Ubuntu 22.04 with kernel 5.15

pfps commented 2 years ago

It may be that there is also a problem with the way that the driver implements smooth scrolling.

What should happen is that hid_logitech_hidpp is used as the driver for your mouse. This driver checks that the mouse supports high-resolution scrolling, then turns on high-resolution scrolling, and then asks the mouse how many high-resolution scrolling units make up a regular scrolling unit. This number is passed back to the input system to implement smooth scrolling. The driver doesn't check that high-resolution scrolling stays on and also doesn't send completely correct messages to the mouse. Both of these mean that it is perilous for any other piece of software to modify the feature. I also don't think that the driver checks that the command succeeded, which can be a problem if the device is just waking up.

Some of this I only found out recently when I was thinking of rewriting the low-level part of Solaar.

sleeksorrow commented 2 years ago

Thank you for your thoughts even as this issue is officially closed. I checked and yes, module hid_logitech_hidpp is loaded, so I guess your assumptions are correct. I understand that changing this hires scrolling setting in solaar without the kernel knowing is dangerous, but only under the assumption that kernels setting and reality are matching. And in this case, it seems it's not, after some reconnects the setting is not what the kernel thinks it is. So the problem already exists and solaar might just be able to correct the setting to what the kernel thinks is active.

I understand very well that from a developers point of view it's quite some dirty hack if solaar corrects the setting, because two wrongs do not make a right. But on the other hand - assumed it's working, which I'm testing since today - then this is my only chance for a workaround beside switching mouse off and back on every time I return to my PC after some minutes.

raelgc commented 1 year ago

I never faced this issue until now. I resumed after upgrade Ubuntu 22.04.2 to 22.04.3 (which now uses kernel 6.2.0-26) and got the slow scrolling issue. Had to turn off and turn on again the mouse.

horrovac commented 7 months ago

I found a 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. Make sure that you disable the Scroll Wheel Resolution setting, otherwise the scrolling is way too fast.