1. Patchew
  2. linux
  3. View series

[PATCH 0/2] HID: logitech-hidpp: fix Bolt hi-res wheel handling

Erik Håkansson posted 2 patches 1 day, 20 hours ago 
drivers/hid/hid-logitech-hidpp.c | 147 ++++++++++++++++++++++++++++++++-------
1 file changed, 123 insertions(+), 24 deletions(-)
[PATCH 0/2] HID: logitech-hidpp: fix Bolt hi-res wheel handling
Posted by Erik Håkansson 1 day, 20 hours ago 
This series aims to fix high-resolution wheel handling for Logitech devices
connected through Bolt receivers as well as respect user settings for
scroll behaviour.

Patch 1 is Rafael Passos’s original implementation:

https://lore.kernel.org/linux-input/20260904034843.1340846-1-rafael@rcpassos.me/

His patch routes Bolt wheel movement through the HID++ child, where the
device’s HiRes Wheel multiplier can be applied. Patch 2 builds on
Rafael’s work by 1. supporting both high-resolution and low-resolution
scroll events, and 2. preserving user-selected high-resolution and
inversion settings.

The follow-up patch was developed with reference to the patches and
reported behavior in Magnetar-OS’s `logitech-bolt-hidpp-dkms` repository:

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

So my assumption right now is that the reason for the divergent results
people have had with the two different fix approaches (i.e. either passing
interface 0 and 1 as DJ interfaces, or Rafael's approach), where it works
for some, and only sometimes, etc. is that with user settings coming from
Solaar, we may end up in weird states.
For example, in the original patch, high-resolution events would go through
the generic HID which would treat each tick as a full wheel event, thus 
scaling the scroll way too far. That was solved with Rafael's patch but
that would instead fail to handle low-resolution events if high resolution
was turned off in Solaar while use_hidpp remained enabled, so a low-resolution
delta would be treated as high-resolution, which would result instead in a 
too slow scroll. Possibly, when Oleksandr switched devices, Solaar reapplied
some saved user settings, which conflicted with the driver logic.

With this patch, user settings from Solaar (or elsewhere) for high-resolution
mode and scroll inversion will be respected, 
and scrolling should work both in high-resolution and low-resolution mode.
However, if user-space turns off the use_hidpp setting while high_resolution
remains on, this will route high-resolution scroll events to generic HID.
Thus, when high_resolution is on for a Bolt device, the driver will
force use_hidpp to be on during initialisation or reinitialisation, because
otherwise the scaling issue will return.
Solaar may still, after driver initialisation, reapply a saved use_hidpp
setting of off while high_resolution remains on, or the user may change it
to off, which will cause the issue even with this patch.

In theory, it should be possible to look at incoming setWheelMode responses
or notifications and, just like on initialisation, enforce use_hidpp as long
as high_resolution is set on a Bolt device. However, I don't know how Solaar
will behave then. There's a risk it will trigger a back-and-forth if Solaar
reapplies its saved setting after the kernel corrects it. Also, even if that
doesn't happen, we should respect user choice even for use_hidpp. Perhaps
the Solaar team can be informed about the problem so they can add a warning
text.

Note that I don't have a Bolt mouse to test this with, and my theory is 
mostly inferred, so I would appreciate very much if people with various
Bolt mice could test it out. Also great if you try different settings in 
Solaar, but note that use_hidpp must be on if high_resolution is on, so 
either set it to on in Solaar, or to ignore.

Link: https://lore.kernel.org/linux-input/20260712003051.338194-2-erikhakan@gmail.com/
Link: https://lore.kernel.org/linux-input/20260901-bolt-scroll-fix-v1-1-58bca7ae487f@protonmail.com/
Link: https://lore.kernel.org/linux-input/LYMlyJcyQt29e1KlLnEoLw@natalenko.name/
Link: https://lore.kernel.org/linux-input/20260920094508.39682-1-roman.stingler@gmail.com/
Signed-off-by: Erik Håkansson <erikhakan@gmail.com>
---
Erik Håkansson (1):
      HID: logitech-hidpp: fix Bolt wheel mode handling

Rafael Passos (1):
      HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

 drivers/hid/hid-logitech-hidpp.c | 147 ++++++++++++++++++++++++++++++++-------
 1 file changed, 123 insertions(+), 24 deletions(-)
---
base-commit: 022eb347ff3a48281e7e69c3addcb11bf24afa53
change-id: 20260921-feature-bolt-fix-5f1f642496df

Best regards,
-- 
Erik Håkansson <erikhakan@gmail.com>
Re: [PATCH 0/2] HID: logitech-hidpp: fix Bolt hi-res wheel handling
Posted by Oleksandr Natalenko 1 day, 7 hours ago 
Hello.

On úterý 22. září 2026 19:40:26, středoevropský letní čas Erik Håkansson wrote:
> This series aims to fix high-resolution wheel handling for Logitech devices
> connected through Bolt receivers as well as respect user settings for
> scroll behaviour.
> 
> Patch 1 is Rafael Passos’s original implementation:
> 
> https://lore.kernel.org/linux-input/20260904034843.1340846-1-rafael@rcpassos.me/
> 
> His patch routes Bolt wheel movement through the HID++ child, where the
> device’s HiRes Wheel multiplier can be applied. Patch 2 builds on
> Rafael’s work by 1. supporting both high-resolution and low-resolution
> scroll events, and 2. preserving user-selected high-resolution and
> inversion settings.
> 
> The follow-up patch was developed with reference to the patches and
> reported behavior in Magnetar-OS’s `logitech-bolt-hidpp-dkms` repository:
> 
> https://github.com/Magnetar-OS/logitech-bolt-hidpp-dkms/tree/main/patches
> 
> So my assumption right now is that the reason for the divergent results
> people have had with the two different fix approaches (i.e. either passing
> interface 0 and 1 as DJ interfaces, or Rafael's approach), where it works
> for some, and only sometimes, etc. is that with user settings coming from
> Solaar, we may end up in weird states.
> For example, in the original patch, high-resolution events would go through
> the generic HID which would treat each tick as a full wheel event, thus 
> scaling the scroll way too far. That was solved with Rafael's patch but
> that would instead fail to handle low-resolution events if high resolution
> was turned off in Solaar while use_hidpp remained enabled, so a low-resolution
> delta would be treated as high-resolution, which would result instead in a 
> too slow scroll. Possibly, when Oleksandr switched devices, Solaar reapplied
> some saved user settings, which conflicted with the driver logic.
> 
> With this patch, user settings from Solaar (or elsewhere) for high-resolution
> mode and scroll inversion will be respected, 
> and scrolling should work both in high-resolution and low-resolution mode.
> However, if user-space turns off the use_hidpp setting while high_resolution
> remains on, this will route high-resolution scroll events to generic HID.
> Thus, when high_resolution is on for a Bolt device, the driver will
> force use_hidpp to be on during initialisation or reinitialisation, because
> otherwise the scaling issue will return.
> Solaar may still, after driver initialisation, reapply a saved use_hidpp
> setting of off while high_resolution remains on, or the user may change it
> to off, which will cause the issue even with this patch.
> 
> In theory, it should be possible to look at incoming setWheelMode responses
> or notifications and, just like on initialisation, enforce use_hidpp as long
> as high_resolution is set on a Bolt device. However, I don't know how Solaar
> will behave then. There's a risk it will trigger a back-and-forth if Solaar
> reapplies its saved setting after the kernel corrects it. Also, even if that
> doesn't happen, we should respect user choice even for use_hidpp. Perhaps
> the Solaar team can be informed about the problem so they can add a warning
> text.
> 
> Note that I don't have a Bolt mouse to test this with, and my theory is 
> mostly inferred, so I would appreciate very much if people with various
> Bolt mice could test it out. Also great if you try different settings in 
> Solaar, but note that use_hidpp must be on if high_resolution is on, so 
> either set it to on in Solaar, or to ignore.
> 
> Link: https://lore.kernel.org/linux-input/20260712003051.338194-2-erikhakan@gmail.com/
> Link: https://lore.kernel.org/linux-input/20260901-bolt-scroll-fix-v1-1-58bca7ae487f@protonmail.com/
> Link: https://lore.kernel.org/linux-input/LYMlyJcyQt29e1KlLnEoLw@natalenko.name/
> Link: https://lore.kernel.org/linux-input/20260920094508.39682-1-roman.stingler@gmail.com/
> Signed-off-by: Erik Håkansson <erikhakan@gmail.com>
> ---
> Erik Håkansson (1):
>       HID: logitech-hidpp: fix Bolt wheel mode handling
> 
> Rafael Passos (1):
>       HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master
> 
>  drivers/hid/hid-logitech-hidpp.c | 147 ++++++++++++++++++++++++++++++++-------
>  1 file changed, 123 insertions(+), 24 deletions(-)
> ---
> base-commit: 022eb347ff3a48281e7e69c3addcb11bf24afa53
> change-id: 20260921-feature-bolt-fix-5f1f642496df
> 
> Best regards,

Not sure if I'm testing this right, but with v7.3-rc4 and these two patches scrolling works OK as long as I keep "Scroll Wheel Resolution" in Solaar off. Unlike with unpatched kernel, scrolling doesn't go crazy if I switch between devices. But if I switch "Scroll Wheel Resolution" on, scrolling jumps crazy again.

-- 
Oleksandr Natalenko, MSE
Re: [PATCH 0/2] HID: logitech-hidpp: fix Bolt hi-res wheel handling
Posted by erikhakan@gmail.com 22 hours ago 
Hi!

> On Sep 23 2026, Oleksandr Natalenko wrote:
> > Hello.
> >
> > Not sure if I'm testing this right, but with v7.3-rc4 and these two patches scrolling works OK as long as I keep "Scroll Wheel Resolution" in Solaar off. Unlike with unpatched kernel, scrolling doesn't go crazy if I switch between devices. But if I switch "Scroll Wheel Resolution" on, scrolling jumps crazy again.

Okay, the expectation would be that scrolling would remain working
with "Scroll Wheel Resolution" (==high_resolution) either ON or OFF,
but when it's ON, it would also need "Scroll Wheel Diversion"
(==use_hidpp) to be ON (or ignored, but ignore may retain a previous
user setting, so a reconnect after setting that would be good.).

When you tested, do you remember what the setting for Scroll Wheel 
Diversion was? With it set to off, the scroll events will not go 
through the hid++ driver, so if high resolution is turned on, the 
events will be misinterpreted by the generic HID driver that expects
low resolution events.

> Hopefully we've got all of the involved people here.
> 
> Honestly, this whole situation has been running for too long: Bolt can't
> be handled as a DJ receiver, and all the quirks I'm seeing here are
> making things even worse, with the "as long as I keep [some user
> settings] off".
> 
> Bolt in kernel was adding in 7.3, so I'm going to revert it now, and
> we'll have to have a fully working plan for an eventual inclusion in a
> future kernel version.
> 
> Cheers,
> Benjamin

I totally agree that this is the right call, despite this being my first
kernel patch and I was a bit excited to see it roll out :) But of course
I don't want my first contribution to be problematic, so I agree with
reverting it.
For what it's worth, I checked with my G502 Lightspeed mouse, and it too
has incompatibilities between kernel and userspace, but in a rather
oppsite fashion: When "Scroll Wheel Diversion" (=use_hidpp) is turned
ON for it, scrolling stops working altogether, and looking at the code
I think that might actually be true for any device that supports HID++
function 0x2121, i.e. the more modern high resolution scroll.
So, having an incompatibility between the kernel driver and some Solaar
settings would not be new to the Bolt driver, it would just be a
different incompatibility.

