[PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[Rafael Passos]

The new added support for Logitech HID++ caused this mouse to
scroll too far for each tic when using the USB dongle (Bolt).
Previously, this mouse was handled as hid_generic over the Bold
connection, and logitech-hidpp when over Bluetooth.

Cause:
Over the Bolt receiver, the mouse reports  are forwarded over the generic
interface 1, instead of the new HID++ child device. The generic hid does
now know about the hi-res scrolling used by the HID++.
In my tests, I discovered this mouse has a multiplier factor of 15. This
multiplier is only handled by the logitech-hidpp driver. When piped to
hid_generic, the "hi-res" value was piped to a "low-res" field, making
the scroll unbearable.

The fix routes the wheel using the HID++, so the ticks are scaled by the
multiplier and correctly reported as a hi-res event.

I also had to move the hidpp_is_bolt_child function up, to use it in the
hidpp_connect_event function, where the gate for
hidpp_initialize_hires_scroll function lives.

Tested with:
- Logitech MX Master 3S (mouse) via Bolt receiver and Bluetooth.

Fixes: 022eb347ff3a ("HID: logitech: add Bolt receiver support for Logitech HID++ devices")
Signed-off-by: Rafael Passos <rafael@rcpassos.me>
---

Hi,
I decided to send this patch as soon as I made it work, to try to make
it into this fix cycle.

I do not have other devices to test this with.
It would *be great* to have other users testing this.

Lastly, I decided to make all the changes in a single patch. 
But I can break it up if asked.

Thanks,
Rafael


 drivers/hid/hid-logitech-hidpp.c | 47 ++++++++++++++++++++++----------
 1 file changed, 32 insertions(+), 15 deletions(-)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 1504de32b1c84..960543bfd5ea1 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -3900,6 +3900,19 @@ static int hidpp10_consumer_keys_raw_event(struct hidpp_device *hidpp,
 	return 1;
 }
 
+static bool hidpp_is_bolt_child(struct hid_device *hdev)
+{
+	struct device *parent = hdev->dev.parent;
+	struct hid_device *receiver_hdev;
+
+	if (!parent)
+		return false;
+
+	receiver_hdev = to_hid_device(parent);
+	return receiver_hdev->vendor == USB_VENDOR_ID_LOGITECH &&
+	       receiver_hdev->product == USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER;
+}
+
 /* -------------------------------------------------------------------------- */
 /* High-resolution scroll wheels                                              */
 /* -------------------------------------------------------------------------- */
@@ -3910,7 +3923,9 @@ static int hi_res_scroll_enable(struct hidpp_device *hidpp)
 	u8 multiplier = 1;
 
 	if (hidpp->capabilities & HIDPP_CAPABILITY_HIDPP20_HI_RES_WHEEL) {
-		ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, false);
+		bool use_hidpp = hidpp_is_bolt_child(hidpp->hid_dev);
+
+		ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, use_hidpp);
 		if (ret == 0)
 			ret = hidpp_hrw_get_wheel_capability(hidpp, &multiplier);
 	} else if (hidpp->capabilities & HIDPP_CAPABILITY_HIDPP20_HI_RES_SCROLL) {
@@ -3998,6 +4013,19 @@ static int hidpp20_hires_wheel_raw_event(struct hidpp_device *hidpp,
 		return 1;
 	}
 
+	/* wheel movement event: 16-bit signed delta in HID++ ticks */
+	if ((data[3] & 0xf0) == 0x00 && size >= 7 && hidpp->input &&
+	    hidpp->vertical_wheel_counter.wheel_multiplier) {
+		s16 delta = get_unaligned_be16(&data[5]);
+
+		if (delta) {
+			hidpp_scroll_counter_handle_scroll(hidpp->input,
+				&hidpp->vertical_wheel_counter, delta);
+			input_sync(hidpp->input);
+		}
+		return 1;
+	}
+
 	return 0;
 }
 
@@ -4405,19 +4433,6 @@ static int hidpp_initialize_battery(struct hidpp_device *hidpp)
 	return ret;
 }
 
-static bool hidpp_is_bolt_child(struct hid_device *hdev)
-{
-	struct device *parent = hdev->dev.parent;
-	struct hid_device *receiver_hdev;
-
-	if (!parent)
-		return false;
-
-	receiver_hdev = to_hid_device(parent);
-	return receiver_hdev->vendor == USB_VENDOR_ID_LOGITECH &&
-	       receiver_hdev->product == USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER;
-}
-
 static int hidpp_bolt_init(struct hidpp_device *hidpp)
 {
 	struct hid_device *hdev = hidpp->hid_dev;
@@ -4579,7 +4594,9 @@ static void hidpp_connect_event(struct work_struct *work)
 	}
 
 	hidpp_initialize_battery(hidpp);
-	if (!hid_is_usb(hidpp->hid_dev))
+
+	if (!hid_is_usb(hidpp->hid_dev) ||
+	    hidpp_is_bolt_child(hidpp->hid_dev))
 		hidpp_initialize_hires_scroll(hidpp);
 
 	/* forward current battery state */
-- 
2.55.0

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unconditional and improperly guarded cast of the parent device to `struct hid_device` in `hidpp_is_bolt_child()` causes type confusion and out-of-bounds memory access for Bluetooth and native USB devices.
- [High] Time-of-check to time-of-use (TOCTOU) data race between `hidpp20_hires_wheel_raw_event()` and `hidpp_connect_event()` leading to a Use-After-Free of `hidpp->input`.
--

commit 1aae454b03bbd4a45bdfdb3bc2a196f15d06fbfa
Author: Rafael Passos <rafael@rcpassos.me>

HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

This commit fixes hi-res scrolling on the MX Master 3S when connected
via the Bolt receiver by routing wheel events through the HID++ driver
instead of hid_generic. It also adjusts initialization checks for Bolt
devices.

> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> index 1504de32b1c84..960543bfd5ea1 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -3900,6 +3900,19 @@ static int hidpp10_consumer_keys_raw_event(struct hidpp_device *hidpp,
>  	return 1;
>  }
>  
> +static bool hidpp_is_bolt_child(struct hid_device *hdev)
> +{
> +	struct device *parent = hdev->dev.parent;
> +	struct hid_device *receiver_hdev;
> +
> +	if (!parent)
> +		return false;
> +
> +	receiver_hdev = to_hid_device(parent);
> +	return receiver_hdev->vendor == USB_VENDOR_ID_LOGITECH &&
> +	       receiver_hdev->product == USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER;
> +}
> +

[Severity: High]
Does this safely handle native USB devices? When this is called for a native
USB device, the parent device is a struct usb_interface, not a struct
hid_device. 

Using to_hid_device(parent) subtracts the container_of offset for a
hid_device from the dev pointer, resulting in a pointer well before the
allocated usb_interface structure. Accessing receiver_hdev->vendor will then
cause an out-of-bounds memory read.

[ ... ]

> @@ -3910,7 +3923,9 @@ static int hi_res_scroll_enable(struct hidpp_device *hidpp)
>  	u8 multiplier = 1;
>  
>  	if (hidpp->capabilities & HIDPP_CAPABILITY_HIDPP20_HI_RES_WHEEL) {
> -		ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, false);
> +		bool use_hidpp = hidpp_is_bolt_child(hidpp->hid_dev);
> +

[Severity: High]
Could this unconditionally trigger the out-of-bounds read described above for
all HID++ 2.0 devices? This includes native USB and Bluetooth devices where
the parent is not a hid_device.

[ ... ]

