|Summary:||Logitech Wireless Receiver 046d:c52f : mouse not working|
|Product:||Drivers||Reporter:||Allan Cairns (acefnq)|
|Severity:||normal||CC:||benjamin.tissoires, chaostya, chzigotzky, jwrdegoede, nrndda|
Logitech Wireless Mouse Failure PPC
journalctl -b | grep -iE "kernel|udev" with usb logitech receiver error
Logitech Mouse Failure PPC
M280 mouse. Moved left/right, double clicked left/right buttons, clicked wheel, scrolled wheel
M280 mouse lsusb -v -d
[PATCH] HID: logitech-dj: Fix 064d:c52f receiver support
Description Allan Cairns 2019-05-16 04:43:56 UTC
Created attachment 282783 [details] Logitech Wireless Mouse Failure PPC Platform AmigaOne X5000 PPc Ubuntu 16.04.6 LTS Issue Using 5.2alpha kernel my Logitech Wireless USB Mouse M280 fails to operate. Using a test kernel composed by Christian Zigotzky (DRM11) I got the following data from xinput-list. I used the final drm11 test kernel and the alpha of 5.2. Outputs below, Logitech mouse works fine under drm11 but not under K5.2a DRM11: allan@Amigaone:~$ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Logitech USB Receiver id=7 [slave pointer (2)] ⎜ ↳ Logitech USB Receiver Consumer Control id=8 [slave pointer (2)] ⎜ ↳ Microsoft Wired Keyboard 600 Consumer Control id=10 [slave pointer (2)] ⎜ ↳ Microsoft Wired Keyboard 600 id=12 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Microsoft Wired Keyboard 600 id=9 [slave keyboard (3)] ↳ Microsoft Wired Keyboard 600 System Control id=11 [slave keyboard (3)] allan@Amigaone:~$ 5.2a allan@Amigaone:~$ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Logitech M280/320/275 id=7 [slave pointer (2)] ⎜ ↳ Microsoft Wired Keyboard 600 Consumer Control id=9 [slave pointer (2)] ⎜ ↳ Microsoft Wired Keyboard 600 id=11 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Microsoft Wired Keyboard 600 id=8 [slave keyboard (3)] ↳ Microsoft Wired Keyboard 600 System Control id=10 [slave keyboard (3)] Hi Ace, Thanks for reporting the issue with your Logitech wireless USB mouse. In my point of view the following updates are responsible for the issue. Link: HID updates I will try to compile a test kernel without these updates. Cheers, Christian
Comment 1 Christian Zigotzky 2019-05-22 02:28:40 UTC
We replaced the file “hid-logitech-dj.c” from the kernel 5.2-rc1 with the one from the kernel 5.1. After that, the Logitech mouse has worked again.
Comment 2 Hans de Goede 2019-05-22 10:49:01 UTC
Can you please reboot into the non working kernel, move and click the mouse a couple of times and then do: dmesg > dmesg.log After this run: sudo evemu-record This gives a list of devices the kernel has found, please copy and paste that list here. If your mouse is in the list, please type the number of your mouse and then move it around and click. Check if you see events being printed when moving / clicking. Please also report here which number(s) you've tried and if you see events from the mouse for those numbers.
Comment 3 Dmitry 2019-05-25 10:34:39 UTC
Created attachment 282939 [details] journalctl -b | grep -iE "kernel|udev" with usb logitech receiver error Can also reproduce not working logitech usb receiver in 5.2-r1, but for me it appears differently: 13:12:12 systemd-udevd: 1-8:1.0: Worker  processing SEQNUM=2452 is taking a long time 13:12:12 systemd-udevd: 1-8:1.1: Worker  processing SEQNUM=2453 is taking a long time 13:12:12 systemd-udevd: 1-8:1.2: Worker  processing SEQNUM=2454 is taking a long time 13:13:55 kernel: usb 1-8: USB disconnect, device number 2 13:14:12 systemd-udevd: 1-8:1.2: Worker  processing SEQNUM=2454 killed 13:14:12 kernel: hid-generic 0003:046D:C52B.0001: usb_submit_urb(ctrl) failed: -19 13:14:12 kernel: input: Logitech USB Receiver as /devices/pci0000:00/0000:00:01.3/0000:03:00.0/usb1/1-8/1-8:1.0/0003:046D:C52B.0001/input/input13 13:14:12 systemd-udevd: 1-8:1.1: Worker  processing SEQNUM=2453 killed 13:14:12 systemd-udevd: 1-8:1.0: Worker  processing SEQNUM=2452 killed 13:14:12 systemd-udevd: Worker  terminated by signal 9 (KILL) 13:14:12 systemd-udevd: 1-8:1.1: Worker  failed 13:14:12 systemd-udevd: Worker  terminated by signal 9 (KILL) 13:14:12 systemd-udevd: 1-8:1.2: Worker  failed There is some odds in behaviour: 1) Unplugging before boot and plugging after makes it work 2) Using usb3.0 port works after error above, but usb2 extender in usb3.0 port not
Comment 4 Allan Cairns 2019-05-26 02:20:03 UTC
Created attachment 282943 [details] Logitech Mouse Failure PPC File includes dmesg.log and evemu-record output. My mouse was listed as number 8, no movements were detected. Allan
Comment 5 Benjamin Tissoires 2019-05-28 09:59:24 UTC
@Dmitry: You seem to have a different mouse and a different receiver: yours is having the Product ID C52B, which is a Unifying receiver, when Allan has a C52F, which is an entirely different one. Please open a separate bug so we can accurately track the progresses. @Allan: I'll need some raw debugging of your device. As far as I can tell, the enumeration went fine, ("HID++ 4.1 device connected." appeared in the logs), so there must be a mismatch in the configuration we send to the mouse. Can you run "sudo hid-recorder /dev/hidraw*", move the mouse, click on it, then hit Ctrl-C. For hid-recorder, you can find it at https://gitlab.freedesktop.org/libevdev/hid-tools.
Comment 6 Hans de Goede 2019-06-03 09:49:09 UTC
@Allen: I've just received another bug-report of a user with a 0xc52f receiver not working. I have the feeling that this may be a mouse-only receiver and that it needs some special handling, like we already have for 27 MHz mouse-only receiver. That and/or its mouse HID input report may be different. If you don't have time to build and run hid-recorder, can you at least run these 2 simple commands and attach the generated output here? : 1: lsusb -v -d 0x046d:c52f > lsusb.log 2: As root: pushd /sys/kernel/debug/hid/ for i in *; do cat $i/rdesc > ~/$i.rdesc; done popd And then attach the generated lsusb.log and *.rdesc files here? Thanks. @Benjamin: Do you have a 0xc52f receiver? and have you tested with this ?
Comment 7 Benjamin Tissoires 2019-06-03 13:25:51 UTC
> @Benjamin: Do you have a 0xc52f receiver? and have you tested with this ? I was sure I did, but now that I looked for, I can't get my hands on one of those. So I must only have tested the series on the 0xc534, which might solve most of the issues.
Comment 8 Kostiantyn Miklevskyi 2019-06-03 21:05:40 UTC
Created attachment 283063 [details] M280 mouse. Moved left/right, double clicked left/right buttons, clicked wheel, scrolled wheel
Comment 9 Kostiantyn Miklevskyi 2019-06-03 21:07:06 UTC
Created attachment 283067 [details] M280 mouse lsusb -v -d
Comment 10 Kostiantyn Miklevskyi 2019-06-03 21:11:26 UTC
Created attachment 283073 [details] M280-rdesc-zip
Comment 11 Hans de Goede 2019-06-04 07:47:01 UTC
Kostiantyn, thank you for the logs. So as I suspected the c52f receiver is a mouse-only receiver and as such is different then the c534 nano receiver. So the addition of the c52f product-id to the logitech-dj driver when support for the c534 receiver was added, was a mistake and for 5.2 we are going to remove the c52f product it, reverting to the old 5.1 situation. We do want to eventually support the c52f receiver, and the logs will be very helpful for that. Are you willing to build your own kernel with a patch added to test c52f support for us?
Comment 12 Hans de Goede 2019-06-04 08:34:20 UTC
Created attachment 283087 [details] [PATCH] HID: logitech-dj: Fix 064d:c52f receiver support If you feel up to building your own kernel (see your distributions documentation), here is a patch which I believe should fix the support for the c52f receiver.
Comment 13 Kostiantyn Miklevskyi 2019-06-04 09:35:07 UTC
Created attachment 283089 [details] M325-M280-M235-receivers I've noticed that there's a different model suffix for M325 unifying receiver and M280 and M235 non-unifying. DJ vs DJR. I could attach logs for M235 non-unifying receiver if need be.
Comment 14 Christian Zigotzky 2019-06-05 09:38:47 UTC
Hello Hans, Many thanks for your patch. I successfully compiled the RC3 of kernel 5.2 with your new patch for the AmigaOne X1000 and X5000 yesterday. Download: http://www.xenosoft.de/linux-image-5.2-rc3-2_X1000_X5000.tar.gz @Allan Please test this kernel if you’re back from your work. Thanks to all for your work! Cheers, Christian
Comment 15 Benjamin Tissoires 2019-06-05 12:27:46 UTC
I just tested the patch on a brand new M280 with the C52F, and I can confirm that Hans' patch works as expected. I'll post this on the LKML and push it upstream right away.
Comment 16 Allan Cairns 2019-06-15 06:50:48 UTC
Using the new release candidate 4 (5.2RC4) by Christian my X5000 boots to my second graphics card (Firepro) and Logitech mouse works fine using the included patch.
Comment 17 Hans de Goede 2019-06-17 09:55:49 UTC
(In reply to Allan Cairns from comment #16) > Using the new release candidate 4 (5.2RC4) by Christian my X5000 boots to my > second graphics card (Firepro) and Logitech mouse works fine using the > included patch. Thank you for testing. Since you have confirmed that this is fixed I will close this bug now.
Comment 18 Kostiantyn Miklevskyi 2019-06-20 16:03:36 UTC
Thank you. M280 started working after 5.2 RC5 kernel upgrade. Good news, everyone. But there's still an issue. Solaar won't detect it. Solaar is a thirparty tool that manages Unifying receiver pairing and other things. It works with stock Ubuntu kernel 5.0.x and it was working for me in 5.1.x builds. Should I reopen this bug, create a new one here or in Solaar project on github?
Comment 19 Hans de Goede 2019-06-21 08:05:31 UTC
(In reply to Kostiantyn Miklevskyi from comment #18) > Thank you. M280 started working after 5.2 RC5 kernel upgrade. Good news, > everyone. > But there's still an issue. Solaar won't detect it. Solaar is a thirparty > tool that manages Unifying receiver pairing and other things. It works with > stock Ubuntu kernel 5.0.x and it was working for me in 5.1.x builds. Should > I reopen this bug, create a new one here or in Solaar project on github? Solaar should still be able to access the devices through the hidraw interface of the receiver (which is unchanged) just fine, so this is a bit weird. This likely has something to do with how solaar detects the devices. Can you please file a bug against solaar upstream for this? Please report back with a link to the solaar issue here, then I will add myself to the Cc of the solaar issue.
Comment 20 Allan Cairns 2019-08-06 02:32:55 UTC
All It appears the original issues have reappeared with the recent pre-releases of Kernel 5.3. Christian Zigotzky has narrowed down the issues to HID changes between 5.3-alpha and release candidates "OK, we definitely know that the issue is somewhere in the latest HID updates". Christian provided a test kernel without the latest HID update which work fine. I am not sure if these issues are related to the previous. Allan
Comment 21 Hans de Goede 2019-08-06 08:04:08 UTC
A patch fixing thr 5.3 regression has been queued for merging into 5.3 here: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-5.3/upstream-fixes Specifically this patch fixes the regression: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/commit/?id=6fb08f1a5f7e5cdde1ce00104788e602f4299b99