But anyway, let's see if Oleksandr can confirm if the issue remains even
with use_hidpp ON. If not, then I think we're hopefully done with at
least the scroll scaling issue, especially if more people can test as
well. But of course there's still the other issue of not being able to
distinguish between devices.

Cheers!
Erik
Re: [PATCH 0/2] HID: logitech-hidpp: fix Bolt hi-res wheel handling
Posted by Oleksandr Natalenko 7 hours ago 
Hello.

On středa 23. září 2026 18:09:01, středoevropský letní čas erikhakan@gmail.com wrote:
> > On Sep 23 2026, Oleksandr Natalenko wrote:
> > > Not sure if I'm testing this right, but with v7.3-rc4 and these two patches scrolling works OK as long as I keep "Scroll Wheel Resolution" in Solaar off. Unlike with unpatched kernel, scrolling doesn't go crazy if I switch between devices. But if I switch "Scroll Wheel Resolution" on, scrolling jumps crazy again.
> 
> Okay, the expectation would be that scrolling would remain working
> with "Scroll Wheel Resolution" (==high_resolution) either ON or OFF,
> but when it's ON, it would also need "Scroll Wheel Diversion"
> (==use_hidpp) to be ON (or ignored, but ignore may retain a previous
> user setting, so a reconnect after setting that would be good.).
> 
> When you tested, do you remember what the setting for Scroll Wheel 
> Diversion was? With it set to off, the scroll events will not go 
> through the hid++ driver, so if high resolution is turned on, the 
> events will be misinterpreted by the generic HID driver that expects
> low resolution events.