> @@ -3998,6 +4013,19 @@ static int hidpp20_hires_wheel_raw_event(struct hidpp_device *hidpp,
>  		return 1;
>  	}
>  
> +	/* wheel movement event: 16-bit signed delta in HID++ ticks */
> +	if ((data[3] & 0xf0) == 0x00 && size >= 7 && hidpp->input &&
> +	    hidpp->vertical_wheel_counter.wheel_multiplier) {
> +		s16 delta = get_unaligned_be16(&data[5]);
> +
> +		if (delta) {
> +			hidpp_scroll_counter_handle_scroll(hidpp->input,
> +				&hidpp->vertical_wheel_counter, delta);

[Severity: High]
Is there a Time-of-Check to Time-of-Use (TOCTOU) race condition here?

Since hid_device_io_start() has already been called during probe, hardware
events can fire concurrently with hidpp_connect_event().

If this raw event handler checks hidpp->input and proceeds, but
concurrently hidpp_connect_event() encounters an error (e.g. from
input_register_device failing) and executes:

    hidpp->input = NULL;
    input_free_device(input);

Could this lockless dereference of hidpp->input in
hidpp_scroll_counter_handle_scroll() result in a use-after-free?

[ ... ]

> @@ -4579,7 +4594,9 @@ static void hidpp_connect_event(struct work_struct *work)
>  	}
>  
>  	hidpp_initialize_battery(hidpp);
> -	if (!hid_is_usb(hidpp->hid_dev))
> +
> +	if (!hid_is_usb(hidpp->hid_dev) ||
> +	    hidpp_is_bolt_child(hidpp->hid_dev))
>  		hidpp_initialize_hires_scroll(hidpp);

[Severity: High]
Could this also trigger the out-of-bounds read in hidpp_is_bolt_child() for
native USB devices?

For a native USB device, hid_is_usb() is true, so !hid_is_usb() evaluates to
false. This forces the logical OR to evaluate hidpp_is_bolt_child(), passing
the USB device into the function that unsafely casts the parent device.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260904034843.1340846-1-rafael@rcpassos.me?part=1

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[Alexey Zagorodnikov]

Hi, thanks for your patch. I've tested it with my MX Master 4 + Bolt.

I'm not seeing a regression from mainline hid++ enabling, as in Solaar 
high-res scrolling was disabled in my config.

But with hid++ for Bolt enabled by mainline and your patch fixing 
high-res scroll init, I finally got smooth high-res scrolling on MX 
Master 4 via a Bolt connection.

Tested-by: Alexey Zagorodnikov <xglooom@gmail.com>

On 9/4/26 08:48, Rafael Passos wrote:
> The new added support for Logitech HID++ caused this mouse to
> scroll too far for each tic when using the USB dongle (Bolt).
> Previously, this mouse was handled as hid_generic over the Bold
> connection, and logitech-hidpp when over Bluetooth.
>
> Cause:
> Over the Bolt receiver, the mouse reports  are forwarded over the generic
> interface 1, instead of the new HID++ child device. The generic hid does
> now know about the hi-res scrolling used by the HID++.
> In my tests, I discovered this mouse has a multiplier factor of 15. This
> multiplier is only handled by the logitech-hidpp driver. When piped to
> hid_generic, the "hi-res" value was piped to a "low-res" field, making
> the scroll unbearable.
>
> The fix routes the wheel using the HID++, so the ticks are scaled by the
> multiplier and correctly reported as a hi-res event.
>
> I also had to move the hidpp_is_bolt_child function up, to use it in the
> hidpp_connect_event function, where the gate for
> hidpp_initialize_hires_scroll function lives.
>
> Tested with:
> - Logitech MX Master 3S (mouse) via Bolt receiver and Bluetooth.
>
> Fixes: 022eb347ff3a ("HID: logitech: add Bolt receiver support for Logitech HID++ devices")
> Signed-off-by: Rafael Passos <rafael@rcpassos.me>
> ---
>
> Hi,
> I decided to send this patch as soon as I made it work, to try to make
> it into this fix cycle.
>
> I do not have other devices to test this with.
> It would *be great* to have other users testing this.
>
> Lastly, I decided to make all the changes in a single patch.
> But I can break it up if asked.
>
> Thanks,
> Rafael
>
>
>   drivers/hid/hid-logitech-hidpp.c | 47 ++++++++++++++++++++++----------
>   1 file changed, 32 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> index 1504de32b1c84..960543bfd5ea1 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -3900,6 +3900,19 @@ static int hidpp10_consumer_keys_raw_event(struct hidpp_device *hidpp,
>   	return 1;
>   }
>   
> +static bool hidpp_is_bolt_child(struct hid_device *hdev)
> +{
> +	struct device *parent = hdev->dev.parent;
> +	struct hid_device *receiver_hdev;
> +
> +	if (!parent)
> +		return false;
> +
> +	receiver_hdev = to_hid_device(parent);
> +	return receiver_hdev->vendor == USB_VENDOR_ID_LOGITECH &&
> +	       receiver_hdev->product == USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER;
> +}
> +
>   /* -------------------------------------------------------------------------- */
>   /* High-resolution scroll wheels                                              */
>   /* -------------------------------------------------------------------------- */
> @@ -3910,7 +3923,9 @@ static int hi_res_scroll_enable(struct hidpp_device *hidpp)
>   	u8 multiplier = 1;
>   
>   	if (hidpp->capabilities & HIDPP_CAPABILITY_HIDPP20_HI_RES_WHEEL) {
> -		ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, false);
> +		bool use_hidpp = hidpp_is_bolt_child(hidpp->hid_dev);
> +
> +		ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, use_hidpp);
>   		if (ret == 0)
>   			ret = hidpp_hrw_get_wheel_capability(hidpp, &multiplier);
>   	} else if (hidpp->capabilities & HIDPP_CAPABILITY_HIDPP20_HI_RES_SCROLL) {
> @@ -3998,6 +4013,19 @@ static int hidpp20_hires_wheel_raw_event(struct hidpp_device *hidpp,
>   		return 1;
>   	}
>   
> +	/* wheel movement event: 16-bit signed delta in HID++ ticks */
> +	if ((data[3] & 0xf0) == 0x00 && size >= 7 && hidpp->input &&
> +	    hidpp->vertical_wheel_counter.wheel_multiplier) {
> +		s16 delta = get_unaligned_be16(&data[5]);
> +
> +		if (delta) {
> +			hidpp_scroll_counter_handle_scroll(hidpp->input,
> +				&hidpp->vertical_wheel_counter, delta);
> +			input_sync(hidpp->input);
> +		}
> +		return 1;
> +	}
> +
>   	return 0;
>   }
>   
> @@ -4405,19 +4433,6 @@ static int hidpp_initialize_battery(struct hidpp_device *hidpp)
>   	return ret;
>   }
>   
> -static bool hidpp_is_bolt_child(struct hid_device *hdev)
> -{
> -	struct device *parent = hdev->dev.parent;
> -	struct hid_device *receiver_hdev;
> -
> -	if (!parent)
> -		return false;
> -
> -	receiver_hdev = to_hid_device(parent);
> -	return receiver_hdev->vendor == USB_VENDOR_ID_LOGITECH &&
> -	       receiver_hdev->product == USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER;
> -}
> -
>   static int hidpp_bolt_init(struct hidpp_device *hidpp)
>   {
>   	struct hid_device *hdev = hidpp->hid_dev;
> @@ -4579,7 +4594,9 @@ static void hidpp_connect_event(struct work_struct *work)
>   	}
>   
>   	hidpp_initialize_battery(hidpp);
> -	if (!hid_is_usb(hidpp->hid_dev))
> +
> +	if (!hid_is_usb(hidpp->hid_dev) ||
> +	    hidpp_is_bolt_child(hidpp->hid_dev))
>   		hidpp_initialize_hires_scroll(hidpp);
>   
>   	/* forward current battery state */

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[Erik Håkansson]

Hi!
Is this the same issue as in
https://lore.kernel.org/linux-input/20260901-bolt-scroll-fix-v1-1-58bca7ae487f@protonmail.com/
The symptoms seem similar at least, and if so the approach to fixing
it in that case is to simply treat Bolt devices like previous DJ
devices, rather than having special treatment for Bolt.
Can you who have Bolt mice maybe test that patch too to see if it
solves the same issue?
Regards
Erik

