Bug 60507 - Logitech Unified Receiver support broken, mouse won't work
Logitech Unified Receiver support broken, mouse won't work
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Input Devices
x86-64 Linux
: P1 high
Assigned To: drivers_input-devices
:
: 60572 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-04 21:33 UTC by Andreas Reis
Modified: 2014-03-28 09:34 UTC (History)
10 users (show)

See Also:
Kernel Version: 3.10.0
Tree: Mainline
Regression: Yes


Attachments
cellisten's dmesg (79.72 KB, text/plain)
2013-08-16 19:41 UTC, Peter Wu
Details
cellisten's lsusb -v (30.42 KB, text/plain)
2013-08-16 19:42 UTC, Peter Wu
Details
cellisten's usbmon (via debugfs) (98.03 KB, text/plain)
2013-08-16 19:51 UTC, Peter Wu
Details

Description Andreas Reis 2013-07-04 21:33:14 UTC
My wireless mouse (Anywhere MX) isn't registered anymore in 3.10.0.

"dmesg | grep HID" still contains:
[    2.191916] logitech-djreceiver 0003:046D:C52B.0005: hiddev0,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-8/input2

A quick search showed that this workaround in hid-logitech-dj was reverted in 3.10.0 for a proper solution, which unfortunately doesn't work, at least not for all devices:

https://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?id=8af6c08830b1ae114d1a8b548b1f8b056e068887

I reapplied the workaround (introduced Oct, 2012: https://patchwork.kernel.org/patch/1562431 ) and the cursor moves again. "dmesg | grep HID" then also contains:

[   22.285488] logitech-djdevice 0003:046D:C52B.0006: input,hidraw3: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:1017] on usb-0000:00:14.0-8:1

Others have confirmed the bug, see Launchpad (I use Arch): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649
Comment 1 G.Wolfe Woodbury 2013-07-07 23:25:00 UTC
confirming the bug.
Logitech wireless trackball (unifying receiver) is detected on the USB bus, but further action to activate it as a mouse device does not occur.

Andreas' analysis above is correct.
Comment 2 G.Wolfe Woodbury 2013-07-20 15:18:39 UTC
Please *REVERT* kernel commit 

https://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?id=8af6c08830b1ae114d1a8b548b1f8b056e068887

because the code it removes is still necessary to properly associate the
mouse with the logitech unifying receiver.  The messages sent during "probe"
phase are getting diverted and ignored. The additional re-probes proviede by the code this commit removes are still required.
Comment 3 Aristid Breitkreuz 2013-07-20 18:04:04 UTC
My Performance MX mouse is also affected. Kernel versions 3.10.0 and 3.10.1 are affected, 3.9.10 and all earlier 3.9 versions that I used are not affected.

