Hi, this is your Linux kernel regression tracker speaking.
I noticed a regression report in bugzilla.kernel.org. As many (most?)
kernel developer don't keep an eye on it, I decided to forward it by
mail. Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216885 :
> David Roth 2023-01-04 20:37:22 UTC
>
> Created attachment 303526 [details]
> Libinput record with G903 attached directly to USB
>
> Since
> https://lore.kernel.org/linux-input/[email protected]/T/#u
> my Logitech G903 has gained hi res support. While normally a good
> thing, it seems that in this case it leads to generating one normal
> REL_WHEEL with each REL_WHEEL_HI_RES event instead of just a couple
> of REL_WHEEL_HI_RES, followed by the standard REL_WHEEL once a
> notch/tick is reached. This leads to overly sensitive scrolling and
> makes the wheel basically useless.
>
> Interestingly this only happens when the mouse is connected directly via
> cable (PID:0xC091) and not via the Lightspeed wireless dongle
> (PID:0x4087) where it will lead to correctly applying the times 8
> multiplier and the relevant set of HI_RES and REL_WHEEL event once a
> notch is reached.
>
> I originally thought about patching the module/adding a param to simple
> disable high res support in general, assuming this might be something
> people might want to configure, but seeing that this can be "fixed" that
> way I decided to hold off on the thought.
>
> However it seems like we'd need to trade one set of quirks for another,
> so not sure what the correct approach might be.
>
> I'll attach some libinput debug logs when the issue happens.
See the ticket for more details.
BTW, let me use this mail to also add the report to the list of tracked
regressions to ensure it's doesn't fall through the cracks:
#regzbot introduced: 908d325e1665
https://bugzilla.kernel.org/show_bug.cgi?id=216885
#regzbot title: hid: overly sensitive scrolling with Logitech G903 that
makes the wheel basically useless
#regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
[ccing a few people that CCed to the bug]
Hi, this is your Linux kernel regression tracker.
On 05.01.23 09:12, Thorsten Leemhuis wrote:
> [...] Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216885 :
>
>> David Roth 2023-01-04 20:37:22 UTC
>>
>> Created attachment 303526 [details]
>> Libinput record with G903 attached directly to USB
>>
>> Since
>> https://lore.kernel.org/linux-input/[email protected]/T/#u
>> my Logitech G903 has gained hi res support. While normally a good
>> thing, it seems that in this case it leads to generating one normal
>> REL_WHEEL with each REL_WHEEL_HI_RES event instead of just a couple
>> of REL_WHEEL_HI_RES, followed by the standard REL_WHEEL once a
>> notch/tick is reached. This leads to overly sensitive scrolling and
>> makes the wheel basically useless.
Bastien, Benjamin, Jiri, that problem was reported 25 days ago now and
there is still no fix in sight afaics (please correct me if I'm wrong)
-- and based on the reports I've seen it seem quite a few people are
hitting it. Hence please allow me to ask:
Wouldn't it be best to revert that change for now (both in mainline and
stable of course) and then reapply it once a fix for this problem is
available? Or
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
>> Interestingly this only happens when the mouse is connected directly via
>> cable (PID:0xC091) and not via the Lightspeed wireless dongle
>> (PID:0x4087) where it will lead to correctly applying the times 8
>> multiplier and the relevant set of HI_RES and REL_WHEEL event once a
>> notch is reached.
>>
>> I originally thought about patching the module/adding a param to simple
>> disable high res support in general, assuming this might be something
>> people might want to configure, but seeing that this can be "fixed" that
>> way I decided to hold off on the thought.
>>
>> However it seems like we'd need to trade one set of quirks for another,
>> so not sure what the correct approach might be.
>>
>> I'll attach some libinput debug logs when the issue happens.
>
> See the ticket for more details.
>
> BTW, let me use this mail to also add the report to the list of tracked
> regressions to ensure it's doesn't fall through the cracks:
>
> #regzbot introduced: 908d325e1665
> https://bugzilla.kernel.org/show_bug.cgi?id=216885
> #regzbot title: hid: overly sensitive scrolling with Logitech G903 that
> makes the wheel basically useless
> #regzbot ignore-activity
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
Hi!
On Mon, 30 Jan 2023, Linux kernel regression tracking (Thorsten Leemhuis) wrote:
> [ccing a few people that CCed to the bug]
>
> Hi, this is your Linux kernel regression tracker.
>
> On 05.01.23 09:12, Thorsten Leemhuis wrote:
> > [...] Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216885 :
> >
> >> David Roth 2023-01-04 20:37:22 UTC
> >>
> >> Created attachment 303526 [details]
> >> Libinput record with G903 attached directly to USB
> >>
> >> Since
> >> https://lore.kernel.org/linux-input/[email protected]/T/#u
> >> my Logitech G903 has gained hi res support. While normally a good
> >> thing, it seems that in this case it leads to generating one normal
> >> REL_WHEEL with each REL_WHEEL_HI_RES event instead of just a couple
> >> of REL_WHEEL_HI_RES, followed by the standard REL_WHEEL once a
> >> notch/tick is reached. This leads to overly sensitive scrolling and
> >> makes the wheel basically useless.
>
> Bastien, Benjamin, Jiri, that problem was reported 25 days ago now and
> there is still no fix in sight afaics (please correct me if I'm wrong)
> -- and based on the reports I've seen it seem quite a few people are
> hitting it. Hence please allow me to ask:
>
> Wouldn't it be best to revert that change for now (both in mainline and
> stable of course) and then reapply it once a fix for this problem is
> available? Or
I think there was something cut off or that `Or` is leftovers.
As for no fix: correct, there is no fix yet, though the workaround of
blacklisting the module sortof works. _Not_ having hires support usually
doesn't break anything, as it's a relatively new feature/functionality,
and so many pieces of userland (GTK+, Qt etc) need to be explicitly
configured to use it, and fall back to lowres in a benign way. I would
have never noticed this if I didn't use a distro kernel on one machine
(my hand-built ones omit the module entirely).
That said, figuring out what is going on and what to do is not trivial,
since most people won't think "kernel" when they notice their mouse's
behavior has changed. My liberal reporting of bugs with Debian, libinput
and then the kernel (and linking them) was a deliberate attempt in
leaving breadcrumbs for people to find.
Best,
Tobias
On Mon, Jan 30, 2023 at 10:56 AM Linux kernel regression tracking
(Thorsten Leemhuis) <[email protected]> wrote:
>
> [ccing a few people that CCed to the bug]
>
> Hi, this is your Linux kernel regression tracker.
>
> On 05.01.23 09:12, Thorsten Leemhuis wrote:
> > [...] Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216885 :
> >
> >> David Roth 2023-01-04 20:37:22 UTC
> >>
> >> Created attachment 303526 [details]
> >> Libinput record with G903 attached directly to USB
> >>
> >> Since
> >> https://lore.kernel.org/linux-input/[email protected]/T/#u
> >> my Logitech G903 has gained hi res support. While normally a good
> >> thing, it seems that in this case it leads to generating one normal
> >> REL_WHEEL with each REL_WHEEL_HI_RES event instead of just a couple
> >> of REL_WHEEL_HI_RES, followed by the standard REL_WHEEL once a
> >> notch/tick is reached. This leads to overly sensitive scrolling and
> >> makes the wheel basically useless.
>
> Bastien, Benjamin, Jiri, that problem was reported 25 days ago now and
> there is still no fix in sight afaics (please correct me if I'm wrong)
> -- and based on the reports I've seen it seem quite a few people are
> hitting it. Hence please allow me to ask:
>
> Wouldn't it be best to revert that change for now (both in mainline and
> stable of course) and then reapply it once a fix for this problem is
> available? Or
Last I heard was that Bastien was actively trying to understand the
problem. I do have a G903 here but it is lacking the feature the
reporters have, and so I can not reproduce (there is likely a new
firmware/model around).
After a quick search on
https://support.logi.com/hc/en-us/search#q=G903&s=all it seems that
there are 2 G903: M-R0081 and M-R0068. I only own the 68 one which
explains why I can not reproduce it. :(
Cheers,
Benjamin
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> >> Interestingly this only happens when the mouse is connected directly via
> >> cable (PID:0xC091) and not via the Lightspeed wireless dongle
> >> (PID:0x4087) where it will lead to correctly applying the times 8
> >> multiplier and the relevant set of HI_RES and REL_WHEEL event once a
> >> notch is reached.
> >>
> >> I originally thought about patching the module/adding a param to simple
> >> disable high res support in general, assuming this might be something
> >> people might want to configure, but seeing that this can be "fixed" that
> >> way I decided to hold off on the thought.
> >>
> >> However it seems like we'd need to trade one set of quirks for another,
> >> so not sure what the correct approach might be.
> >>
> >> I'll attach some libinput debug logs when the issue happens.
> >
> > See the ticket for more details.
> >
> > BTW, let me use this mail to also add the report to the list of tracked
> > regressions to ensure it's doesn't fall through the cracks:
> >
> > #regzbot introduced: 908d325e1665
> > https://bugzilla.kernel.org/show_bug.cgi?id=216885
> > #regzbot title: hid: overly sensitive scrolling with Logitech G903 that
> > makes the wheel basically useless
> > #regzbot ignore-activity
> >
> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > --
> > Everything you wanna know about Linux kernel regression tracking:
> > https://linux-regtracking.leemhuis.info/about/#tldr
> > If I did something stupid, please tell me, as explained on that page.
>
Hi!
On Mon, 30 Jan 2023, Benjamin Tissoires wrote:
> On Mon, Jan 30, 2023 at 10:56 AM Linux kernel regression tracking
> (Thorsten Leemhuis) <[email protected]> wrote:
> >
> > [ccing a few people that CCed to the bug]
> >
> > Hi, this is your Linux kernel regression tracker.
> >
> > On 05.01.23 09:12, Thorsten Leemhuis wrote:
> > > [...] Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216885 :
> > >
> > >> David Roth 2023-01-04 20:37:22 UTC
> > >>
> > >> Created attachment 303526 [details]
> > >> Libinput record with G903 attached directly to USB
> > >>
> > >> Since
> > >> https://lore.kernel.org/linux-input/[email protected]/T/#u
> > >> my Logitech G903 has gained hi res support. While normally a good
> > >> thing, it seems that in this case it leads to generating one normal
> > >> REL_WHEEL with each REL_WHEEL_HI_RES event instead of just a couple
> > >> of REL_WHEEL_HI_RES, followed by the standard REL_WHEEL once a
> > >> notch/tick is reached. This leads to overly sensitive scrolling and
> > >> makes the wheel basically useless.
> >
> > Bastien, Benjamin, Jiri, that problem was reported 25 days ago now and
> > there is still no fix in sight afaics (please correct me if I'm wrong)
> > -- and based on the reports I've seen it seem quite a few people are
> > hitting it. Hence please allow me to ask:
> >
> > Wouldn't it be best to revert that change for now (both in mainline and
> > stable of course) and then reapply it once a fix for this problem is
> > available? Or
>
> Last I heard was that Bastien was actively trying to understand the
> problem. I do have a G903 here but it is lacking the feature the
> reporters have, and so I can not reproduce (there is likely a new
> firmware/model around).
>
> After a quick search on
> https://support.logi.com/hc/en-us/search#q=G903&s=all it seems that
> there are 2 G903: M-R0081 and M-R0068. I only own the 68 one which
> explains why I can not reproduce it. :(
I have an affected mouse and am willing to try patches/fixes, but my
kernel coding fu is weak.
Best,
Tobias
On 30.01.23 11:44, Tobias Klausmann wrote:
> On Mon, 30 Jan 2023, Benjamin Tissoires wrote:
>
>> On Mon, Jan 30, 2023 at 10:56 AM Linux kernel regression tracking
>> (Thorsten Leemhuis) <[email protected]> wrote:
>>>
>>> [ccing a few people that CCed to the bug]
>>>
>>> Hi, this is your Linux kernel regression tracker.
>>>
>>> On 05.01.23 09:12, Thorsten Leemhuis wrote:
>>>> [...] Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216885 :
>>>>
>>>>> David Roth 2023-01-04 20:37:22 UTC
>>>>>
>>>>> Created attachment 303526 [details]
>>>>> Libinput record with G903 attached directly to USB
>>>>>
>>>>> Since
>>>>> https://lore.kernel.org/linux-input/[email protected]/T/#u
>>>>> my Logitech G903 has gained hi res support. While normally a good
>>>>> thing, it seems that in this case it leads to generating one normal
>>>>> REL_WHEEL with each REL_WHEEL_HI_RES event instead of just a couple
>>>>> of REL_WHEEL_HI_RES, followed by the standard REL_WHEEL once a
>>>>> notch/tick is reached. This leads to overly sensitive scrolling and
>>>>> makes the wheel basically useless.
>>>
>>> Bastien, Benjamin, Jiri, that problem was reported 25 days ago now and
>>> there is still no fix in sight afaics (please correct me if I'm wrong)
>>> -- and based on the reports I've seen it seem quite a few people are
>>> hitting it. Hence please allow me to ask:
>>>
>>> Wouldn't it be best to revert that change for now (both in mainline and
>>> stable of course) and then reapply it once a fix for this problem is
>>> available? Or
>>
>> Last I heard was that Bastien was actively trying to understand the
>> problem.
Yup, no complains there. Thx for your work on this, Bastien.
But that debugging has already taken some time and it seem more is
needed. And apparently it's more than just a single user or two that is
affected by this. That's why I think it would be better to revert this
temporarily[1], unless a fix suddenly comes into sight.
[1] as strongly suggested by
https://docs.kernel.org/process/handling-regressions.html , which states
that a regression like this should ideally be fixed within a few days
after the report; we are long past this...
>> I do have a G903 here but it is lacking the feature the
>> reporters have, and so I can not reproduce (there is likely a new
>> firmware/model around).
>>
>> After a quick search on
>> https://support.logi.com/hc/en-us/search#q=G903&s=all it seems that
>> there are 2 G903: M-R0081 and M-R0068. I only own the 68 one which
>> explains why I can not reproduce it. :(
>
> I have an affected mouse and am willing to try patches/fixes, but my
> kernel coding fu is weak.
Thx for your help, too.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.