On 9/4/26 09:44, Alexey Zagorodnikov wrote:
> Hi, thanks for your patch. I've tested it with my MX Master 4 + Bolt.
>
> I'm not seeing a regression from mainline hid++ enabling, as in Solaar 
> high-res scrolling was disabled in my config.
>
> But with hid++ for Bolt enabled by mainline and your patch fixing 
> high-res scroll init, I finally got smooth high-res scrolling on MX 
> Master 4 via a Bolt connection.
>
> Tested-by: Alexey Zagorodnikov <xglooom@gmail.com>
>
> On 9/4/26 08:48, Rafael Passos wrote:
>> The new added support for Logitech HID++ caused this mouse to
>> scroll too far for each tic when using the USB dongle (Bolt).
>> Previously, this mouse was handled as hid_generic over the Bold
>> connection, and logitech-hidpp when over Bluetooth.
>>
>> Cause:
>> Over the Bolt receiver, the mouse reports  are forwarded over the 
>> generic
>> interface 1, instead of the new HID++ child device. The generic hid does
>> now know about the hi-res scrolling used by the HID++.
>> In my tests, I discovered this mouse has a multiplier factor of 15. This
>> multiplier is only handled by the logitech-hidpp driver. When piped to
>> hid_generic, the "hi-res" value was piped to a "low-res" field, making
>> the scroll unbearable.
>>
>> The fix routes the wheel using the HID++, so the ticks are scaled by the
>> multiplier and correctly reported as a hi-res event.
>>
>> I also had to move the hidpp_is_bolt_child function up, to use it in the
>> hidpp_connect_event function, where the gate for
>> hidpp_initialize_hires_scroll function lives.
>>
>> Tested with:
>> - Logitech MX Master 3S (mouse) via Bolt receiver and Bluetooth.
>>
>> Fixes: 022eb347ff3a ("HID: logitech: add Bolt receiver support for 
>> Logitech HID++ devices")
>> Signed-off-by: Rafael Passos <rafael@rcpassos.me>
>> ---
>>
>> Hi,
>> I decided to send this patch as soon as I made it work, to try to make
>> it into this fix cycle.
>>
>> I do not have other devices to test this with.
>> It would *be great* to have other users testing this.
>>
>> Lastly, I decided to make all the changes in a single patch.
>> But I can break it up if asked.
>>
>> Thanks,
>> Rafael
>>
>>
>>   drivers/hid/hid-logitech-hidpp.c | 47 ++++++++++++++++++++++----------
>>   1 file changed, 32 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/hid/hid-logitech-hidpp.c 
>> b/drivers/hid/hid-logitech-hidpp.c
>> index 1504de32b1c84..960543bfd5ea1 100644
>> --- a/drivers/hid/hid-logitech-hidpp.c
>> +++ b/drivers/hid/hid-logitech-hidpp.c
>> @@ -3900,6 +3900,19 @@ static int 
>> hidpp10_consumer_keys_raw_event(struct hidpp_device *hidpp,
>>       return 1;
>>   }
>>   +static bool hidpp_is_bolt_child(struct hid_device *hdev)
>> +{
>> +    struct device *parent = hdev->dev.parent;
>> +    struct hid_device *receiver_hdev;
>> +
>> +    if (!parent)
>> +        return false;
>> +
>> +    receiver_hdev = to_hid_device(parent);
>> +    return receiver_hdev->vendor == USB_VENDOR_ID_LOGITECH &&
>> +           receiver_hdev->product == 
>> USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER;
>> +}
>> +
>>   /* 
>> -------------------------------------------------------------------------- 
>> */
>>   /* High-resolution scroll 
>> wheels                                              */
>>   /* 
>> -------------------------------------------------------------------------- 
>> */
>> @@ -3910,7 +3923,9 @@ static int hi_res_scroll_enable(struct 
>> hidpp_device *hidpp)
>>       u8 multiplier = 1;
>>         if (hidpp->capabilities & 
>> HIDPP_CAPABILITY_HIDPP20_HI_RES_WHEEL) {
>> -        ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, false);
>> +        bool use_hidpp = hidpp_is_bolt_child(hidpp->hid_dev);
>> +
>> +        ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, use_hidpp);
>>           if (ret == 0)
>>               ret = hidpp_hrw_get_wheel_capability(hidpp, &multiplier);
>>       } else if (hidpp->capabilities & 
>> HIDPP_CAPABILITY_HIDPP20_HI_RES_SCROLL) {
>> @@ -3998,6 +4013,19 @@ static int 
>> hidpp20_hires_wheel_raw_event(struct hidpp_device *hidpp,
>>           return 1;
>>       }
>>   +    /* wheel movement event: 16-bit signed delta in HID++ ticks */
>> +    if ((data[3] & 0xf0) == 0x00 && size >= 7 && hidpp->input &&
>> +        hidpp->vertical_wheel_counter.wheel_multiplier) {
>> +        s16 delta = get_unaligned_be16(&data[5]);
>> +
>> +        if (delta) {
>> +            hidpp_scroll_counter_handle_scroll(hidpp->input,
>> +                &hidpp->vertical_wheel_counter, delta);
>> +            input_sync(hidpp->input);
>> +        }
>> +        return 1;
>> +    }
>> +
>>       return 0;
>>   }
>>   @@ -4405,19 +4433,6 @@ static int hidpp_initialize_battery(struct 
>> hidpp_device *hidpp)
>>       return ret;
>>   }
>>   -static bool hidpp_is_bolt_child(struct hid_device *hdev)
>> -{
>> -    struct device *parent = hdev->dev.parent;
>> -    struct hid_device *receiver_hdev;
>> -
>> -    if (!parent)
>> -        return false;
>> -
>> -    receiver_hdev = to_hid_device(parent);
>> -    return receiver_hdev->vendor == USB_VENDOR_ID_LOGITECH &&
>> -           receiver_hdev->product == 
>> USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER;
>> -}
>> -
>>   static int hidpp_bolt_init(struct hidpp_device *hidpp)
>>   {
>>       struct hid_device *hdev = hidpp->hid_dev;
>> @@ -4579,7 +4594,9 @@ static void hidpp_connect_event(struct 
>> work_struct *work)
>>       }
>>         hidpp_initialize_battery(hidpp);
>> -    if (!hid_is_usb(hidpp->hid_dev))
>> +
>> +    if (!hid_is_usb(hidpp->hid_dev) ||
>> +        hidpp_is_bolt_child(hidpp->hid_dev))
>>           hidpp_initialize_hires_scroll(hidpp);
>>         /* forward current battery state */

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[Benjamin Tissoires]

