[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wg=BKLd9FQiqxh8Sirvu96qkDojY+P1Ukrz2EdBXTN5dA@mail.gmail.com>
Date: Sat, 23 Nov 2024 11:58:57 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Benjamin Tissoires <bentiss@...nel.org>
Cc: Jiri Kosina <jikos@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] HID for 6.13
On Sat, 23 Nov 2024 at 11:05, Benjamin Tissoires <bentiss@...nel.org> wrote:
>
> What would be interesting to know is if the line
>
> logitech-hidpp-device 0003:046D:4090.001A: HID++ 4.5 device connected.
>
> ever happens on a fresh reboot (before the unplus/replug).
It does happen, at boot too, although it happens a bit later:
[ 4.905196] input: Logitech USB Receiver Mouse as /devices/...
[ 4.905276] input: Logitech USB Receiver Consumer Control as /devices/...
[ 4.956062] input: Logitech USB Receiver System Control as /devices/...
...
[ 5.265096] input: Logitech MX Anywhere 3 Mouse as /devices/..
...
[ 24.330052] logitech-hidpp-device 0003:046D:4090.000E: HID++ 4.5
device connected.
while at unplug/replug it happens immediately.
The bootup delay isn't because this is a horribly slow machine, it's
probably me typing in the encrypted disk password etc, so there's at
least 10s due to that, but there's probably other boot time stuff
going on too.
In the systemd logs, that HID++ comes within a second after
systemd[1]: Reached target graphical.target - Graphical Interface.
so I suspect it has something to do with X (or Wayland, I guess)
opening the mouse device?
> Anyway, this confirms my theory that the mouse wheel is set to high
> resolution mode by the previous boot and that the next one (using
> hid-generic) is actually not handling properly: I bet that if you scroll
> long enough in the same direction (can't remember exactly the actual
> multiplier) you'll eventually get one scroll event. Not convenient I
> agree :)
Yeah, that doesn't sound like a great user experience, but might match
what I see. I just didn't scroll enough.
> The problem seems to be that hid-generic is not letting
> hid-logitech-hidpp taking over (or that the driver is not properly
> loaded at boot time once the disk is ready). I have some suspicions on
> some core changes I made in hid-core for handling a new quirk, but I
> should be able to reproduce next week with all of that information.
Thanks,
Linus
Powered by blists - more mailing lists