Thread (1 message) 1 message, 1 author, 2013-10-01

Fwd: possible conflict between xhci_hcd and a patched usbhid?

From: Cristobal Navarro <hidden>
Date: 2013-10-01 18:26:07

---------- Forwarded message ----------
From: Cristobal Navarro <redacted>
Date: Tue, Oct 1, 2013 at 3:15 PM
Subject: Re: possible conflict between xhci_hcd and a patched usbhid?
To: Sarah Sharp <sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Xenia Ragiadakou
[off-list ref], Alan Stern [off-list ref],
linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org





On Tue, Oct 1, 2013 at 2:44 PM, Sarah Sharp
[off-list ref] wrote:
On Mon, Sep 30, 2013 at 11:19:56AM -0400, Cristobal Navarro wrote:
quoted
Dear Sarah,

Maybe you can help us. We, Razer Blade laptop users are having a weird
problem when patching the usbhid module and using the xhci_hcd module at
the same time.

Razer Blade Laptop users running linux need to fix the polling rate
interval of the usbhid module, to be 1000Hz in order for the laptop's
keyboard to work properly (it is a high performance keyboard). That is to
hardcode a line in drivers/hid/usbhid/hid-core.c to be "interval = 1;",
around line 1134 of hid-core.c
Can you send me the output of `sudo lsusb -v`?  The USB HID driver
should be creating a quirk for this device, rather than having users
hard-code the interval value for all USB HID devices.

I have attached it as 'lsusb_output.txt'. I think the device where the
keyboard is located is
Bus 001 Device 003: ID 1532:0116 Razer USA, Ltd

Just wanted to add that in addition, the laptop has eight led-keys
(possibly detected as another keyboard), and a trackpad with led
display on the back (in linux works as a trackpad only).


quoted
The problem is that if i also include the xhci_hcd module in the kernel,
then the fix at usbhid no longer works and the keyboard works faultly. So
at the moment, i have to remove hxci_hcd and loose USB 3.0 support i guess.
Yep, hard coding the interval won't help when the device is under xHCI.
The xHCI driver looks at the endpoint descriptors, not the URB interval,
when it sets up the poll rate.  Changing the URB interval will have no
impact on when transfers actually get scheduled.  The EHCI driver will
respect the interval in the URB, which is why it works under EHCI.

This has been a known issue for quite some time.  What we need is new
API to allow drivers to request a different interval than the one in the
endpoint descriptors.  That's not a simple fix, and I don't think it's
going to happen any time soon.  Maybe it's something Xenia could look
into?

I see now. In the worst case, would be great to be able to include
xHCI, at least
hardcoding xHCI source file in an equivalent way as in usbhid,
meanwhile a better fix comes.
If you need more output info just ask me,.
thanks,
Cristobal
quoted
Do you know what could be the cause of the problem? how could we fix it?
Does xhci_hcd module take over the laptop's keyboard instead of usbhid??

many thanks in advance, i appreciatte all the work you have done on USB 3.0.
Best regards,

Cristobal A. Navarro
Sarah Sharp

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help