[PD] joysticks with hid

Hans-Christoph Steiner hans at eds.org
Sun Jan 29 18:01:36 CET 2006


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





More information about the Pd-list mailing list