You are right, the "Scroll Wheel Diversion" diversion switch was off for me. I've enabled it along with "Scroll Wheel Resolution", and the scrolling stays normal and survives both resume and device switching.

Somewhat unrelated note: if I enable "Thumb Wheel Diversion", the thumb wheel stops working altogether. It's probably not supported by the driver at all in HID++ mode?

Thank you.

> 
> > Hopefully we've got all of the involved people here.
> > 
> > Honestly, this whole situation has been running for too long: Bolt can't
> > be handled as a DJ receiver, and all the quirks I'm seeing here are
> > making things even worse, with the "as long as I keep [some user
> > settings] off".
> > 
> > Bolt in kernel was adding in 7.3, so I'm going to revert it now, and
> > we'll have to have a fully working plan for an eventual inclusion in a
> > future kernel version.
> 
> I totally agree that this is the right call, despite this being my first
> kernel patch and I was a bit excited to see it roll out :) But of course
> I don't want my first contribution to be problematic, so I agree with
> reverting it.
> For what it's worth, I checked with my G502 Lightspeed mouse, and it too
> has incompatibilities between kernel and userspace, but in a rather
> oppsite fashion: When "Scroll Wheel Diversion" (=use_hidpp) is turned
> ON for it, scrolling stops working altogether, and looking at the code
> I think that might actually be true for any device that supports HID++
> function 0x2121, i.e. the more modern high resolution scroll.
> So, having an incompatibility between the kernel driver and some Solaar
> settings would not be new to the Bolt driver, it would just be a
> different incompatibility.
> 
> But anyway, let's see if Oleksandr can confirm if the issue remains even
> with use_hidpp ON. If not, then I think we're hopefully done with at
> least the scroll scaling issue, especially if more people can test as
> well. But of course there's still the other issue of not being able to
> distinguish between devices.

-- 
Oleksandr Natalenko, MSE

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.