On Sep 04 2026, Erik Håkansson wrote:
> Hi!
> Is this the same issue as in
> https://lore.kernel.org/linux-input/20260901-bolt-scroll-fix-v1-1-58bca7ae487f@protonmail.com/
> The symptoms seem similar at least, and if so the approach to fixing
> it in that case is to simply treat Bolt devices like previous DJ
> devices, rather than having special treatment for Bolt.
> Can you who have Bolt mice maybe test that patch too to see if it
> solves the same issue?

FWIW, my initial decision a few years back when Bolt was introduced was
to not include it in the kernel, because there are too many things it's
missing, the most problematic one being that we don't know which device
sends which event.

So basically, there is a chance that the driver sets high-resolution
scrolling on a bolt device, when 2 mice are connected, and one is
capable of it and the other is not. This is unlikely to happen, but is
hard to solve in the kernel.

So I'm happy to wait for testing and patches, but I would also like a
conclusion where bolt doesn't belong to the kernel, and we just revert
the inclusion of the receiver in the dj driver.

Cheers,
Benjamin

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[Alexey Zagorodnikov]

I've tried your patch, and MX Master 4 + Bolt goes crazy, it moves on 
vertical with very high speed, and very very slow on horizontal.

On 9/4/26 21:34, Erik Håkansson wrote:
> Hi!
> Is this the same issue as in
> https://lore.kernel.org/linux-input/20260901-bolt-scroll-fix-v1-1-58bca7ae487f@protonmail.com/ 
>
> The symptoms seem similar at least, and if so the approach to fixing
> it in that case is to simply treat Bolt devices like previous DJ
> devices, rather than having special treatment for Bolt.
> Can you who have Bolt mice maybe test that patch too to see if it
> solves the same issue?
> Regards
> Erik
>
> On 9/4/26 09:44, Alexey Zagorodnikov wrote:
>> Hi, thanks for your patch. I've tested it with my MX Master 4 + Bolt.
>>
>> I'm not seeing a regression from mainline hid++ enabling, as in 
>> Solaar high-res scrolling was disabled in my config.
>>
>> But with hid++ for Bolt enabled by mainline and your patch fixing 
>> high-res scroll init, I finally got smooth high-res scrolling on MX 
>> Master 4 via a Bolt connection.
>>
>> Tested-by: Alexey Zagorodnikov <xglooom@gmail.com>
>>
>> On 9/4/26 08:48, Rafael Passos wrote:
>>> The new added support for Logitech HID++ caused this mouse to
>>> scroll too far for each tic when using the USB dongle (Bolt).
>>> Previously, this mouse was handled as hid_generic over the Bold
>>> connection, and logitech-hidpp when over Bluetooth.
>>>
>>> Cause:
>>> Over the Bolt receiver, the mouse reports  are forwarded over the 
>>> generic
>>> interface 1, instead of the new HID++ child device. The generic hid 
>>> does
>>> now know about the hi-res scrolling used by the HID++.
>>> In my tests, I discovered this mouse has a multiplier factor of 15. 
>>> This
>>> multiplier is only handled by the logitech-hidpp driver. When piped to
>>> hid_generic, the "hi-res" value was piped to a "low-res" field, making
>>> the scroll unbearable.
>>>
>>> The fix routes the wheel using the HID++, so the ticks are scaled by 
>>> the
>>> multiplier and correctly reported as a hi-res event.
>>>
>>> I also had to move the hidpp_is_bolt_child function up, to use it in 
>>> the
>>> hidpp_connect_event function, where the gate for
>>> hidpp_initialize_hires_scroll function lives.
>>>
>>> Tested with:
>>> - Logitech MX Master 3S (mouse) via Bolt receiver and Bluetooth.
>>>
>>> Fixes: 022eb347ff3a ("HID: logitech: add Bolt receiver support for 
>>> Logitech HID++ devices")
>>> Signed-off-by: Rafael Passos <rafael@rcpassos.me>
>>> ---
>>>
>>> Hi,
>>> I decided to send this patch as soon as I made it work, to try to make
>>> it into this fix cycle.
>>>
>>> I do not have other devices to test this with.
>>> It would *be great* to have other users testing this.
>>>
>>> Lastly, I decided to make all the changes in a single patch.
>>> But I can break it up if asked.
>>>
>>> Thanks,
>>> Rafael
>>>
>>>
>>>   drivers/hid/hid-logitech-hidpp.c | 47 
>>> ++++++++++++++++++++++----------
>>>   1 file changed, 32 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/hid/hid-logitech-hidpp.c 
>>> b/drivers/hid/hid-logitech-hidpp.c
>>> index 1504de32b1c84..960543bfd5ea1 100644
>>> --- a/drivers/hid/hid-logitech-hidpp.c
>>> +++ b/drivers/hid/hid-logitech-hidpp.c
>>> @@ -3900,6 +3900,19 @@ static int 
>>> hidpp10_consumer_keys_raw_event(struct hidpp_device *hidpp,
>>>       return 1;
>>>   }
>>>   +static bool hidpp_is_bolt_child(struct hid_device *hdev)
>>> +{
>>> +    struct device *parent = hdev->dev.parent;
>>> +    struct hid_device *receiver_hdev;
>>> +
>>> +    if (!parent)
>>> +        return false;
>>> +
>>> +    receiver_hdev = to_hid_device(parent);
>>> +    return receiver_hdev->vendor == USB_VENDOR_ID_LOGITECH &&
>>> +           receiver_hdev->product == 
>>> USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER;
>>> +}
>>> +
>>>   /* 
>>> -------------------------------------------------------------------------- 
>>> */
>>>   /* High-resolution scroll 
>>> wheels                                              */
>>>   /* 
>>> -------------------------------------------------------------------------- 
>>> */
>>> @@ -3910,7 +3923,9 @@ static int hi_res_scroll_enable(struct 
>>> hidpp_device *hidpp)
>>>       u8 multiplier = 1;
>>>         if (hidpp->capabilities & 
>>> HIDPP_CAPABILITY_HIDPP20_HI_RES_WHEEL) {
>>> -        ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, false);
>>> +        bool use_hidpp = hidpp_is_bolt_child(hidpp->hid_dev);
>>> +
>>> +        ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, use_hidpp);
>>>           if (ret == 0)
>>>               ret = hidpp_hrw_get_wheel_capability(hidpp, &multiplier);
>>>       } else if (hidpp->capabilities & 
>>> HIDPP_CAPABILITY_HIDPP20_HI_RES_SCROLL) {
>>> @@ -3998,6 +4013,19 @@ static int 
>>> hidpp20_hires_wheel_raw_event(struct hidpp_device *hidpp,
>>>           return 1;
>>>       }
>>>   +    /* wheel movement event: 16-bit signed delta in HID++ ticks */
>>> +    if ((data[3] & 0xf0) == 0x00 && size >= 7 && hidpp->input &&
>>> +        hidpp->vertical_wheel_counter.wheel_multiplier) {
>>> +        s16 delta = get_unaligned_be16(&data[5]);
>>> +
>>> +        if (delta) {
>>> + hidpp_scroll_counter_handle_scroll(hidpp->input,
>>> +                &hidpp->vertical_wheel_counter, delta);
>>> +            input_sync(hidpp->input);
>>> +        }
>>> +        return 1;
>>> +    }
>>> +
>>>       return 0;
>>>   }
>>>   @@ -4405,19 +4433,6 @@ static int hidpp_initialize_battery(struct 
>>> hidpp_device *hidpp)
>>>       return ret;
>>>   }
>>>   -static bool hidpp_is_bolt_child(struct hid_device *hdev)
>>> -{
>>> -    struct device *parent = hdev->dev.parent;
>>> -    struct hid_device *receiver_hdev;
>>> -
>>> -    if (!parent)
>>> -        return false;
>>> -
>>> -    receiver_hdev = to_hid_device(parent);
>>> -    return receiver_hdev->vendor == USB_VENDOR_ID_LOGITECH &&
>>> -           receiver_hdev->product == 
>>> USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER;
>>> -}
>>> -
>>>   static int hidpp_bolt_init(struct hidpp_device *hidpp)
>>>   {
>>>       struct hid_device *hdev = hidpp->hid_dev;
>>> @@ -4579,7 +4594,9 @@ static void hidpp_connect_event(struct 
>>> work_struct *work)
>>>       }
>>>         hidpp_initialize_battery(hidpp);
>>> -    if (!hid_is_usb(hidpp->hid_dev))
>>> +
>>> +    if (!hid_is_usb(hidpp->hid_dev) ||
>>> +        hidpp_is_bolt_child(hidpp->hid_dev))
>>>           hidpp_initialize_hires_scroll(hidpp);
>>>         /* forward current battery state */

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[Alexey Zagorodnikov]

 >we just revert the inclusion of the receiver in the dj driver.

