Bug 202909

Perhaps I should add that I've been using this mouse for over a year now without any issues. I also happen to have two of these mice and both exhibit the same problem after updating to kernel 5.0 while they were fine before.

I'm on a Dell XPS 13 9370.

A follow up to this. When testing on Linux 5.0.2 (perhaps this was the case on 5.0 as well), it turns out that it's not that we no longer get any axis events, it's that to generate any one has to scroll like crazy. Eg. something that would result in lots of axis events only results in a few of them. Again this happens after some time - like 30 minutes or so.

I have the same issue. No axis events and scroll wheel not working.
Product: Microsoft Pro Intellimouse Mouse
Kernel version: 5.0.2

Tested on both libinput and evdev driver.

(In reply to Phoenix Emik from comment #4)
> I have the same issue. No axis events and scroll wheel not working.
> Product: Microsoft Pro Intellimouse Mouse
> Kernel version: 5.0.2

Phoenix,

i have this mouse as well. however i have reason to believe this bug is not related to John's issue.

i believe the issue we share is that the kernel now seems to emit a new event for this mouse's scroll wheel - REL_WHEEL_HI_RES - since the new high resolution scrolling code was introduced.

however, it would seem that the relevant patch for libinput is not merged.

Hi all, I have Microsoft Sculpt Touch Mouse witch has the same problem described above.
I also have a Microsoft Bluetooth Notebook Mouse 5000 that works fine. Below you can find the output of both evtest on both mouses and on the same machine with kernel 4 and kernel 5:

Linux knuth 5.0.5-arch1-1-ARCH #1 SMP PREEMPT Wed Mar 27 17:53:10 UTC 2019 x86_64 GNU/Linux

Input driver version is 1.0.1
Input device ID: bus 0x5 vendor 0x45e product 0x77c version 0x120
Input device name: "Microsoft Sculpt Touch Mouse"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 272 (BTN_LEFT)
    Event code 273 (BTN_RIGHT)
    Event code 274 (BTN_MIDDLE)
    Event code 275 (BTN_SIDE)
    Event code 276 (BTN_EXTRA)
  Event type 2 (EV_REL)
    Event code 0 (REL_X)
    Event code 1 (REL_Y)
    Event code 6 (REL_HWHEEL)
    Event code 8 (REL_WHEEL)
    Event code 11 (?)
    Event code 12 (?)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
Event: time 1554064025.026696, type 2 (EV_REL), code 11 (?), value 7
Event: time 1554064025.026696, -------------- SYN_REPORT ------------
Event: time 1554064026.016950, type 2 (EV_REL), code 11 (?), value -7
Event: time 1554064026.016950, -------------- SYN_REPORT ------------



Kernel 
Linux knuth 5.0.5-arch1-1-ARCH #1 SMP PREEMPT Wed Mar 27 17:53:10 UTC 2019 x86_64 GNU/Linux

Input driver version is 1.0.1
Input device ID: bus 0x5 vendor 0x45e product 0x700 version 0x100
Input device name: "Microsoft Bluetooth Notebook Mouse 5000 Mouse"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 272 (BTN_LEFT)
    Event code 273 (BTN_RIGHT)
    Event code 274 (BTN_MIDDLE)
    Event code 275 (BTN_SIDE)
  Event type 2 (EV_REL)
    Event code 0 (REL_X)
    Event code 1 (REL_Y)
    Event code 8 (REL_WHEEL)
    Event code 11 (?)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
Event: time 1554064179.153701, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1554064179.153701, type 2 (EV_REL), code 11 (?), value 120
Event: time 1554064179.153701, -------------- SYN_REPORT ------------
Event: time 1554064180.765802, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1554064180.765802, type 2 (EV_REL), code 11 (?), value -120
Event: time 1554064180.765802, -------------- SYN_REPORT ------------

RESULT: Bluetooth mouse works, Sculpt mouse only scrolls (one line) after a LOT of wheel spinning.

Linux knuth 4.19.32-1-lts #1 SMP Wed Mar 27 16:37:44 CET 2019 x86_64 GNU/Linux

Input driver version is 1.0.1
Input device ID: bus 0x5 vendor 0x45e product 0x700 version 0x100
Input device name: "Microsoft Bluetooth Notebook Mouse 5000 Mouse"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 272 (BTN_LEFT)
    Event code 273 (BTN_RIGHT)
    Event code 274 (BTN_MIDDLE)
    Event code 275 (BTN_SIDE)
  Event type 2 (EV_REL)
    Event code 0 (REL_X)
    Event code 1 (REL_Y)
    Event code 8 (REL_WHEEL)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
Event: time 1554064613.391454, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1554064613.391454, -------------- SYN_REPORT ------------
Event: time 1554064614.648223, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1554064614.648223, -------------- SYN_REPORT ------------


Input driver version is 1.0.1
Input device ID: bus 0x5 vendor 0x45e product 0x77c version 0x120
Input device name: "Microsoft Sculpt Touch Mouse Mouse"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 272 (BTN_LEFT)
    Event code 273 (BTN_RIGHT)
    Event code 274 (BTN_MIDDLE)
    Event code 275 (BTN_SIDE)
    Event code 276 (BTN_EXTRA)
  Event type 2 (EV_REL)
    Event code 0 (REL_X)
    Event code 1 (REL_Y)
    Event code 6 (REL_HWHEEL)
    Event code 8 (REL_WHEEL)
  Event type 4 (EV_MSC)
    Event code 4 (MSC_SCAN)
Properties:
Testing ... (interrupt to exit)
Event: time 1554064730.041579, type 2 (EV_REL), code 8 (REL_WHEEL), value 1
Event: time 1554064730.041579, -------------- SYN_REPORT ------------
Event: time 1554064730.614046, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1554064730.614046, -------------- SYN_REPORT ------------

RESULT: Both mouses work nicely.

It looks like that events are being reported with the correct frequency (every 'tick' on the sculpt mouse sends an even on both kernels), but the Kernel 5 reports a diferent event, and a different value. I am no expert, but it feels that the problem is NOT libinput...

Hope this helps,
Fabio

Microsoft wireless mouse models that I have, are showing degraded scrolling since kernel 5 upgrade 3 months ago.
 

Models :

Microsoft Standard Wireless Optical Mouse
Microsoft Wireless Optical Mouse 2000


I can confirm that scroll events are not being detected correctly on linux 5.0.x. but work fine on kernels 4.20.17 an 4.19.34.

Degraded scrolling is straight after boot to desktop.

Symptom is seen in libinput debug-events - i get one scroll event per 18 wheel clicks - which is one full wheel rotation.

On the same PC, a USB wired (Microsoft) mouse works OK on kernel 5.0*.

I have posted this initially at https://bbs.archlinux.org/viewtopic.php?id=245501

sorry for the sub-optimal formatting of this post.....jeff

I forgot to mention - also tested on 5.1-rc4.

System is desktop PC running archlinux.

I'm having the same issue. However, this doesn't just affect the MS Arc Mouse (bluetooth) but a LogitechT650 (wireless) trackpad. I booted kernel 4.18 and the problem isn't present. So is clearly a 5.x issue.

By the way, this is on Pop!_OS.

Can you check if this patch fixes things please?
https://patchwork.kernel.org/patch/10913251/

That one is slated for stable but didn't make 5.1.

Peter,

this works on my machine. i applied it on top of v5.1, and have tested my microsoft mouse.

i now see this in evtest:

Event: time 1557194109.719526, type 2 (EV_REL), code 8 (REL_WHEEL), value -1
Event: time 1557194109.719526, type 2 (EV_REL), code 11 (?), value -120

whereas before i only saw code 11 (the new hires events).

thanks!

Created attachment 282659 [details]
lsusb 045e:082a

lsusb of microsoft mouse tested with Peter's linked patch

I'm the original reporter and the mentioned patch does not fix my issue.

the patch (on 5.1) fixes my scrolling issue with 'Microsoft Standard Wireless Optical Mouse'.

(In reply to John A. Eriksson from comment #14)
> I'm the original reporter and the mentioned patch does not fix my issue.

It's pretty clear your original bug report got hijacked by another bug report, which itself got addressed/resolved quite effectively.

But the issue of an idle arc mouse losing axis events is still open and reproducible.  As long as I keep using the mouse, touch scrolling works.  But if I let the mouse go idle for about 5-10 minutes, when it wakes up it's without touch scroll working.

While there is no indication in the logs on the paired host, the pattern suggests the mouse is going into a low power mode of some sort.  Movement wakes it up, and everything works except touch scrolling.

If the bluetooth subsystem on the host is bounced then the mouse functions properly including touch scrolling.

5.0.13
libinput 1.13.1

https://www.microsoft.com/en-us/p/microsoft-arc-mouse-black/8mwhbv8qvskr?activetab=pivot%3aoverviewtab

Trying to untangle the bits here.

As mentioned in the previous comment (#16), there are 2 bugs here:

- one that for some old mice, the wheel is not set correctly (the kernel believes it can support high resolution scrolling, while the device refuses it). This should be fixed by the patch mentioned in comment #11 and which is now in Linus' tree.

- the original bug: the mouse is correctly switched to the high resolution mode, but when put to sleep and back again, it forgets the settings.

For this bug, this seems to only happen with the Bluetooth Arc Mouse, am I correct?

What is likely to happen is that the mouse resets its state when put to sleep, but the kernel doesn't see the connect event and can not resend the configuration settings.

Would it be possible for anyone who has the Arc Mouse to do some recording with hid-recorder (as root) at https://gitlab.freedesktop.org/libevdev/hid-tools:
- one with "working" scroll events
- one with the faulty scroll events

Created attachment 282703 [details]
hid-recorder output of MS arc mouse (BT) prior to sleep/lp mode

Created attachment 282705 [details]
hid-recorder output of MS arc mouse (BT) after waking from sleep/lp mode

(In reply to Benjamin Tissoires from comment #17)
 
> Would it be possible for anyone who has the Arc Mouse to do some recording
> with hid-recorder (as root) at
> https://gitlab.freedesktop.org/libevdev/hid-tools:
> - one with "working" scroll events
> - one with the faulty scroll events

Done and attached, and it's pretty clear from the output that upon resume the scroll factor is being set to 1, whereas prior to sleep/lp mode it was like 7 or 8.

Indeed, upon resume if I wail away on that touch scroll like a dozen times, the screen does indeed manage to scroll by a single line.

Like I said, bouncing the BT subsystem re-inits everything the pre-sleep values.

Thanks a lot for the logs.

So, next question: do we get an event when the mouse comes back from sleep?

(this could be checked by leaving hid-recorder in the background).

However, the thing I am worried is that if this mouse is indeed a BLE one, I am afraid we lose the reconnect event in bluez and so the hid stack has no way of knowing if the mouse reconnects (besides adding a 5 min timeout or such)

Created attachment 282707 [details]
long background hid-recorder output of an awake MS arc mouse (BT), left to enter sleep/lp mode, then reawoken

Yeah there's no event upon wakeup.  Also interesting that LC/RC do *not* wake the device, only mouse movement does.  Clicks register after the wake.

But you're right, hid just gets the mouse moves and noting else.

Thanks for the analysis. I am a little bit lost regarding which solution we should take here.

One could be to assume we will never get a reconnect event from those devices, and check for how long is the last event. If the last event is more than 5 min, then we can assume we lost the settings.

But OTOH, a cleaner solution would be for bluez to actually signal us that the mouse is disconnected and when it comes back. I am not sure we have anything in place right now in the kernel for that, so I'll need a little bit of days to figure this out.

(In reply to Benjamin Tissoires from comment #24)
> One could be to assume we will never get a reconnect event from those
> devices, and check for how long is the last event. If the last event is more
> than 5 min, then we can assume we lost the settings.

This would totally do it.

Created attachment 282933 [details]
bluez patch that removes the uhid device on disconnect

Here is a simple patch that seems to be doing the trick: when the device disconnects, it removes the uhid attached device.

The downside is that further reconnects are taking longer time than without it, as bluez needs to re-enumerate the device entirely.

I can confirm this patch to bluez appears to address the issue.  I've applied the patch, rebuilt and bounced bluez (as in gentoo portage net-wireless/bluez-5.50-r2). 
 I've allowed the arc mouse device to go low power, and then after waking it again the touch scrolling is available.

Regarding the extra time for device enumeration, I don't really notice it.  Even before the patch there was always a delay of a few seconds for the device to wake and start moving the pointer.  Also, as stated in previous comment, clicks and scrolls don't serve to wake the device anyway, only movement seems to do this.

So this looks good from my pov.

git-formatted patch:
https://github.com/hadess/bluez/commit/be7bac59135f513cf389b0a43fd2a62f05f6cc9f

And sent upstream:
https://marc.info/?l=linux-bluetooth&m=156052629217765&w=2

The upstream change was reverted:
https://github.com/bluez/bluez/commit/5fb9c9feb1b7d8845d10c386cfdcf17aa13cb27c

and replaced with a more 'optimal' solution:
https://github.com/bluez/bluez/commit/23b69ab3e484ce5a077457bdfb1533cfa216a755

However, the axis issue has returned for me since the above fix for me (I'm using a MS Arc Touch BT mouse).
(I'll raise an upstream bug after capturing appropriate debug logs).