I also get a message in the kernel that the Logitech receiver is detected, but no mouse is.
Comment 4 Ethan 2013-08-04 22:00:54 UTC
(In reply to Andreas Reis from comment #0)
> My wireless mouse (Anywhere MX) isn't registered anymore in 3.10.0.
> 
> "dmesg | grep HID" still contains:
> [    2.191916] logitech-djreceiver 0003:046D:C52B.0005: hiddev0,hidraw2: USB
> HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-8/input2
> 
> A quick search showed that this workaround in hid-logitech-dj was reverted
> in 3.10.0 for a proper solution, which unfortunately doesn't work, at least
> not for all devices:
> 
> https://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/
> ?id=8af6c08830b1ae114d1a8b548b1f8b056e068887
> 
> I reapplied the workaround (introduced Oct, 2012:
> https://patchwork.kernel.org/patch/1562431 ) and the cursor moves again.
> "dmesg | grep HID" then also contains:
> 
> [   22.285488] logitech-djdevice 0003:046D:C52B.0006: input,hidraw3: USB HID
> v1.11 Mouse [Logitech Unifying Device. Wireless PID:1017] on
> usb-0000:00:14.0-8:1
> 
> Others have confirmed the bug, see Launchpad (I use Arch):
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649

I am experiencing this bug as well.

Andreas, could you please explain to me how you reapplied the old workaround? I am running Fedora 19 if that makes any difference. I would very much appreciate it, I am a newbie to Linux. Thank you. :)
Comment 5 Andreas Reis 2013-08-05 15:23:12 UTC
Basically it's just inserting this line before the make command(s) into the build script (I don't know how Fedora/YUM/RPM handles this, so I can't help you there, sorry):

patch -Np1 -i [if required: /path/to/patch/]patchfile

Check "man patch" for an explanation of these CL arguments.
Comment 6 Peter Wu 2013-08-12 22:03:55 UTC
See also discussion at LKML[1]. A workaround that triggers re-enumeration without having to remove the USB receiver[2] (essentially same magic as in hid-logitech-dj driver):

# should output /dev/hidrawN where N is usually 0
hidraw=/dev/$(cd /sys/bus/hid/drivers/logitech-djreceiver/*/hidraw &&
echo hidraw*)
printf '\x20\xff\x81\0\0\0\0\0\0\0\0\0\0\0\0' | sudo tee "$hidraw" >/dev/null

 [1]: http://www.spinics.net/lists/linux-input/msg26713.html
 [2]: https://bbs.archlinux.org/viewtopic.php?pid=1309535#p1309535
Comment 7 Peter Hurley 2013-08-13 16:27:51 UTC
@Andreas Reis,

As the OP, on any 3.10+ vanilla kernel, please attach
1) complete dmesg output
2) usbmon capture of a plug attempt
Comment 8 Peter Wu 2013-08-16 19:41:22 UTC
Created attachment 107220 [details]
cellisten's dmesg

I got these files from cellisten from the Arch Linux forums[1].

 [1]: https://bbs.archlinux.org/viewtopic.php?pid=1312624#p1312624
Comment 9 Peter Wu 2013-08-16 19:42:58 UTC
Created attachment 107221 [details]
cellisten's lsusb -v

The affected 001.004 (bus.dev) device is using the xhci driver (see dmesg).
Part from lsusb:

    Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver
Comment 10 Peter Wu 2013-08-16 19:51:16 UTC
Created attachment 107222 [details]
cellisten's usbmon (via debugfs)

Post-processing the usbmon output with an AWK script[1] helped me find an issue. Consider this part:

ffff8803f4802cc0 3000314283 S Ii:1:012:3 -115:2 32 <
ffff8803f4802840 3000314443 C Co:1:012:0 0 15 >
ffff8803f4802840 3000314449 S Co:1:012:0 s 21 09 0220 0002 000f 15 = 20ff8100 00000000 00000000 000000
ffff8803f4802840 3000314525 C Co:1:012:0 -32 0

After sending an enumeration report to the receiver (20 ff 81 00..), a callback is returned with -EPIPE. This sounds familiar, it was reported to the mailing lists before by Benjamin Tissoires[2].

After 3.3 seconds, the receiver reports a connected device:
ffff8803f4802cc0 3003676450 C Ii:1:012:3 0:2 15 = 20014200 00000000 00000000 000000

I do not know what is happening here, let me know if you need more details.


 [1]: https://git.lekensteyn.nl/ltunify/tree/usbmon.awk
 [2]: https://lkml.kernel.org/r/CAN+gG=HKe0eNBmwaf=h6nzR9U3DPC-Hvb1W-uwVqjih5AiKUuQ@mail.gmail.com
Comment 11 Balder Lingegård 2013-08-16 21:15:03 UTC
I am Cellisten, if you want me to try any patches, just tell me. The dmesg and lsusb was captured after I had renumerated the receiver to make it work. The usbmon was captured after I unplugged the receiver and reinserted it. I have a 100% failure rate when doing that. Best regards /Balder
Comment 12 Peter Hurley 2013-08-19 00:44:32 UTC
@Peter and Balder,

Thanks for all the trace and report data.
Please open a *new* kernel bug assigned to Drivers/USB with the files and commentary you posted here.

The OP for this bug may or may not have the identical problem you're experiencing, so this may confuse the proper resolution of both your bug and the OP's.

I suspect your bug is a known bug with the xhci-hcd driver that needs to get fixed.
Comment 13 Peter Wu 2013-08-19 14:47:12 UTC
@Balder, please open a new bug. Can you also try 3.11-rc6 with commit c63e0e370028d7e4033bd40165f18499872b5183 reverted?

I could not reproduce the XHCI issue on my laptop which runs 3.11-rc6 (with that commit reverted).
Comment 14 Peter Hurley 2013-08-19 15:36:39 UTC
(In reply to Peter from comment #13)
> @Balder, please open a new bug. Can you also try 3.11-rc6 with commit
> c63e0e370028d7e4033bd40165f18499872b5183 reverted?
> 
> I could not reproduce the XHCI issue on my laptop which runs 3.11-rc6 (with
> that commit reverted).

Perhaps commit 481f2d4f89f87a0baa26147f323380e31cfa7c44 'usb: core: don't try to reset_device() a port that got just disconnected' has addressed one aspect of the underlying bug and therefore not triggered the xHCI reset-on-not-halted-endpoint bug?

Can you revert commit 481f2d4f on vanilla 3.11-rc6 and reproduce this bug?
Comment 15 Peter Wu 2013-08-19 21:01:24 UTC
I reverted 481f2d4f and c63e0e3 on top of 3.11-rc6, but I can still not reproduce the bug. I cannot reproduce it on my laptop (M525) nor my desktop (K800). On the desktop, I also tried vanilla 3.10.5 which still does not expose the bug. Below you can find lshw output for the machines.

When comparing Baldars usbmon with the one from my desktop, there is absolutely no difference in the data except for the callback output ("-32 0" vs "0 15 >") and the additional NOTIF_DEVICE_PAIRED messages using isochronous input (for my working desktop).

In order to compare the usbmon logs, I use the following bash functions:
##################################################
filter(){ sed -r -e "s/^[0-9a-f]+ [0-9]+ /# /" -e \
"s/([IC][oi]:)[0-9]:0[0-9][0-9]:[0-9]/\1#:0##:#/" "$@";}
comp() {
    diff -u --label "$1" --label "$2" \
        <(filter "$1") <(filter "$2")
}
ccomp(){ colordiff -u "$@" | less -r; }
ccomp usbmon-xhci usbmon-xhci-new
##################################################

lshw for my laptop:
        *-pci:1
             description: PCI bridge
             product: 5 Series/3400 Series Chipset PCI Express Root Port 1
             vendor: Intel Corporation
             physical id: 1c
             bus info: pci@0000:00:1c.0
             version: 05
             width: 32 bits
             clock: 33MHz
             capabilities: pci normal_decode bus_master cap_list
             configuration: driver=pcieport
             resources: irq:16 ioport:3000(size=4096) memory:fc000000-fcffffff ioport:fa000000(size=16777216)
           *-usb
                description: USB controller
                product: uPD720200 USB 3.0 Host Controller
                vendor: NEC Corporation
                physical id: 0
                bus info: pci@0000:02:00.0
                version: 03
                width: 64 bits
                clock: 33MHz
                capabilities: xhci bus_master cap_list
                configuration: driver=xhci_hcd latency=0
                resources: irq:16 memory:fc000000-fc001fff

lshw for desktop:
        *-pci:2
             description: PCI bridge
             product: 6 Series/C200 Series Chipset Family PCI Express Root Port 5
             vendor: Intel Corporation
             physical id: 1c.4
             bus info: pci@0000:00:1c.4
             version: b5
             width: 32 bits
             clock: 33MHz
             capabilities: pci normal_decode bus_master cap_list
             configuration: driver=pcieport
             resources: irq:16 memory:f7a00000-f7afffff
           *-usb
                description: USB controller
                product: EJ168 USB 3.0 Host Controller
                vendor: Etron Technology, Inc.
                physical id: 0
                bus info: pci@0000:04:00.0
                version: 01
                width: 64 bits
                clock: 33MHz
                capabilities: xhci bus_master cap_list
                configuration: driver=xhci_hcd latency=0
                resources: irq:40 memory:f7a00000-f7a07fff
Comment 16 Balder Lingegård 2013-08-20 17:04:54 UTC
I will try to find some time this week to troubleshoot further.
Comment 17 Alan 2013-11-13 16:47:33 UTC
*** Bug 60572 has been marked as a duplicate of this bug. ***
Comment 18 Jean Delvare 2014-03-24 12:15:11 UTC
What is the status of this bug? Commit 8af6c088 was reverted in kernels 3.11.0 (commit c63e0e37) and 3.10.27, so I believe the bug should be gone when using these or more recent kernels. Andreas (or others), can you confirm?
Comment 19 G.Wolfe Woodbury 2014-03-24 12:40:26 UTC
Yes, this bug should be closed.  Kernels in 3.13.x series are working fine without having to tweak hid/logitech-dj.c

Note You need to log in before you can comment on or make changes to this bug.