linux-kernel - Re: [GIT PULL] HID for 6.13

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: <2eh3ep6ft5kekc6u6hj3m5qflk5bypbfatpwo6oiptnpspaa6j@wqapte332xgy>
Date: Sat, 23 Nov 2024 20:05:38 +0100
From: Benjamin Tissoires <bentiss@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jiri Kosina <jikos@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] HID for 6.13

On Nov 23 2024, Linus Torvalds wrote:
> On Sat, 23 Nov 2024 at 08:42, Benjamin Tissoires <bentiss@...nel.org> wrote:
> >
> > IMO the suspect might be 526748b925185e95f1415900ee13c2469d4b64cc.
> 
> I'll try reverting it when I have more time (which is probably end of
> next week.. merge window).

No need to bother with this one then, because your receiver is the
0xc52b, which is the old (and well known) unifying receiver, when this
commit touches teh bolt receiver, which is 0xc548. So a revert would
have no impact.

> 
> > In addition to Jiri's requests, could you also post the dmesg after the
> > fresh (and broken) reboot, and after unplug/replug the dongle? We would
> > get more information on to which kernel modules are involved this way.
> 
> All I get for a unplug/replug is
> 
>   usb 5-4.2.2: USB disconnect, device number 10
>   usb 5-4.2.2: new full-speed USB device number 11 using xhci_hcd
>   usb 5-4.2.2: New USB device found, idVendor=046d, idProduct=c52b,
> bcdDevice=24.11
>   usb 5-4.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
>   usb 5-4.2.2: Product: USB Receiver
>   usb 5-4.2.2: Manufacturer: Logitech
> 
> and then
> 
>   logitech-djreceiver 0003:046D:C52B.0019: hiddev100,hidraw9: USB HID
> v1.11 Device [Logitech USB Receiver] on usb-0000:46:00.1-4.2.2/input2
>   input: Logitech MX Anywhere 3 as
> /devices/pci0000:40/0000:40:01.1/0000:41:00.0/0000:42:08.0/0000:46:00.1/usb5/5-4/5-4.2/5-4.2.2/5-4.2.2:1.2/0003:046D:C52B.0019/0003:046D:4090.001A/input/input36
>   logitech-hidpp-device 0003:046D:4090.001A: input,hidraw10: USB HID
> v1.11 Mouse [Logitech MX Anywhere 3] on
> usb-0000:46:00.1-4.2.2/input2:1
>   logitech-hidpp-device 0003:046D:4090.001A: HID++ 4.5 device connected.
> 
> but doing some grepping, at bootup time I also see a line line
> 
>   hid-generic 0003:046D:4090.000E: input,hidraw10: USB HID v1.11 Mouse
> [Logitech Wireless Device PID:4090] on usb-0000:46:00.1-4.2.2/input2:1

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).

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 :)

> 
> which does not happen at replug. There's a few other boot-time
> messages that seem to be about module init stuff too, ie
> 
>   input: Logitech USB Receiver as /devices/...
>   input: Logitech USB Receiver Mouse as /devices/...
>   input: Logitech USB Receiver Consumer Control as /devices/...
>   input: Logitech USB Receiver System Control as /devices/...
>   input: Logitech Wireless Device PID:4090 Mouse as /devices/...
> 
> and that only happens once and then never again. Some module loading
> thing? I have
> 
>   CONFIG_HID=y
>   CONFIG_HID_BATTERY_STRENGTH=y
>   CONFIG_HIDRAW=y
>   CONFIG_HID_GENERIC=y
> 
> but then the Logitech part is modules:
> 
>   CONFIG_HID_LOGITECH=m
>   CONFIG_HID_LOGITECH_DJ=m
>   CONFIG_HID_LOGITECH_HIDPP=m
> 
> which I think is all normal (ie I have my own local config, but that
> part matches the default distro kernel config)
> 

Yep all normal.

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.

Sorry for the trouble.

Cheers,
Benjamin