On Jan 29, 2006, at 8:29 AM, Christian Klippel wrote:
hi all,
Am Sonntag 29 Januar 2006 07:20 schrieb Hans-Christoph Steiner:
[...snip...]
Call it a gamepad, call it a joystick, or call it a "MISC". In any case, they should have used one button type consistently... I forgot
to mention, these button types that I mentioned are actually the Linux interpretation of the USB HID spec, mostly its much better. I wonder what the actual "proper" USB HID values are for all the buttons...skimming through the hid usage tables ( http://www.usb.org/developers/devclass_docs/Hut1_12.pdf ) i see that
there are no MISC types anyway, only a reserverd range at the end of most
usage tables.this is generally the problem with hid names/usages: they thought of a
lot of things, but it can never be complete since there are too many different (new?) devices.if you look at the usage tables, what would you assign to these "hidden buttons" in david's device? i can see nothing that could fit....
Now that I have dived into the source again, I think this is more of a
question of how the Linux kernel module author mapped things. I am
curious to see how the buttons are mapped in USB HID. The problem
might either be with how Microsoft mapped the buttons to USB HID, or
how the kernel module author mapped the USB HID types to linux/input.h.
(David, maybe you could try the device on Mac OS X with [hid]?)
In linux/input.h, buttons are all laid out by device type, so it would
have been quite handy if the buttons of this device were mapped to
buttons of one type. All joystick buttons for example. That special
button could be a BTN_DEAD:
#define BTN_JOYSTICK 0x120 #define BTN_TRIGGER 0x120 #define BTN_THUMB 0x121 #define BTN_THUMB2 0x122 #define BTN_TOP 0x123 #define BTN_TOP2 0x124 #define BTN_PINKIE 0x125 #define BTN_BASE 0x126 #define BTN_BASE2 0x127 #define BTN_BASE3 0x128 #define BTN_BASE4 0x129 #define BTN_BASE5 0x12a #define BTN_BASE6 0x12b #define BTN_DEAD 0x12f
If the buttons were using USB HID's Button Page, then they would be
sequentially numbered, which is what [hid] does.
But the really great news is that I just found libHID! This sounds
like the perfect solution for the [hid] object in the future. Its a
library for working with HID that bypasses the OS and uses libusb to
access the device, then parses HID itself. Yeee haw! Its even in
Debian. So it looks like this is the future of the [hid] object. Then
there is (hopefully) no need for the [linuxhid], [windowshid], and
[darwinhid] objects, instead there can be [hid], [usb], and then
[linuxinput] and [directinput] for good measure.
http://libhid.alioth.debian.org/
.hc
"Information wants to be free." -Stewart Brand