Bug 216997

Summary:	Handle hi-res scrolling through HID++ for G903
Product:	Drivers	Reporter:	Bastien Nocera (bugzilla)
Component:	Input Devices	Assignee:	drivers_input-devices
Status:	NEW ---
Severity:	normal	CC:	carnil, davidroth9, decedion, gudvinr+kernelorg, klausman, mariusz.g.mazur, val.zapod.vz
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	6.2	Subsystem:
Regression:	No	Bisected commit-id:
Bug Depends on:
Bug Blocks:	217909

Description Bastien Nocera 2023-02-03 13:11:55 UTC

"HID: logitech: Disable hi-res scrolling on USB" says:
"
On some Logitech mice, such as the G903, and possibly the G403, the HID
events are generated on a different interface to the HID++ one.

If we enable hi-res through the HID++ interface, the HID interface
wouldn't know anything about it, and handle the events as if they were
regular scroll events, making the mouse unusable.

Disable hi-res scrolling on those devices until we implement scroll
events through HID++.
"

This bug is about tracking re-enabling hi-res scrolling support for G903 mice.

Comment 1 David Roth 2023-03-14 23:23:19 UTC

Hey there thanks for the patch in the other report, it at least restored sane functionality in my case. 

I'm "working" as a support staff/forum moderator on the Arch Linux boards and there where a bunch of people that mentioned to still be having issues/the high res enablement in general not really leading to the results they want/generally unexpected scrolling behaviour.

https://bbs.archlinux.org/viewtopic.php?id=282852

So I'm asking how much of an issue it would be to consider my original proposal in https://bugzilla.kernel.org/attachment.cgi?id=303559 of providing a module parameter to control whether high res is enabled in the first place or not.

Since this is somewhat related to the original report, I surmised to add this here, sorry if this should rather be a report on it's own.

Comment 2 Bastien Nocera 2023-03-15 09:29:51 UTC

(In reply to David Roth from comment #1)
> Hey there thanks for the patch in the other report, it at least restored
> sane functionality in my case. 
> 
> I'm "working" as a support staff/forum moderator on the Arch Linux boards
> and there where a bunch of people that mentioned to still be having
> issues/the high res enablement in general not really leading to the results
> they want/generally unexpected scrolling behaviour.
> 
> https://bbs.archlinux.org/viewtopic.php?id=282852
> 
> So I'm asking how much of an issue it would be to consider my original
> proposal in https://bugzilla.kernel.org/attachment.cgi?id=303559 of
> providing a module parameter to control whether high res is enabled in the
> first place or not.
> 
> Since this is somewhat related to the original report, I surmised to add
> this here, sorry if this should rather be a report on it's own.

I would be against adding any module parameter to work-around driver bugs. If there are still problems with hi-res scrolling on particular Logitech devices with an updated kernel, you should consider reporting those to the linux-input list, or filing a bug in this bugzilla. The bug you mentioned has details on what information to provide.

Comment 3 Maxim 2023-05-05 17:22:39 UTC

This also happens with MX Master 3 (running through USB Unifying receiver)

Comment 4 val.zapod.vz 2025-05-02 19:51:49 UTC

This is still completely broken. Please revert you broken kernel patches that "disable" high resolution wheel scroll, Mozilla on wayland and wayland itself already implemented HID++ 4.2 wheel just 4 months ago. https://bugzilla.mozilla.org/show_bug.cgi?id=1836886

There are horrible bugs still that remain on all GTK4 apps: https://gitlab.gnome.org/GNOME/gtk/-/issues/6316 

telegram desktop is still broken, e.g.: https://github.com/search?q=repo%3Atelegramdesktop%2Ftdesktop+logitech&type=issues

This needs to be fixed in apps, not in the kernel, Windows Vista was 20 years ago... https://gitlab.gnome.org/GNOME/gtk/-/issues/6316