Bug#248855: Useful clues for non-working USB keyboard on SunBlade 150 / sparc64
reassign 248855 kbd-chooser
retitle 248855 Does not detect usb keyboard on SunBlade 150
tags 248855 - moreinfo
tags 248855 + patch
thanks
On Tuesday 07 December 2004 12:51, Wiktor Wandachowicz wrote:
> However, I thought finally to check the source code of the kbd-chooser.
> I found a file "usb-kbd.c" in the location:
Thank you very much for your work! That is indeed usefull information.
The current code in fact checks for both 'usbkbd' and 'usbhid', as those
were the only variants observed so far.
Attached are two alternative patches for usb-kbd.c (both untested!):
1) The evidence seems to support the theory that usb keyboards can be
safely identified by CLs=03, Sub=01, Prot=01.
This patch cleans up the existing code based on that theory.
2) This patch says that there are too few cases to be certain about that
theory, certainly so close to the final build for Sarge.
It just adds the new observation in the existing code.
My gut feeling is that patch 1 is safe, but hey, I don't know f.all about
usb... The evidence _is_ based on at least three different arches though.
Joey, your call:
A) apply 1 to trunk and after testing to sarge branch
B) apply 2 to trunk and after testing to sarge branch; then apply 1 to
trunk for post-sarge development
The advantage of 1 is that we may catch other as yet unknown variations in
the Driver= without having to wade through bug reports.
Cheers,
FJP
--- usb-kbd.c 2004-11-09 14:59:30.000000000 +0100
+++ usb-kbd_alt1.c 2004-12-07 21:11:34.000000000 +0100
@@ -132,27 +132,13 @@
p = strstr(buf, "ProdID=");
productid = DEHEX(p + strlen("ProdID="));
}
- if ((p = strstr(buf, "usbkbd")) != NULL) {
- // This stanza refers to a usbkbd. We can use the
- // latest Vendor=XXXX ProdID=XXXX results
- di_debug ("Found usbkbd kdb: 0x%hx:0x%hx\n", vendorid, productid);
- k = usb_new_entry (keyboards);
- data = xmalloc(sizeof(usb_data));
- k->data = (usb_data *) data;
- data->vendorid = vendorid;
- data->productid = productid;
- k->present = TRUE;
- keyboards = k;
- }
- if (((p = strstr(buf, "usbhid")) != NULL) &&
- ((p = strstr(buf, "Cls=03")) != NULL) && // Human Interface Device
+ // The combination of Cls=03, Sub=01, Prot=01 seems a very reliable
+ // test to see that an usb keyboard is present. The Driver=...
+ // information seems to vary (usb, usbkbd, usbhid) and is ignored
+ if (((p = strstr(buf, "Cls=03")) != NULL) && // Human Interface Device
((p = strstr(buf, "Sub=01")) != NULL) && // Boot Interface Subclass
((p = strstr(buf, "Prot=01")) != NULL)) { // Keyboard
- // This stanza refers to a usbhid with a keyboard
- // attached. Unfortunately AFAICT there's no info
- // on the keyboard itself. For now let's assume
- // we can use the Vendor & ProdID of the HID itself.
- di_debug ("Found usbhid kbd: 0x%hx:0x%hx\n", vendorid, productid);
+ di_debug ("Found usb keyboard: 0x%hx:0x%hx\n", vendorid, productid);
k = usb_new_entry (keyboards);
data = xmalloc(sizeof(usb_data));
k->data = (usb_data *) data;
--- usb-kbd.c 2004-11-09 14:59:30.000000000 +0100
+++ usb-kbd_alt2.c 2004-12-07 21:11:49.000000000 +0100
@@ -144,7 +144,8 @@
k->present = TRUE;
keyboards = k;
}
- if (((p = strstr(buf, "usbhid")) != NULL) &&
+ if ((((p = strstr(buf, "Driver=usbhid")) != NULL) ||
+ ((p = strstr(buf, "Driver=usb")) != NULL)) &&
((p = strstr(buf, "Cls=03")) != NULL) && // Human Interface Device
((p = strstr(buf, "Sub=01")) != NULL) && // Boot Interface Subclass
((p = strstr(buf, "Prot=01")) != NULL)) { // Keyboard
@@ -152,7 +153,8 @@
// attached. Unfortunately AFAICT there's no info
// on the keyboard itself. For now let's assume
// we can use the Vendor & ProdID of the HID itself.
- di_debug ("Found usbhid kbd: 0x%hx:0x%hx\n", vendorid, productid);
+ // 'Driver=usb' was observed on a SunBlade 150 (sparc64)
+ di_debug ("Found usbhid/usb kbd: 0x%hx:0x%hx\n", vendorid, productid);
k = usb_new_entry (keyboards);
data = xmalloc(sizeof(usb_data));
k->data = (usb_data *) data;
Reply to: