Bug 2201
| Summary: | Keyboard found randomly as mouse, keyboard or both | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Dennis Haney (davh) |
| Component: | USB | Assignee: | Vojtech Pavlik (vojtech) |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | high | CC: | dennisn |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.3 and below | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 5089 | ||
| Attachments: | Get descriptor retry patch | ||
|
Description
Dennis Haney
2004-02-26 07:11:07 UTC
Distribution: Self-build 2.6.5 (with gcc 3.3.2)
Hardware Environment: Logitech Internet Navigator Keyboard (USB)
I had the same problem with 2.6.5. Most times the Kernel didn't bind the
hid-driver to the keyboard. I have tracked down the Problem to this this function:
linux/drivers/usb/input/hid-core.c
> static int hid_get_class_descriptor(struct usb_device *dev, int ifnum,
> unsigned char type, void *buf, int size)
> {
> return usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
> USB_REQ_GET_DESCRIPTOR, USB_RECIP_INTERFACE | USB_DIR_IN,
> (type << 8), ifnum, buf, size, HZ * USB_CTRL_GET_TIMEOUT);
> }
In some cases this function returns without any byte read. The debug-output
shows: "report descriptor (size xyz, read 0)" and tries to interpret the data.
I think usb_control_msg times out too fast.
I for myself solved the problem by looping until an error occured or enough data
has been read. I know its *dirty*, but it works fine for me.
I get the same randomly-found problems with my Logitech Internet Navigator
Keyboard - most of the time, either the keyboard or the aditional keys are not
detected. (ie. usbhid: probe of 1-1.3:1.0 failed with error -5)
Within linux/drivers/usb/input/hid-core.c for linux-2.6.8-rc4, I tried doing the
following to "fix" the problem:
static int hid_get_class_descriptor(struct usb_device *dev, int ifnum,
unsigned char type, void *buf, int size)
{
usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_RECIP_INTERFACE | USB_DIR_IN,
(type << 8), ifnum, buf, size, HZ * USB_CTRL_GET_TIMEOUT);
return 0;
}
Basically, it only works when I return 0. Any non-zero return value (i think)
results in the -5 probe error, and the device not being detected.
Nevermind .. my last suggestion to force the function to not return an error did not work today .. although, honestly, it did appear to work for a few days =) I will try to loop for data, as Alex suggested. Created attachment 3688 [details]
Get descriptor retry patch
ie.
static int hid_get_class_descriptor(struct usb_device *dev, int ifnum,
unsigned char type, void *buf, int size)
{
int retv = 0;
while ( retv < 2 ) {
retv = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_RECIP_INTERFACE | USB_DIR_IN,
(type << 8), ifnum, buf, size, HZ * USB_CTRL_GET_TIMEOUT);
}
return retv;
}
has the patch actually been applied? ... i'm using kernel v2.6.10 (gentoo-r2), and it was not patched =( the patch isn't working properly, for me (linux-2.6.10-gentoo-r2, Logitech USB Keyboard) - my keyboard (or the 'mouse' on the keyboard) is still frequently not detected. i think result=0 is also an error, and instead, we should loop until result > 0. i did this, and so far, it seems to work. also, any ideas why hid_get_class_descriptor would fail? You should loop while result==0. Result<0 means there was an error. Is this still a problem on 2.6.13-rc6 or greater? If so, please reopen with the new information. |