[REGRESSION 7.3-rc1] HID: logitech-hidpp: hi-res scroll mode forcibly re-enabled on every reconnect for Bolt devices, overriding userspace

[REGRESSION 7.3-rc1] HID: logitech-hidpp: hi-res scroll mode forcibly re-enabled on every reconnect for Bolt devices, overriding userspace

[Roman Stingler]

Hi,

Since Bolt receiver support was added in 7.3-rc1, the user-selected
"Scroll Wheel Resolution" (HID++ feature 0x2121 HiRes Wheel) setting on my
MX Master 4 is reset by the kernel every time the device reconnects, most
visibly across every suspend/resume cycle. I disable hi-res scrolling in
Solaar, suspend the laptop, and on resume the mouse is back in hi-res mode
and I have to toggle it manually again.

This worked correctly on 7.2 and is broken on 7.3-rc1 through 7.3-rc3.

#regzbot introduced: 022eb347ff3a48281e7e69c3addcb11bf24afa53


Hardware
========

  Logi Bolt Receiver              046d:c548
  Logitech MX Master 4 (WPID B042), HID++ 4.5, paired to the Bolt receiver
  HIRES WHEEL {2121} V1, multiplier 15

  Host: HP OmniBook Ultra Laptop 14-fd0xxx,
        AMD Ryzen AI 9 HX 375 (family 0x1a model 0x24)
  Distro kernel: 7.3.0-rc3-1-cachyos-rc
  Solaar 1.1.20


Reproduction
============

  1. Pair an MX Master 4 (or other 0x2121-capable mouse) to a Bolt receiver.
  2. In Solaar, set "Scroll Wheel Resolution" to off
     (solaar config 2 hires-smooth-resolution false).
  3. Suspend and resume (s2idle here, but any reconnect does it -- turning
     the mouse off and on again is enough).
  4. The setting is back on.

Solaar shows the divergence between what the user asked for and what the
device is actually in:

     18: HIRES WHEEL            {2121} V1
         Multiplier: 15
         Has invert: Normal wheel motion
         Has ratchet switch: Normal wheel mode
         High resolution mode
         HID notification
         Scroll Wheel Direction (saved): False
         Scroll Wheel Direction        : False
         Scroll Wheel Resolution (saved): False
         Scroll Wheel Resolution        : True
         Scroll Wheel Diversion (saved): False
         Scroll Wheel Diversion        : False

"(saved)" is what I configured; the live value has been overwritten.


Analysis
========

I have not bisected this, but I believe the cause is clear from inspection.

Before 022eb347ff3a4 ("HID: logitech: add Bolt receiver support for Logitech
HID++ devices"), USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER was not present in
logi_dj_receivers[] -- it appeared only in hid-quirks.c and hid-multitouch.c.
So a Bolt-connected mouse never became a HID_GROUP_LOGITECH_DJ_DEVICE child,
hid-logitech-hidpp never bound to it, and the kernel never touched HID++
feature 0x2121. The device was driven by hid-generic and userspace was the
only writer of the wheel mode, so the setting stuck.

With Bolt support in place the mouse is now a hid-logitech-hidpp device:

  logitech-djreceiver 0003:046D:C548.0007: device of type Bolt (0x10) connected on slot 2
  input: Logitech Wireless Mouse PID:b042 Mouse as /devices/.../0003:046D:C548.0007/0003:046D:B042.0009/input/input22
  logitech-hidpp-device 0003:046D:B042.0009: input,hidraw7: USB HID v1.11 Mouse [Logitech Wireless Mouse PID:b042] on usb-0000:c5:00.4-1.3.2.4/input2:2
  logitech-hidpp-device 0003:046D:B042.0009: HID++ 4.5 device connected.

and every reconnect now runs hidpp_connect_event(), which unconditionally
does:

	if (hidpp->capabilities & HIDPP_CAPABILITY_HI_RES_SCROLL)
		hi_res_scroll_enable(hidpp);

and hi_res_scroll_enable() in turn does:

	ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, false);
	                            /* invert ^     ^ high_resolution */

with high_resolution hard-coded to true. There is no record of a user
preference and nothing consults the device's current mode, so any userspace
choice is discarded at connect time.

Note this is not a suspend/resume bug as such -- hidpp_driver has no .resume
or .reset_resume callback. The reconnect is driven purely by the receiver
re-announcing the device after USB resume, which queues hidpp_connect_event
via hidpp_report_is_connect_event().

The same call hard-codes invert = false, so "Scroll Wheel Direction" is reset
by the same path for anyone who inverts their wheel.

I realise hid-logitech-hidpp has always enabled hi-res scrolling at connect
for devices it drives, and that Unifying users have lived with this for
years. What changed in 7.3 is the set of devices this applies to: Bolt
devices were previously outside the driver's reach and are now inside it, so
for those users this is a user-visible behavioural regression.

Commit f0866517be934 ("HID: logitech-hidpp: sync wheel multiplier on wheel
mode changes") in 7.2 already added hidpp20_hires_wheel_raw_event() to notice
an external SetWheelMode and re-sync the cached multiplier. The driver
therefore sees userspace changing the mode; it just does not remember the
choice across a reconnect. Persisting the last observed mode and restoring
that in hi_res_scroll_enable(), rather than unconditionally forcing hi-res,
would fix this. I am happy to test any patch.


Possibly related
================

On this same Bolt topology the wheel also scrolls far too far per detent,
apparently because hid-logitech-dj does not forward the hi-res wheel reports
to hid-logitech-hidpp, so the multiplier-15 steps reach userspace unscaled.
There is an out-of-tree DKMS workaround for exactly this WPID:

  https://github.com/Magnetar-OS/logitech-bolt-hidpp-dkms

I am reporting only the mode-reset problem here, but the two look like
neighbouring consequences of the same commit and may be worth considering
together.

Thanks,
Roman