[Please CC replies to me because I've not subscribed this list]
I have an USB Keyboard with some multimedial keys: most worked as expected,
but the tree 'cut', 'copy' and 'paste' keys didn't work. I investigated a bit
and I solved by modifying the function hidinput_configure_usage in
hid-input.c.
I discovered that my keyboard identifies that keys as HID_UP_BUTTON instead
of, e.g., HID_UP_CONSUMER: more, the 'application' field seems to be not
standard (I've not found this value in hid.h), and the 'usage->code' fields
are greater than 255, so that the input subsystem doesn't recognize them ad
"standard" keys.
I've written a little patch that recognize that usages and fix them by
re-assigning a suitable code. Unfortunately I've no chance to test the patch
with other keyboards, so I can't know if it works only for my model or if
it's a more general patch.
Here is the patch, comments are appreciated.
Cheers,
Antonio
[sorry for my not-so-good english, but I'm not a native speaker... ]
--- drivers/usb/input/hid-input.c.orig 2004-04-25 10:23:49.000000000 +0200
+++ drivers/usb/input/hid-input.c 2004-04-25 10:32:54.000000000 +0200
@@ -122,6 +122,22 @@ static void hidinput_configure_usage(str
case HID_GD_GAMEPAD: usage->code += 0x10;
case HID_GD_JOYSTICK: usage->code += 0x10;
case HID_GD_MOUSE: usage->code += 0x10; break;
+
+ case 0x000C0003:
+ /* reported on a (broken?) USB Keyboard: the three
+ * 'cut', 'copy' and 'paste' keys are seen as
+ * HID_UP_BUTTON instead of, e.g.,
+ * HID_UP_CONSUMER. The keys report a keycode > 255,
+ * so we need to fix it.
+ */
+
+ switch (usage->code) {
+ case 0x10f: usage->code = KEY_CUT; break;
+ case 0x100: usage->code = KEY_COPY; break;
+ case 0x101: usage->code = KEY_PASTE; break;
+ }
+ break;
+
default:
if (field->physical == HID_GD_POINTER)
usage->code += 0x10;
