From: johannes.goede@oss.qualcomm.com
To: Roman Stingler <roman.stingler@gmail.com>,
Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <bentiss@kernel.org>
Cc: Lovekesh Solanki <lovekeshsolanki00@gmail.com>,
Erik Hakansson <erikhakan@gmail.com>,
Filipe Lains <lains@riseup.net>,
Bastien Nocera <hadess@hadess.net>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
regressions@lists.linux.dev
Subject: Re: [PATCH] HID: logitech-hidpp: do not overwrite the device's hi-res wheel mode
Date: Fri, 25 Sep 2026 11:50:59 +0200 [thread overview]
Message-ID: <9acaeb9e-551d-474a-9c3e-9be5f667297f@oss.qualcomm.com> (raw)
In-Reply-To: <20260923181203.422097-1-roman.stingler@gmail.com>
Hi,
On 23-Sep-26 20:11, Roman Stingler wrote:
> hi_res_scroll_enable() unconditionally puts HID++ 2.0 devices supporting
> the HiRes Wheel feature (0x2121) into high-resolution mode on every
> connect event.
>
> On at least the MX Master 4 that mode is persistent state in the device.
> With hid-logitech-hidpp unloaded, a mode set from userspace survives
> switching the mouse off and on again. Writing it at connect therefore
> destroys a setting the user configured, and does so on every probe --
> cold boot, receiver replug or module reload -- so userspace cannot
> reliably keep it either: it gets no indication that the mode it set has
> been changed underneath it.
>
> This became visible when Bolt receivers gained support in 7.3. Before
> that these devices were driven by hid-generic, hid-logitech-hidpp never
> bound to them, and nothing in the kernel wrote the setting.
>
> 0x2121 exposes getWheelMode alongside setWheelMode. Read the current
> mode and scale vertical_wheel_counter.wheel_multiplier to match rather
> than forcing high resolution: a device left in high-resolution mode
> still gets its multiplier, and one the user configured for low
> resolution is left alone.
>
> Note this changes behaviour for devices sitting at a low-resolution
> factory default -- the kernel will no longer switch those to
> high-resolution scrolling.
>
> Link: https://lore.kernel.org/all/20260920094508.39682-1-roman.stingler@gmail.com/
> Signed-off-by: Roman Stingler <roman.stingler@gmail.com>
I assume the low-res mode factory default is because not all OS-es
can handle hires mode (I guess mostly much older Os-es cannot).
This regresses (new factory default mice) to no longer support
hi-res wheel mode at all under Linux, even the non Bolt ones even
though this is only a Bolt issue.
So in so far as this is a solution at all, it really should be
limited to Bolt devices only. Although I wonder what switching
Bolt devices to the hidpp driver wins us after this patch?
Do they still gain any meaningful functionality from the switch
to the hidpp driver?
AlsoI wonder if there is not a non-persistent equivalent of
setWheelMode, that would be ideal.
Do we know what Windows (with Logitech drivers) does here?
I cannot believe that Windows will not use hi-res wheel mode
in that case...
Regards,
Hans
prev parent reply other threads:[~2026-09-25 9:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 18:11 Roman Stingler
2026-09-25 9:50 ` johannes.goede
2026-09-25 9:50 ` johannes.goede [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9acaeb9e-551d-474a-9c3e-9be5f667297f@oss.qualcomm.com \
--to=johannes.goede@oss.qualcomm.com \
--cc=bentiss@kernel.org \
--cc=erikhakan@gmail.com \
--cc=hadess@hadess.net \
--cc=jikos@kernel.org \
--cc=lains@riseup.net \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lovekeshsolanki00@gmail.com \
--cc=regressions@lists.linux.dev \
--cc=roman.stingler@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®