2017-08-23 02:10 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0007340CentOS-7kernelpublic2016-11-21 18:07
ReporterLeScooterBug 
PriorityhighSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version7.0-1406 
Target VersionFixed in Version 
Summary0007340: Broken support for Logitech Unifying Receiver - Paired mouse not recognized as HID
DescriptionIn the current kernel release, 3.10.0-123.4.2, support for the Logitech Unifying Receiver is broken. The Unifying Receiver, itself, is found when connrcted to USB, but my wireless Logitech Performance Mouse MX is not activated as an HID device.

Similarly reported in this kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=60507
Steps To Reproduce1) Plug the Unifying Receiver into the USB port
2) Try to move the paired mouse around or click buttons.
3) Watch as nothing happens.
Additional Information[scott@localhost ~]$ dmesg | grep HID
[ 2.784327] hidraw: raw HID events driver (C) Jiri Kosina
[ 2.784384] usbhid: USB HID core driver
[ 3.921242] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-3.3/input2

[scott@localhost ~]$ lsusb | grep Logitech
Bus 002 Device 008: ID 046d:c52b Logitech, Inc. Unifying Receiver




Tagscentos 7, kernel, mouse, usb
abrt_hash
URL
Attached Files
  • patch file icon centos-linux-3.10-missing-Unifying-device-bug7340.patch (6,661 bytes) 2014-07-10 19:34 -
    centosplus patch bug #7340
    
    commit c63e0e370028d7e4033bd40165f18499872b5183
    Author: Nestor Lopez Casado <nlopezcasad@logitech.com>
    Date:   Thu Jul 18 06:21:30 2013 -0700
    
        HID: Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
        
        This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887.
        
        This patch re-adds the workaround introduced by 596264082f10dd4
        which was reverted by 8af6c08830b1ae114.
        
        The original patch 596264 was needed to overcome a situation where
        the hid-core would drop incoming reports while probe() was being
        executed.
        
        This issue was solved by c849a6143bec520af which added
        hid_device_io_start() and hid_device_io_stop() that enable a specific
        hid driver to opt-in for input reports while its probe() is being
        executed.
        
        Commit a9dd22b730857347 modified hid-logitech-dj so as to use the
        functionality added to hid-core. Having done that, workaround 596264
        was no longer necessary and was reverted by 8af6c08.
        
        We now encounter a different problem that ends up 'again' thwarting
        the Unifying receiver enumeration. The problem is time and usb controller
        dependent. Ocasionally the reports sent to the usb receiver to start
        the paired devices enumeration fail with -EPIPE and the receiver never
        gets to enumerate the paired devices.
        
        With dcd9006b1b053c7b1c the problem was "hidden" as the call to the usb
        driver became asynchronous and none was catching the error from the
        failing URB.
        
        As the root cause for this failing SET_REPORT is not understood yet,
        -possibly a race on the usb controller drivers or a problem with the
        Unifying receiver- reintroducing this workaround solves the problem.
        
        Overall what this workaround does is: If an input report from an
        unknown device is received, then a (re)enumeration is performed.
        
        related bug:
        https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649
        
        Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
        Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    
        Applied-by: Akemi Yagi <toracat@centos.org>
    
    diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
    index 5207591..cd33084 100644
    --- a/drivers/hid/hid-logitech-dj.c
    +++ b/drivers/hid/hid-logitech-dj.c
    @@ -192,6 +192,7 @@ static struct hid_ll_driver logi_dj_ll_driver;
     static int logi_dj_output_hidraw_report(struct hid_device *hid, u8 * buf,
     					size_t count,
     					unsigned char report_type);
    +static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev);
     
     static void logi_dj_recv_destroy_djhid_device(struct dj_receiver_dev *djrcv_dev,
     						struct dj_report *dj_report)
    @@ -232,6 +233,7 @@ static void logi_dj_recv_add_djhid_device(struct dj_receiver_dev *djrcv_dev,
     	if (dj_report->report_params[DEVICE_PAIRED_PARAM_SPFUNCTION] &
     	    SPFUNCTION_DEVICE_LIST_EMPTY) {
     		dbg_hid("%s: device list is empty\n", __func__);
    +		djrcv_dev->querying_devices = false;
     		return;
     	}
     
    @@ -242,6 +244,12 @@ static void logi_dj_recv_add_djhid_device(struct dj_receiver_dev *djrcv_dev,
     		return;
     	}
     
    +	if (djrcv_dev->paired_dj_devices[dj_report->device_index]) {
    +		/* The device is already known. No need to reallocate it. */
    +		dbg_hid("%s: device is already known\n", __func__);
    +		return;
    +	}
    +
     	dj_hiddev = hid_allocate_device();
     	if (IS_ERR(dj_hiddev)) {
     		dev_err(&djrcv_hdev->dev, "%s: hid_allocate_device failed\n",
    @@ -305,6 +313,7 @@ static void delayedwork_callback(struct work_struct *work)
     	struct dj_report dj_report;
     	unsigned long flags;
     	int count;
    +	int retval;
     
     	dbg_hid("%s\n", __func__);
     
    @@ -337,6 +346,25 @@ static void delayedwork_callback(struct work_struct *work)
     		logi_dj_recv_destroy_djhid_device(djrcv_dev, &dj_report);
     		break;
     	default:
    +	/* A normal report (i. e. not belonging to a pair/unpair notification)
    +	 * arriving here, means that the report arrived but we did not have a
    +	 * paired dj_device associated to the report's device_index, this
    +	 * means that the original "device paired" notification corresponding
    +	 * to this dj_device never arrived to this driver. The reason is that
    +	 * hid-core discards all packets coming from a device while probe() is
    +	 * executing. */
    +	if (!djrcv_dev->paired_dj_devices[dj_report.device_index]) {
    +		/* ok, we don't know the device, just re-ask the
    +		 * receiver for the list of connected devices. */
    +		retval = logi_dj_recv_query_paired_devices(djrcv_dev);
    +		if (!retval) {
    +			/* everything went fine, so just leave */
    +			break;
    +		}
    +		dev_err(&djrcv_dev->hdev->dev,
    +			"%s:logi_dj_recv_query_paired_devices "
    +			"error:%d\n", __func__, retval);
    +		}
     		dbg_hid("%s: unexpected report type\n", __func__);
     	}
     }
    @@ -367,6 +395,12 @@ static void logi_dj_recv_forward_null_report(struct dj_receiver_dev *djrcv_dev,
     	if (!djdev) {
     		dbg_hid("djrcv_dev->paired_dj_devices[dj_report->device_index]"
     			" is NULL, index %d\n", dj_report->device_index);
    +		kfifo_in(&djrcv_dev->notif_fifo, dj_report, sizeof(struct dj_report));
    +
    +		if (schedule_work(&djrcv_dev->work) == 0) {
    +			dbg_hid("%s: did not schedule the work item, was already "
    +			"queued\n", __func__);
    +		}
     		return;
     	}
     
    @@ -397,6 +431,12 @@ static void logi_dj_recv_forward_report(struct dj_receiver_dev *djrcv_dev,
     	if (dj_device == NULL) {
     		dbg_hid("djrcv_dev->paired_dj_devices[dj_report->device_index]"
     			" is NULL, index %d\n", dj_report->device_index);
    +		kfifo_in(&djrcv_dev->notif_fifo, dj_report, sizeof(struct dj_report));
    +
    +		if (schedule_work(&djrcv_dev->work) == 0) {
    +			dbg_hid("%s: did not schedule the work item, was already "
    +			"queued\n", __func__);
    +		}
     		return;
     	}
     
    @@ -444,6 +484,10 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
     	struct dj_report *dj_report;
     	int retval;
     
    +	/* no need to protect djrcv_dev->querying_devices */
    +	if (djrcv_dev->querying_devices)
    +		return 0;
    +
     	dj_report = kzalloc(sizeof(struct dj_report), GFP_KERNEL);
     	if (!dj_report)
     		return -ENOMEM;
    @@ -455,6 +499,7 @@ static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
     	return retval;
     }
     
    +
     static int logi_dj_recv_switch_to_dj_mode(struct dj_receiver_dev *djrcv_dev,
     					  unsigned timeout)
     {
    diff --git a/drivers/hid/hid-logitech-dj.h b/drivers/hid/hid-logitech-dj.h
    index fd28a5e..4a40003 100644
    --- a/drivers/hid/hid-logitech-dj.h
    +++ b/drivers/hid/hid-logitech-dj.h
    @@ -101,6 +101,7 @@ struct dj_receiver_dev {
     	struct work_struct work;
     	struct kfifo notif_fifo;
     	spinlock_t lock;
    +	bool querying_devices;
     };
     
     struct dj_device {
    

-Relationships
related to 0007401new Logitech k400r wireless keyboard not detected by GUI during NetInstall 
+Relationships

-Notes

~0020335

LeScooterBug (reporter)

I didn't have a keyboard available to test, but this is a more detailed output from lsusb -v


Bus 002 Device 010: ID 046d:c52b Logitech, Inc. Unifying Receiver
Couldn't open device, some information will be missing
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor 0x046d Logitech, Inc.
  idProduct 0xc52b Unifying Receiver
  bcdDevice 12.01
  iManufacturer 1
  iProduct 2
  iSerial 0
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 84
    bNumInterfaces 3
    bConfigurationValue 1
    iConfiguration 4
    bmAttributes 0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower 98mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 1
      bInterfaceClass 3 Human Interface Device
      bInterfaceSubClass 1 Boot Interface Subclass
      bInterfaceProtocol 1 Keyboard
      iInterface 0
        HID Device Descriptor:
          bLength 9
          bDescriptorType 33
          bcdHID 1.11
          bCountryCode 0 Not supported
          bNumDescriptors 1
          bDescriptorType 34 Report
          wDescriptorLength 59
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0008 1x 8 bytes
        bInterval 8
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 1
      bAlternateSetting 0
      bNumEndpoints 1
      bInterfaceClass 3 Human Interface Device
      bInterfaceSubClass 1 Boot Interface Subclass
      bInterfaceProtocol 2 Mouse
      iInterface 0
        HID Device Descriptor:
          bLength 9
          bDescriptorType 33
          bcdHID 1.11
          bCountryCode 0 Not supported
          bNumDescriptors 1
          bDescriptorType 34 Report
          wDescriptorLength 148
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x82 EP 2 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0008 1x 8 bytes
        bInterval 2
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 2
      bAlternateSetting 0
      bNumEndpoints 1
      bInterfaceClass 3 Human Interface Device
      bInterfaceSubClass 0 No Subclass
      bInterfaceProtocol 0 None
      iInterface 0
        HID Device Descriptor:
          bLength 9
          bDescriptorType 33
          bcdHID 1.11
          bCountryCode 0 Not supported
          bNumDescriptors 1
          bDescriptorType 34 Report
          wDescriptorLength 98
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x83 EP 3 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0020 1x 32 bytes
        bInterval 2

~0020354

tigalch (manager)

I've successfully installed C7 an a laptop with a unifying receiver, allthough it is a zone touch mouse. Not shure how to reproduce this issue.

~0020356

toracat (manager)

According to the bug report you referenced (#60507 at kernel.org), this bug was fixed in kernel 3.11.0 (commit c63e0e37) and 3.10.27.

To see if your device works in a newer kernel, could you test-install kernel-ml [1] from ELRepo? When you're done, you can uninstall it by 'yum remove kernel-ml', or keep it until the CentOS kernel gets the fix (in kernel-plus).

[1] http://elrepo.org/tiki/kernel-ml

~0020365

toracat (manager)

Patch uploaded.

~0020369

LeScooterBug (reporter)

Hi toracat

I installed latest kernel-ml from ELRepo, currently 3.15.5-1.el7.elrepo.x86_64, and I can confirm that my mouse works, again. I detached, then reattached the Unifying Receiver, and my mouse still worked correctly.

~0020370

toracat (manager)

That is assuring. I will try patching the centosplus kernel. In the meantime, you should be able to keep using kernel-ml.

~0020448

toracat (manager)

There is a new piece of info from smooge regarding the bug.

Bus 001 Device 003: ID 046d:c52b

"I might have figured out why the logitech unify works for some people and not others without a kernel fix. The two boxes I have that don't work had either USB-3 only or USB-1.5 only. When I switched the laptop to be USB-2 only (its a bios setting) the logitech began to work"

"so maybe it is usb-2.0 versus usb-special"

~0020449

LeScooterBug (reporter)

That could be. My HP EliteBook 850 G1 only has USB 3.0 ports. I haven't installed CentOS-7 on any other computer that has USB 2.0.

I do want to note something I discovered, though. When using the current, stable kernel, if I unplug and re-attach the receiver multiple times (in the same port), the mouse will start working after one of those attempts. This does seem to support the "race condition" with USB 3.0 I've read about.

~0020555

toracat (manager)

The patch is in the latest update to kernel-plus: 3.10.0-123.4.4.el7.centos.plus.

~0020928

nbalonso (reporter)

I can confirm the same thing.

My logitech K400r was not working with kernel 3.10.0-123.6.3.el7.x86_64

Now with 3.16.2-1.el7.elrepo.x86_64 works flawlessly

Thanks

~0021996

kowalsky (reporter)

I have CentOS with the Kde desktop installed with the latest yum update. My Logitech Revolution MX mouse is not working (which seems to be the same bug as this issue is describing). My kernel version : 3.10.0-123.13.1.el7.x86_64.

According to the comment on this thread this version should include the fix ? (or I misunderstand the version number).

Thanks.

~0021997

toracat (manager)

@kowalsky

Until the patch is applied to the upstream (RHEL) kernel, CentOS kernel will not work. You want to use the centosplus kernel, kernel-plus, which has the fix.

~0022284

cageordie (reporter)

For others still stuck with this issue: I am using a Dell Precision M6800 with 3.10.0-123.20.1.el7.x86_64. Re-plugging the receiver in the built in ports does not help, the mouse keeps on not working. However, on the second attempt in a USB 2.0 hub the mouse worked. So try an external hub until you can update to the fixed release.

~0026836

toracat (manager)

Closing due to inactivity.

~0027956

toracat (manager)

Just a short note to add that the patch applied to the plus kernel is now in the 7.3 kernel.
+Notes

-Issue History
Date Modified Username Field Change
2014-07-10 01:28 LeScooterBug New Issue
2014-07-10 02:04 LeScooterBug Note Added: 0020335
2014-07-10 15:27 LeScooterBug Tag Attached: centos 7
2014-07-10 15:27 LeScooterBug Tag Attached: kernel
2014-07-10 15:27 LeScooterBug Tag Attached: usb
2014-07-10 15:27 LeScooterBug Tag Attached: mouse
2014-07-10 17:47 tigalch Note Added: 0020354
2014-07-10 18:11 toracat Note Added: 0020356
2014-07-10 18:11 toracat Status new => feedback
2014-07-10 19:34 toracat File Added: centos-linux-3.10-missing-Unifying-device-bug7340.patch
2014-07-10 19:36 toracat Note Added: 0020365
2014-07-10 21:58 LeScooterBug Note Added: 0020369
2014-07-10 21:58 LeScooterBug Status feedback => assigned
2014-07-10 22:39 toracat Note Added: 0020370
2014-07-16 18:14 toracat Note Added: 0020448
2014-07-16 19:46 LeScooterBug Note Added: 0020449
2014-07-19 18:23 toracat Relationship added related to 0007401
2014-07-31 11:50 toracat Note Added: 0020555
2014-09-17 15:33 nbalonso Note Added: 0020928
2014-12-18 17:55 kowalsky Note Added: 0021996
2014-12-18 18:01 toracat Note Added: 0021997
2015-02-04 22:33 cageordie Note Added: 0022284
2016-06-10 03:56 toracat Note Added: 0026836
2016-06-10 03:56 toracat Status assigned => resolved
2016-06-10 03:56 toracat Resolution open => fixed
2016-11-21 18:07 toracat Note Added: 0027956
+Issue History