Please no, we finally able to achieve hi-res scrolling, like it was on 
unifying and bluetooth connections.

Maybe place it behind some quirk flags if causes more trouble on other 
setup.

On 9/4/26 22:03, Benjamin Tissoires wrote:
> On Sep 04 2026, Erik Håkansson wrote:
>> Hi!
>> Is this the same issue as in
>> https://lore.kernel.org/linux-input/20260901-bolt-scroll-fix-v1-1-58bca7ae487f@protonmail.com/
>> The symptoms seem similar at least, and if so the approach to fixing
>> it in that case is to simply treat Bolt devices like previous DJ
>> devices, rather than having special treatment for Bolt.
>> Can you who have Bolt mice maybe test that patch too to see if it
>> solves the same issue?
> FWIW, my initial decision a few years back when Bolt was introduced was
> to not include it in the kernel, because there are too many things it's
> missing, the most problematic one being that we don't know which device
> sends which event.
>
> So basically, there is a chance that the driver sets high-resolution
> scrolling on a bolt device, when 2 mice are connected, and one is
> capable of it and the other is not. This is unlikely to happen, but is
> hard to solve in the kernel.
>
> So I'm happy to wait for testing and patches, but I would also like a
> conclusion where bolt doesn't belong to the kernel, and we just revert
> the inclusion of the receiver in the dj driver.
>
> Cheers,
> Benjamin

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[Rafael Passos]

Hi Erik,

On Fri Sep 4, 2026 at 3:17 PM -03, Alexey Zagorodnikov wrote:
> I've tried your patch, and MX Master 4 + Bolt goes crazy, it moves on 
> vertical with very high speed, and very very slow on horizontal.
>
> On 9/4/26 21:34, Erik Håkansson wrote:
>> Hi!
>> Is this the same issue as in
>> https://lore.kernel.org/linux-input/20260901-bolt-scroll-fix-v1-1-58bca7ae487f@protonmail.com/ 

