lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