With kernel 5.9-rc1 my Logitech t650 is no longer detected correctly. Fortunately I've been following the pre-rc1 git tree and bisect was short and easy. d31327922 HID: usbhid: do not sleep when opening device Confirmed with a revert on top of rc1. Without the revert it fails to detect. With the revert it works. Related dmesg lines when it's broken (the dj device and k350 keyboard also connected to it work): logitech-hidpp-device 0003:046D:4101.0005: item fetching failed at offset 0/0 logitech-hidpp-device 0003:046D:4101.0005: hidpp_probe:parse failed logitech-hidpp-device: probe of 0003:046D:4101.0005 failed with error -22 With that commit reverted and the touchpad working, I get: logitech-hidpp-device 0003:046D:4101.0006: hidraw3: USB HID v1.11 Keyboard [Logitech T650] on usb-0000:00:13.0-3/input2:3 [then later, when I actually touch the thing to activate it] logitech-hidpp-device 0003:046D:4101.0006: HID++ 2.0 device connected. input: Logitech Rechargeable Touchpad T650 as /devices/pci0000:00/0000:00:13.0/usb5/5-3/5-3:1.2/0003:046D:C52B.0004/0003:046D:4101.0006/inp\ ut/input14 (This may be a dupe of bug #208923, but I don't know that yet, since that bug has so little detail filled in.)
I can confirm this with a Logitech Ergo MX trackball and unified receiver. With kernel 5.9-rc1 I get: [ 144.210951] logitech-djreceiver 0003:046D:C52B.0003: device of type eQUAD step 4 DJ (0x04) connected on slot 4 [ 144.211174] hid-generic 0003:046D:406F.0005: item fetching failed at offset 0/0 [ 144.211189] hid-generic: probe of 0003:046D:406F.0005 failed with error -22 [ 144.217224] logitech-hidpp-device 0003:046D:406F.0005: item fetching failed at offset 0/0 [ 144.217236] logitech-hidpp-device 0003:046D:406F.0005: hidpp_probe:parse failed [ 144.217243] logitech-hidpp-device: probe of 0003:046D:406F.0005 failed with error -22 Reverting "d31327922 HID: usbhid: do not sleep when opening device" makes the device work again: [ 157.133316] logitech-djreceiver 0003:046D:C52B.0009: hiddev96,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:04:00.4-1/input2 [ 157.252639] input: Logitech MX Ergo as /devices/pci0000:00/0000:00:08.1/0000:04:00.4/usb3/3-1/3-1:1.2/0003:046D:C52B.0009/0003:046D:406F.000A/input/input35 [ 157.252915] logitech-hidpp-device 0003:046D:406F.000A: input,hidraw2: USB HID v1.11 Keyboard [Logitech MX Ergo] on usb-0000:04:00.4-1/input2:3 [ 157.262429] input: Logitech MX Ergo as /devices/pci0000:00/0000:00:08.1/0000:04:00.4/usb3/3-1/3-1:1.2/0003:046D:C52B.0009/0003:046D:406F.000B/input/input36 [ 157.262702] logitech-hidpp-device 0003:046D:406F.000B: input,hidraw3: USB HID v1.11 Keyboard [Logitech MX Ergo] on usb-0000:04:00.4-1/input2:4 [ 159.899985] logitech-hidpp-device 0003:046D:406F.000B: HID++ 4.5 device connected.
(In reply to Johannes Hirte from comment #1) > I can confirm this with a Logitech Ergo MX trackball and unified receiver. > Reverting "d31327922 HID: usbhid: do not sleep when opening device" makes > the device work again: Thanks for the confirmation. You have a Logitech trackball with the unified wireless receiver; I have a Logitech trackpad with the unified receiver; and bug #809923 says Logitech mouse m220, which googling (on the privacy respecting duckduckgo) suggests also uses a unified receiver or something looking like it, tho the revert-fix isn't confirmed on that one yet. Meanwhile, it's worth mentioning again that my Logitech k350 wireless keyboard, connected as well thru the same unified receiver connecting the trackpad, continues to work even while the trackpad fails. So it seems to affect Logitech unifying receiver connected pointing devices, but /not/ Logitech keyboards similarly connected. And it's bisected. Adjusting the title accordingly (and marking regression, which I missed with the original filing).
changing the line usbhid->input_start_time = ktime_add_ms(ktime_get_coarse(), 50); to become usbhid->input_start_time = ktime_add_ms(ktime_get_coarse(), 0); also results in working mouse input again. Is hid_start_in() being called recursively such that input_start_time gets incremented forever and the check conditions can never be successful?
FYI I mailed the maintainers and Jiri replies "I have revert already queued in hid.git#for-5.9/upstream-fixes."
(In reply to Eric Shattow from comment #4) > FYI I mailed the maintainers and Jiri replies "I have revert already queued > in hid.git#for-5.9/upstream-fixes." Looks like that's in now, as commit 5b0545dc1, merged in commit b9aa527ae on August 25, Tuesday. So for those doing the rcs only it should be in 5.9-rc3. Quoting the git log: Revert "HID: usbhid: do not sleep when opening device" This reverts commit d3132792285859253c466354fd8d54d1fe0ba786. This patch causes a regression with quite a few devices, as probing fails because of the race where the first IRQ is dropped on the floor (after hid_device_io_start() happens, but before the 50ms timeout passess), and report descriptor never gets parsed and populated. As this is just a boot time micro-optimization, let's revert the patch for 5.9 now, and fix this properly eventually for next merge window. Link: https://bugzilla.kernel.org/show_bug.cgi?id=208935 That's a link to this bug, of course. =:^) Also note the "revert ... now, and fix this properly ... for next merge window" bit. So be particularly on the lookout for 5.10-rcs as well, but I expect they'll be pre-commit testing against hardware that failed this time and won't fail on it for the second go-round in 5.10. I'll leave the bug open until rc3 is released with the revert, then will close the bug if no objections as it was introduced pre-rc1 this cycle and never hit full release.
Fixed in 5.9-rc3. =:^)