I tested this patch and had the same behavior as Alexey in
my MX Master 3S. It affects the mouse movement, not the wheel.

If I coud ask, could you test my patch in your system too?

Thanks,
Rafael Passos

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[erikhakan]

Hi again!
This patch works fine on my MX Keys Business. No regressions noted.

It seems then that the earlier patch by Grégoire cause similar regressions to what
Kateřina Medvědová reported when all three interfaces were treated as DJ interfaces
in https://lore.kernel.org/linux-input/345f7347-30a8-4568-a7a6-c70f54a52a8d@mcld.eu/
where she reported e.g. that the mouse became very sensitive as well as some
other issues.

I.e. it seems like this patch is the better approach.

Thanks
Erik

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[Oleksandr Natalenko]

[-- Attachment #1: Type: text/plain, Size: 5147 bytes --]

Hello.

On pátek 4. září 2026 5:48:29, středoevropský letní čas Rafael Passos wrote:
> The new added support for Logitech HID++ caused this mouse to
> scroll too far for each tic when using the USB dongle (Bolt).
> Previously, this mouse was handled as hid_generic over the Bold
> connection, and logitech-hidpp when over Bluetooth.
> 
> Cause:
> Over the Bolt receiver, the mouse reports  are forwarded over the generic
> interface 1, instead of the new HID++ child device. The generic hid does
> now know about the hi-res scrolling used by the HID++.
> In my tests, I discovered this mouse has a multiplier factor of 15. This
> multiplier is only handled by the logitech-hidpp driver. When piped to
> hid_generic, the "hi-res" value was piped to a "low-res" field, making
> the scroll unbearable.
> 
> The fix routes the wheel using the HID++, so the ticks are scaled by the
> multiplier and correctly reported as a hi-res event.
> 
> I also had to move the hidpp_is_bolt_child function up, to use it in the
> hidpp_connect_event function, where the gate for
> hidpp_initialize_hires_scroll function lives.
> 
> Tested with:
> - Logitech MX Master 3S (mouse) via Bolt receiver and Bluetooth.
> 
> Fixes: 022eb347ff3a ("HID: logitech: add Bolt receiver support for Logitech HID++ devices")
> Signed-off-by: Rafael Passos <rafael@rcpassos.me>

For v7.3-rc3 + Bolt receiver + MX Master 4 mouse:

Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>

Thank you.

> ---
> 
> Hi,
> I decided to send this patch as soon as I made it work, to try to make
> it into this fix cycle.
> 
> I do not have other devices to test this with.
> It would *be great* to have other users testing this.
> 
> Lastly, I decided to make all the changes in a single patch. 
> But I can break it up if asked.
> 
> Thanks,
> Rafael
> 
> 
>  drivers/hid/hid-logitech-hidpp.c | 47 ++++++++++++++++++++++----------
>  1 file changed, 32 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> index 1504de32b1c84..960543bfd5ea1 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -3900,6 +3900,19 @@ static int hidpp10_consumer_keys_raw_event(struct hidpp_device *hidpp,
>  	return 1;
>  }
>  
> +static bool hidpp_is_bolt_child(struct hid_device *hdev)
> +{
> +	struct device *parent = hdev->dev.parent;
> +	struct hid_device *receiver_hdev;
> +
> +	if (!parent)
> +		return false;
> +
> +	receiver_hdev = to_hid_device(parent);
> +	return receiver_hdev->vendor == USB_VENDOR_ID_LOGITECH &&
> +	       receiver_hdev->product == USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER;
> +}
> +
>  /* -------------------------------------------------------------------------- */
>  /* High-resolution scroll wheels                                              */
>  /* -------------------------------------------------------------------------- */
> @@ -3910,7 +3923,9 @@ static int hi_res_scroll_enable(struct hidpp_device *hidpp)
>  	u8 multiplier = 1;
>  
>  	if (hidpp->capabilities & HIDPP_CAPABILITY_HIDPP20_HI_RES_WHEEL) {
> -		ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, false);
> +		bool use_hidpp = hidpp_is_bolt_child(hidpp->hid_dev);
> +
> +		ret = hidpp_hrw_set_wheel_mode(hidpp, false, true, use_hidpp);
>  		if (ret == 0)
>  			ret = hidpp_hrw_get_wheel_capability(hidpp, &multiplier);
>  	} else if (hidpp->capabilities & HIDPP_CAPABILITY_HIDPP20_HI_RES_SCROLL) {
> @@ -3998,6 +4013,19 @@ static int hidpp20_hires_wheel_raw_event(struct hidpp_device *hidpp,
>  		return 1;
>  	}
>  
> +	/* wheel movement event: 16-bit signed delta in HID++ ticks */
> +	if ((data[3] & 0xf0) == 0x00 && size >= 7 && hidpp->input &&
> +	    hidpp->vertical_wheel_counter.wheel_multiplier) {
> +		s16 delta = get_unaligned_be16(&data[5]);
> +
> +		if (delta) {
> +			hidpp_scroll_counter_handle_scroll(hidpp->input,
> +				&hidpp->vertical_wheel_counter, delta);
> +			input_sync(hidpp->input);
> +		}
> +		return 1;
> +	}
> +
>  	return 0;
>  }
>  
> @@ -4405,19 +4433,6 @@ static int hidpp_initialize_battery(struct hidpp_device *hidpp)
>  	return ret;
>  }
>  
> -static bool hidpp_is_bolt_child(struct hid_device *hdev)
> -{
> -	struct device *parent = hdev->dev.parent;
> -	struct hid_device *receiver_hdev;
> -
> -	if (!parent)
> -		return false;
> -
> -	receiver_hdev = to_hid_device(parent);
> -	return receiver_hdev->vendor == USB_VENDOR_ID_LOGITECH &&
> -	       receiver_hdev->product == USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER;
> -}
> -
>  static int hidpp_bolt_init(struct hidpp_device *hidpp)
>  {
>  	struct hid_device *hdev = hidpp->hid_dev;
> @@ -4579,7 +4594,9 @@ static void hidpp_connect_event(struct work_struct *work)
>  	}
>  
>  	hidpp_initialize_battery(hidpp);
> -	if (!hid_is_usb(hidpp->hid_dev))
> +
> +	if (!hid_is_usb(hidpp->hid_dev) ||
> +	    hidpp_is_bolt_child(hidpp->hid_dev))
>  		hidpp_initialize_hires_scroll(hidpp);
>  
>  	/* forward current battery state */
> 


