Starting with 5.73, Logitech MX Master 3 scroll wheel speed drops dramatically after some idle time or mouse power toggle

[dimitris-personal]

Up to date Fedora 39 paired with a MX Master 3. Mouse has been working flowlessly up to and including 5.72. Starting with 5.73:

• Fresh boot or resume from s2ide: Turn mouse on, connects, mouse wheel speed is normal.
• Step away from the machine for 10-15 minutes or, alternatively, turn mouse off, wait a few seconds, then turn back on.
• Come back, unlock the screen (if applicable)
• Scroll wheel is now very, very slow.

A quick look at the journal shows only this:

bluetoothd[34318]: Device is already marked as connected

(edit: as far as I can tell this message only started appearing with 5.73)

Downgrading back to 5.72 fixes the issue.

[yeezy69]

Same here with Logitech MX Master on Archlinux after bluez update from 5.72 to 5.73.

Turning the mouse off and on doesn't help. The Bluetooth process seems to hang a little. Bluetooth cannot be switched off/on via the Mate GUI.

As a temporary solution, I kill the Bluetooth process with signal 9. The mouse then reconnects and the scroll wheel can be used normally again. until the next break.

# ps xau |grep bluetoothd
root       20675  0.0  0.0  13948  7500 ?        Ss   00:07   0:15 /usr/lib/bluetooth/bluetoothd
# kill -9 20675

[cschramm]

I'm experiencing the same. Unless I did something wrong while testing, neither UserspaceHID=false, nor the line from #771 (comment) help.

[gandriyko]

Same issue with Logitech MX Anywhere 3
bluez update from 5.72 to 5.73 (ArchLinux)

[mandibleman]

same issue, also with logitech mx anywhere 3
quick reproduction was to power-cycle mouse, and scroll wheel speed became slow
rebooting pc would allow the mouse to operate as normal

downgraded from 5.73 to 5.72 as a temp fix

[AdamWill]

Also discussed here, where I thought it was a GNOME issue.

Something I found there: if you install the 'solaar' management utility and toggle the "Scroll Wheel Resolution" setting to on (when I ran the app, it was off - you have to 'unlock' the setting by clicking the lock icon twice first) it 'fixes' the problem. So bluez may be somehow inadvertently doing something to whatever that toggle represents?

[Vudentz]

#774 (comment)

[cschramm]

After I got https://gitlab.archlinux.org/archlinux/packaging/packages/bluez/-/blob/e67ba6b274c4b5e182c323ae0048fe96da1bcdcb/0001_use_bt_uhid_functions.patch via Arch's 5.73-4, the problem seems to be gone.

Edit: I also got an update to Linux 6.8 that might be relevant somehow.

Edit: Not true. It's back. Trying 8060d12 now.

[dimitris-personal]

I added the patch from BluezTestBot#2140 to the fedora package and built locally. Seems to fix this issue. Also tested my Pixel Buds Pro, no regressions there. So that PR LGTM.

[AdamWill]

Sadly I'm still seeing slow scrolling here :( It seemed to be working all day, but after I left the system idle for a while and came back, slow scrolling returned.

[dimitris-personal]

Can't reproduce, at least not yet, after a 15-minute idle period. (edit: with the same locally-built patched package)

[AdamWill]

I left it longer than that (went downstairs for dinner, probably 3 hours or so).

[dimitris-personal]

Yup, reproduced here too after an overnight s2idle sleep. The mouse was off overnight and this happened immediately upon resume and mouse switch on, no "idle" time as such - well, maybe the 8 seconds between resume and the error message:

Mar 19 08:30:48 bluetoothd[2006]: Controller resume with wake event 0x0
Mar 19 08:30:56 bluetoothd[2006]: Device is already marked as connected

Editing to add: Later in the day leaving the machine idle doesn't (yet) reproduce the problem, even though the Device is already marked as connected message does reappear when I wake up the desktop (no s2idle, just locked desktop for a few minutes).

[yeezy69]

With Archlinux bluez 5.73-4 the problem is NOT gone for me.

[AdamWill]

It does kinda seem like the problem happens less now, but hard to say if that's really true or just my unreliable impression...

[cschramm]

With Archlinux bluez 5.73-4 the problem is NOT gone for me.

Sorry, I just jumped to conclusions there. See my edits.