-- 
Oleksandr Natalenko, MSE

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[Oleksandr Natalenko]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

On pondělí 14. září 2026 12:31:01, středoevropský letní čas Oleksandr Natalenko wrote:
> 
> For v7.3-rc3 + Bolt receiver + MX Master 4 mouse:
> 
> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>

OK, no, something is not right: the mouse behaved fine after a fresh boot with the patch applied, but once I switched it to another device and then back, the scroll started to be crazy again.

-- 
Oleksandr Natalenko, MSE

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[erikhakan]

Hi all!

I believe I have an explanation (and a solution) for why everyone's results differ.

As noted in https://lore.kernel.org/linux-input/20260920094508.39682-1-roman.stingler@gmail.com/
there is a conflict between the driver and Solaar in that user settings are not
respected by the driver.

So while investigating that, I found some further issues with regards to how Rafael's
proposed fix would deal with the case where Solaar disables high resolution scroll.

Locally, I have a fix that expands on Rafael's patch and but also handles low-
resolution scroll events. And it also respects on-device user settings so that 
settings set in Solaar will remain.

I believe that the reason for inconsistent behaviour for some testers is simply
that there are unhandled states in combinations of settings in the current code,
which my fix aims to solve.

So, Rafael, is it alright if I post a new series with your fix as Patch 1 and then
my addition as Patch 2?
I'd love to have it properly tested since I don't have a Bolt mouse.

Regards,
Erik

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[Rafael Passos]

Hi, 

On September 22, 2026 16:28:47 GMT+01:00, erikhakan@gmail.com wrote:
>Hi all!
>
>I believe I have an explanation (and a solution) for why everyone's results differ.
>
>As noted in https://lore.kernel.org/linux-input/20260920094508.39682-1-roman.stingler@gmail.com/
>there is a conflict between the driver and Solaar in that user settings are not
>respected by the driver.
>
>So while investigating that, I found some further issues with regards to how Rafael's
>proposed fix would deal with the case where Solaar disables high resolution scroll.
>
>Locally, I have a fix that expands on Rafael's patch and but also handles low-
>resolution scroll events. And it also respects on-device user settings so that settings set in Solaar will remain.
>
>I believe that the reason for inconsistent behaviour for some testers is simply
>that there are unhandled states in combinations of settings in the current code,
>which my fix aims to solve.
>
>So, Rafael, is it alright if I post a new series with your fix as Patch 1 and then
>my addition as Patch 2?
>I'd love to have it properly tested since I don't have a Bolt mouse.

Please go ahead Erik.
I'll be back home this week, and will be able to test on my hardware.

Thanks, 
Rafael Passos,
Software Engineer
São Paulo, Brasil

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[Rafael Passos]

Hi Oleksandr, 

On September 14, 2026 11:51:48 GMT+01:00, Oleksandr Natalenko <oleksandr@natalenko.name> wrote:
>On pondělí 14. září 2026 12:31:01, středoevropský letní čas Oleksandr Natalenko wrote:
>> 
>> For v7.3-rc3 + Bolt receiver + MX Master 4 mouse:
>> 
>> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
>
>OK, no, something is not right: the mouse behaved fine after a fresh boot with the patch applied, but once I switched it to another device and then back, the scroll started to be crazy again.
>

Could you send the detailed steps of your testing procedure?
I'd like to try reproducing it when I'm back home. 

Thanks, 
Rafael Passos,
Software Engineer
São Paulo, Brasil

Re: [PATCH] HID: logitech-hidpp: fix hi-res scroll for Bolt-connected MX Master

[Oleksandr Natalenko]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

Hello.

On úterý 22. září 2026 18:32:16, středoevropský letní čas Rafael Passos wrote:
> Hi Oleksandr, 
> 
> On September 14, 2026 11:51:48 GMT+01:00, Oleksandr Natalenko <oleksandr@natalenko.name> wrote:
> >On pondělí 14. září 2026 12:31:01, středoevropský letní čas Oleksandr Natalenko wrote:
> >> 
> >> For v7.3-rc3 + Bolt receiver + MX Master 4 mouse:
> >> 
> >> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
> >
> >OK, no, something is not right: the mouse behaved fine after a fresh boot with the patch applied, but once I switched it to another device and then back, the scroll started to be crazy again.
> >
> 
> Could you send the detailed steps of your testing procedure?
> I'd like to try reproducing it when I'm back home. 

Nothing special: I've got two Bolt receivers connected to two different machines, each receiver is paired with MX Keys S and MX Master 4. I switch both the keyboard and the mouse between two machines with a keyboard shortcut that triggers Solaar rule to change the host.

I'm going to try the series Erik sent today.

-- 
Oleksandr Natalenko, MSE

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]