With 8060d12 (on top of Arch's 5.73-4) it seems to be running fine yet. Will report back if it reappears.

[cschramm]

Unfortunately it's back. I second @AdamWill's impression that it takes a longer idle time to appear with that patch, but it still does.

[farchord]

For me, I don't even need to go idle. If I simply turn off the mouse, the problem will trigger. I can make bluetoothd die completely if, after this issue occurs, I try to turn off/on bluetooth in KDE settings.

Restarting the bluetooth service does fix it. Restarting it does take quite a while though.

[dimitris-personal]

I tried a Fedora package built on b8ad349, same scrolling symptom persists. No need to idle, just turn mouse off, wait a few seconds, then back on.

@Vudentz looks like this should be re-opened?

[Vudentz]

@dimitris-personal might be a duplication of #777, we persist the input node because of #771 otherwise we may loose key presses at the start. HIDP actually has a way to indicate to the host it wants to generate a virtual cable unplug:

https://github.com/bluez/bluez/blob/master/profiles/input/device.c#L323

So if there anything wrong with keeping the device 'plugged' that is because the manufactorer did not asked it to be unplugged while disconnected.

[farchord]

I tried a Fedora package built on b8ad349, same scrolling symptom persists. No need to idle, just turn mouse off, wait a few seconds, then back on.

@Vudentz looks like this should be re-opened?

Try this next:

When you are afflicted (Hehe... love that word!) by the mouse slowdown issue, go in KDE settings (I assume it's the same with Gnome) and try to disable bluetooth and reenable it. In KDE, that seems to work, but then devices will not reconnect.

The only fix for this is to restart bluetoothd.

[dimitris-personal]

@Vudentz I see. I tried UserspaceHID=false from #777 but the issue persists. This sounds like a Logitech firmware issue for which I don't have high hopes.

Any chance of an option to control the behavior at https://github.com/bluez/bluez/blob/master/profiles/input/device.c#L323 ?

Any other workarounds? I did try the unifying receiver and it does work, but a) it's an extra dongle, b) forwards/backwards buttons and overview gesture no longer work with it.

[dimitris-personal]

Well this looks more interesting:

I tried building b8ad349 plus the patch at https://patchwork.kernel.org/project/bluetooth/patch/20240320130119.854959-1-luiz.dentz@gmail.com/ plus setting IdleTimeout=30 and the problem persists.

Then looking at kernel messages, it looks like both hid-generic and logitech-hidpp-device claim (?) the mouse. On a whim I unloaded the hid_logitech_hidpp module, and that seems to fix the problem, without any apparent loss of functionality on the mouse.

Steps:

• Fresh boot, mouse not connected:

  $ lsmod |grep hid
  uhid                   20480  1
  hid_sensor_als         16384  1
  hid_sensor_trigger     20480  2 hid_sensor_als
  hid_sensor_iio_common    20480  2 hid_sensor_trigger,hid_sensor_als
  industrialio_triggered_buffer    12288  1 hid_sensor_trigger
  industrialio          131072  5 industrialio_triggered_buffer,hid_sensor_trigger,kfifo_buf,hid_sensor_als
  hid_multitouch         32768  0
  hid_sensor_hub         32768  3 hid_sensor_trigger,hid_sensor_iio_common,hid_sensor_als
  i2c_hid_acpi           12288  0
  i2c_hid                40960  1 i2c_hid_acpi
  

• Connect the mouse.

  $ lsmod |grep hid
  hid_logitech_hidpp     73728  0
  uhid                   20480  2
  hid_sensor_als         16384  1
  hid_sensor_trigger     20480  2 hid_sensor_als
  hid_sensor_iio_common    20480  2 hid_sensor_trigger,hid_sensor_als
  industrialio_triggered_buffer    12288  1 hid_sensor_trigger
  industrialio          131072  5 industrialio_triggered_buffer,hid_sensor_trigger,kfifo_buf,hid_sensor_als
  hid_multitouch         32768  0
  hid_sensor_hub         32768  3 hid_sensor_trigger,hid_sensor_iio_common,hid_sensor_als
  i2c_hid_acpi           12288  0
  i2c_hid                40960  1 i2c_hid_acpi
  

• Toggle mouse switch (stay off > 30 sec).

• Scrolling is slow.

• $ sudo modprobe -r hid_logitech_hidpp

  $ lsmod |grep hid
  uhid                   20480  2
  hid_sensor_als         16384  1
  hid_sensor_trigger     20480  2 hid_sensor_als
  hid_sensor_iio_common    20480  2 hid_sensor_trigger,hid_sensor_als
  industrialio_triggered_buffer    12288  1 hid_sensor_trigger
  industrialio          131072  5 industrialio_triggered_buffer,hid_sensor_trigger,kfifo_buf,hid_sensor_als
  hid_multitouch         32768  0
  hid_sensor_hub         32768  3 hid_sensor_trigger,hid_sensor_iio_common,hid_sensor_als
  i2c_hid_acpi           12288  0
  i2c_hid                40960  1 i2c_hid_acpi
  

• Scrolling is fast again, no functionality loss.

• Toggle again

• Still fast, and hid_logitech_hidpp not loaded.

So, not sure what/how is loading hid_logitech_hidpp and why its presence contributes to the problem. Blacklisting it should be a crude workaround, but there seems to be some (kernel? udev? bluez?) underlying issue.

[kparal]

My guess is that this is a kernel issue, not a bluetooth issue. Just some latest update in bluez exposed it for bluetooth connection as well.

I've reported a slow scrolling bug in 2019, using USB dongle connection, here:
https://bugzilla.redhat.com/show_bug.cgi?id=1701322

So it has been present for at least 5 years now. During that time, it has never affected bluetooth connection (I still have the same mouse, and I use it with both USB dongle and BT regularly), that started just recently.

[pfps]

So it has been present for at least 5 years now. During that time, it has never affected bluetooth connection (I still have the same mouse, and I use it with both USB dongle and BT regularly), that started just recently.

TL;DR: This may be a problem where the Linux input driver is not notified or does not recognize when the mouse reconnects under Bluetooth.

Here is some background on the problem. I have knowledge of how these mice work because I maintain the Solaar program, which can be used to control various Logitech devices that use the Logitech HID++ protocol.

These mice respond to a special (HID++) message sent to them by changing several ways the scroll wheel works. The message sets the scroll wheel into low-resolution or high-resolution mode, into inverted or not inverted mode, and into HID or HID++ mode. In high-resolution mode the mouse wheel reports about 8 times as much distance when it turns as it does in low-resolution mode, and can report many more events.

The Linux HID++ driver, https://github.com/torvalds/linux/blob/master/drivers/hid/hid-logitech-hidpp.c, uses high-resolution mode to implement smooth scrolling. What the driver does, at least for programs that don't use smooth scrolling, is to keep track of the high-resolution scrolling distance and only send out a scroll event when 8-or-so high-resolution distance units have been accumulated. So nothing should change for these programs.

There are two things that can go wrong. First, a program, like Solaar, might change the resolution mode. The driver should examine all the messages that the device sends out and change smooth-scrolling mode when the device indicates that it has switched resolution mode but it does not. Second, each time that the mouse goes into a power-saving mode it forgets its scrolling modes and when it reawakens it starts up in its default modes, which include low-resolution mode. The driver should recognize when the device wakes up and send a message to switch to high-resolution mode.

For mice connected via a Logitech receiver this is generally done in response to HID++ connection messages. For mice connected via Bluetooth this is generally done when the Bluetooth connection is established, because Bluetooth connections were dropped when the mouse goes into a power-saving mode. If this is no longer the case then it is easy to see how scrolling can become slow after a period of inactivity.

For more information on the HID++ messages used for these scrolling wheels see https://drive.google.com/drive/folders/0BxbRzx7vEV7eWmgwazJ3NUFfQ28?resourcekey=0-dQ-Lx1FORQl0KAdOHQaE1A

PS: The ongoing problem when the connection is via a receiver may be caused by sending a message to the mouse so early in the reconnect process that the message is either lost or the mouse does not process the message.

[dimitris-personal]

The driver should recognize when the device wakes up and send a message to switch to high-resolution mode.

@pfps which driver would that be? uhid, hid-logitech-hidpp or something else?

[pfps]

The driver should recognize when the device wakes up and send a message to switch to high-resolution mode.

@pfps which driver would that be? uhid, hid-logitech-hidpp or something else?

hid-logitech-hidpp

But it might be that the driver currently has no way of recognizing when the device wakes up, so the change has to (also?) be in the Bluetooth stack. Or it might be that some driver has to set a flag somewhere so that the Bluetooth stack knows to do something differently. Or there might be something else that needs to be changed so that the driver can know when the device wakes up.

[Vudentz]

The driver should recognize when the device wakes up and send a message to switch to high-resolution mode.

@pfps which driver would that be? uhid, hid-logitech-hidpp or something else?

hid-logitech-hidpp

But it might be that the driver currently has no way of recognizing when the device wakes up, so the change has to (also?) be in the Bluetooth stack. Or it might be that some driver has to set a flag somewhere so that the Bluetooth stack knows to do something differently. Or there might be something else that needs to be changed so that the driver can know when the device wakes up.

If what you are saying is related to keeping the uhid device while disconnected Ive just merged the following change:

https://patchwork.kernel.org/project/bluetooth/patch/20240405211145.3463154-3-luiz.dentz@gmail.com/

This will store the control messages seem when it connects the first time, then if reconnects (due to entering powersafe mode, etc) then we will replay the control messages to restore the states.

[Vudentz]

The driver should recognize when the device wakes up and send a message to switch to high-resolution mode.

@pfps which driver would that be? uhid, hid-logitech-hidpp or something else?

hid-logitech-hidpp
But it might be that the driver currently has no way of recognizing when the device wakes up, so the change has to (also?) be in the Bluetooth stack. Or it might be that some driver has to set a flag somewhere so that the Bluetooth stack knows to do something differently. Or there might be something else that needs to be changed so that the driver can know when the device wakes up.

If what you are saying is related to keeping the uhid device while disconnected Ive just merged the following change:

patchwork.kernel.org/project/bluetooth/patch/20240405211145.3463154-3-luiz.dentz@gmail.com

This will store the control messages seem when it connects the first time, then if reconnects (due to entering powersafe mode, etc) then we will replay the control messages to restore the states.

Correction, looks like this won't work on LE since the changes were just for classic, so I may need to move the replay support to a common place to have LE also taking benefit of it.

[pfps]

@Vudentz How are you keeping track of the messages? The messages sent by the driver (and Solaar) are HID++ messages sent on the raw interface.

The underlying issue is that there is state that may need to be set up whenever these devices come back from a power-saving mode. Some of this state (e.g., high-resolution scrolling) needs to be sent from software (driver or some other system) to the device, but other state (e.g., distance multiplication) is stored on the device and needs to be present in software. The driver sends three messages (get an index used in later messages, get the multiplier, set high-resolution mode). Only the third needs to be sent on reconnections. The first two only retrieve information and the information is always the same for the device (unless its firmware is updated).

I'm not sure how this all will affect Solaar, which similarly sets up device state for Logitech HID++ devices whenever they connect or reconnect. The number of messages that Solaar sends to do this can be several dozen.

[Vudentz]

@pfps it records all messages of ev.type = GET_REPORT/SET_REPORT. so as long as that is what HID++ uses then it shall be fine.

And yes, there are quite a few of them, I recorded 18 with MX Anywhere 3, then on reconnect they are resend immediately, we may want to introduce a timeout for these messages though so if the device stay disconnected for some long time we just send UHID_DESTROY and cleanup the cache.

[pfps]

@Vudentz For some Logitech devices the best startup sequence can be non-trivial to determine. Some messages to the device change what messages are sent from the device.

A bad situation is if the device is woken up by pressing a function key. Many Logitech devices have a mode that switches the HID report that is sent by these keys. The device should be set up to delay messages until software has had a chance to tell it what report to send for function keys. The software should quickly send setup messages and then tell the device that it is finished setup so the device can then sent the appropriate report. (There is a timeout to guard against deficient software.) I don't know whether replay is sufficient here.

[Vudentz]

Here is the set: https://patchwork.kernel.org/project/bluetooth/list/?series=842597

[pfps]

@Vudentz

On bluez 5.72 when a Bluetooth device disconnects Solaar immediately notices that the connection is gone. When the device reconnects Solaar sees a new device and sends appropriate setup messages.

On bluez 5.73 when a Bluetooth device disconnects Solaar does not notice that anything has changed. Writes to the device fail but the HID raw node for the device is still available. But something notices because a notification pops up saying that the device has disconnected. Is there documentation on this change? Is there any way for Solaar to find out that the device has disconnected?

When the Logitech device reconnects it sends a message asking for reconfiguration. Solaar currently doesn't do anything with this message, but it should. UPDATE: Not all Logitech devices send this message so Solaar needs to know when a device disconnects.

The messages that Solaar sends to set up Logitech devices should not be replayed becuase Solaar will soon be able to set up these devices when they disconnect, even under bluez 5.73. As well, the correct setup sequence may have changed because the user has changed settings on the device. Replaying driver setup messages might not be correct for the same reason, although I don't think that there currently is any variability in setup by the current Linux driver for Logitech devices. Replaying setup messages is also potentially inefficient as on reconnect the driver might not request information that is unchanging.

[Vudentz]

@Vudentz

On bluez 5.72 when a Bluetooth device disconnects Solaar immediately notices that the connection is gone. When the device reconnects Solaar sees a new device and sends appropriate setup messages.

What is Solaar? https://pwr-solaar.github.io/Solaar/?

On bluez 5.73 when a Bluetooth device disconnects Solaar does not notice that anything has changed. Writes to the device fail but the HID raw node for the device is still available. But something notices because a notification pops up saying that the device has disconnected. Is there documentation on this change? Is there any way for Solaar to find out that the device has disconnected?

When the Logitech device reconnects it sends a message asking for reconfiguration. Solaar currently doesn't do anything with this message, but it should. UPDATE: Not all Logitech devices send this message so Solaar needs to know when a device disconnects.

The messages that Solaar sends to set up Logitech devices should not be replayed becuase Solaar will soon be able to set up these devices when they disconnect, even under bluez 5.73. As well, the correct setup sequence may have changed because the user has changed settings on the device. Replaying driver setup messages might not be correct for the same reason, although I don't think that there currently is any variability in setup by the current Linux driver for Logitech devices. Replaying setup messages is also potentially inefficient as on reconnect the driver might not request information that is unchanging.

The change to prefer uHID was introduced to keep input devices around since otherwise there were events being lost during the creation of the input node, in particular this is very cumbersome for keyboards since the users had to re-enter key presses while reconnecting and by keeping the device around the problem was gone, which indicates there is a bug somewhere in between HID, or perhaps user session, not processing these events.

Anyway there is a long list of changes for 5.74 release so I do recommend testing against that.

[fadein]

I filed #803 last week after discovering that this problem is introduced by commit 247ae85. The issue is reliably reproducible on this commit. FYI, I use the Microsoft Arc Mouse.

[Spunkie]

So is this bug actually resolved or was this GH issue just closed prematurely?

[AdamWill]

It was closed prematurely, the bug definitely persists. @Vudentz says to try the replay patches - I think that's the range 7604a57..b163e2b in git master. I'm trying that now.

edit - for anyone on Fedora 40, https://koji.fedoraproject.org/koji/taskinfo?taskID=116243781 is a scratch build of current git master (the patches don't backport cleanly so I just went with a snapshot build). I've just installed it, will have to wait a bit to see if it fixes the bug.

[AdamWill]

I don't want to jump the gun again, but it really does seem like that build fixes it this time, so presumably the replay patches helped. @Vudentz will 5.74 be coming soon? It'd be great to get this fixed for Fedora 40, but I don't really want to update the package to a random git snapshot...I can try harder to rebase the replay patches if the release won't be soon, I guess.

[Vudentz]

I don't want to jump the gun again, but it really does seem like that build fixes it this time, so presumably the replay patches helped. @Vudentz will 5.74 be coming soon? It'd be great to get this fixed for Fedora 40, but I don't really want to update the package to a random git snapshot...I can try harder to rebase the replay patches if the release won't be soon, I guess.

That is great to know it is working for more people, we are in the process of releasing 5.74 soon.

[samfelgar]

After updating to 5.75, the scroll wheel keeps its speed, but the sensitivity (DPI) still drops. I'm also using solaar.

[AdamWill]

I've never tweaked my DPI, so I wouldn't have noticed that part.

[pfps]

@samfelgar You could run Solaar as solaar -ddd to show the responses to the messages sent by Bluez when the mouse reconnects. This would allow me to see what Bluez replays during reconnects. If Bluez does not replay any messages sent by Solaar then Solaar could be patched to detect reconnects and do its own restoring.

[samfelgar]

@pfps Here's the output: solaar-debug.txt

Thanks!

[pfps]

Thanks.

Here is an edited, annotated list of the messages that are coming back from the mouse.

The first message is a notification from the device of its battery status

2024-04-15 23:54:39,428,428 r[11 FF 0800 64320000000000000000000000000000] BATTERY STATUS notification

Then there are a bunch of responses to messages sent to the device. The messages appear to have been originally sent by the device driver, because the driver uses a 0x1 for the software identifier, which is the lower half of the fourth byte of the responses. It is unclear whether these are all from the bluez replay mechanism.

2024-04-15 23:54:39,455,455 r[11 FF 0001 03000000000000000000000000000000] index of DEVICE NAME
2024-04-15 23:54:39,892,892 r[11 FF 0301 1A000000000000000000000000000000] DEVICE NAME - length
2024-04-15 23:54:39,935,935 r[11 FF 0311 576972656C657373204D6F757365204D] DEVICE NAME - first part
2024-04-15 23:54:40,295,295 r[11 FF 0311 58204D61737465722033000000000000] DEVICE NAME - second part
2024-04-15 23:54:40,475,475 r[11 FF 0011 04055A00000000000000000000000000] ROOT - protocol version
2024-04-15 23:54:40,488,488 r[11 FF 0001 04000000000000000000000000000000] index of WIRELESS DEVICE STATUS
2024-04-15 23:54:40,502,502 r[11 FF 0001 03000000000000000000000000000000] index of DEVICE NAME
2024-04-15 23:54:40,502,502 r[11 FF 0301 1A000000000000000000000000000000] DEVICE NAME - length
2024-04-15 23:54:40,528,528 r[11 FF 0311 576972656C657373204D6F757365204D] DEVICE NAME - first part
2024-04-15 23:54:40,538,538 r[11 FF 0311 58204D61737465722033000000000000] DEVICE NAME - second part
2024-04-15 23:54:40,548,548 r[11 FF 0001 08000100000000000000000000000000] index of BATTERY STATUS
2024-04-15 23:54:40,561,561 r[11 FF 0801 64320000000000000000000000000000] BATTERY STATUS information
2024-04-15 23:54:40,562,562 r[11 FF 0811 0404C078050000000000000000000000] BATTERY STATUS capabilities
2024-04-15 23:54:40,588,588 r[11 FF 0001 0E000100000000000000000000000000] index of HIRES WHEEL
2024-04-15 23:54:40,595,595 r[11 FF 0801 64320000000000000000000000000000] BATTERY STATUS information
2024-04-15 23:54:40,612,612 r[11 FF 0811 0404C078050000000000000000000000] BATTERY STATUS capabilities
2024-04-15 23:54:40,628,628 r[11 FF 0001 0E000100000000000000000000000000] index of HIRES WHEEL
2024-04-15 23:54:40,648,648 r[11 FF 0E21 02000000000000000000000000000000] HIRES WHEEL set high resolution mode
2024-04-15 23:54:40,662,662 r[11 FF 0001 0E000100000000000000000000000000] index of HIRES WHEEL
2024-04-15 23:54:40,678,678 r[11 FF 0E01 0F1C1818000000000000000000000000] HIRES WHEEL get capabilities

Of these 20 responses, 19 are for messages sent to gather information. Some of these are to determine the indexes of various features. Some are to find out the device's name. Some are to find information about the device's battery. One is to find out information about the device's protocol version. One is to find out information about the device's scroll wheel. There is quite a bit of duplication, putting extra load on the device. The source of this duplication is unclear. Only one response is for a message that actually changes something.

Fortunately it appears that messages sent by Solaar are not being replayed.

[Vudentz]

Hmm, maybe we need to check if there are duplicated messages in the queue, anyway we can make bt_uhid instance be a little bit more smart with respect to the device, maybe even incorporate the logic of Solaar and make it remember settings so the user don't have to keep doing this on every reconnect.

[discapes]

Thanks for fixing this guys 🙏 as I'm on Fedora, I will survive with sudo rmmod hid_logitech_hidpp

[pfps]

Solaar https://github.com/pwr-Solaar/Solaar release 1.1.12rc1, just out, uses the connect and disconnect DBus messages from bluez to reinitialize the Bluetooth devices it controls when they reconnect. It can be used to correctly set the feature that the hid_logitech_hidpp driver modifies to implement smooth scrolling and prevent wheel speed drop when Bluez 5.73 is installed.

The Solaar Scroll Wheel Resolution setting has to be true (and not ignored). There is a small chance that Solaar and the driver interact poorly at startup, which can be fixed by toggling the setting to false and back to true.

[AdamWill]

@discapes just do dnf --enablerepo=updates-testing update bluez, power off and on again, and it should be fine. the update will go to stable as soon as the release freeze is listed (sometime before Tuesday).

[ktdreyer]

@AdamWill thanks, with updates-testing my MX Master 3 wheel is working again over Bluetooth on my two Fedora 39 laptops.

kernel-6.8.8-200.fc39.x86_64
bluez-5.75-1.fc39.x86_64
solaar-1.1.11-1.fc39.noarch

Special thank you to @pfps for your expertise and detailed comments here.

[dimitris-personal]

Same good results here with the same F39 versions @ktdreyer.

One note: After I removed hid_logitech_hidpp from the blacklist, I found that I had to enable the Scroll Wheel Resolution switch in Solaar to get the correct speed on my MX Master 3. Otherwise it would only scroll slowly.