[PD-dev] making a libusb object (expanding on [hid] toolkit)

[Hans-Christoph Steiner]

On Jan 20, 2006, at 4:02 PM, Christian Klippel wrote:

> hi,
>
> Am Freitag 20 Januar 2006 20:48 schrieb Hans-Christoph Steiner:
> [...snip...]
>>>
>>> even just saying "let make a general hid object for hid-speaking
>>> devices" is
>>> almost impossible. just because something talks hid, it doesnt mean  
>>> it
>>> sends
>>> the data in the same format .....
>>
>> Not quite impossible, but difficult.  But you can chip away at the
>> problem in the way I did with [mouse], [joystick], [gamepad], etc.
>> objects.  The output from [hid] is autoscaled to 0-1, so even tho the
>> data that comes from the devices varies widely, the data that comes  
>> out
>> of [joystick], for example, is always 0-1.
>>
>
> ok, lets examine that. when hid is used, we _can_ refer to the  
> hid-name to map
> axes & buttons, but this can be done easily only if the hid api from  
> the os
> is used. this is because the hid driver knows what values refer to what
> axes/buttons.
>
> now, if you want to have a generic access to hid devices, you need to  
> put the
> complete descriptor parser inside the object/abstraction as well. and  
> it is
> only this descriptor(s) that tell you what is what. if you dont look  
> at them,
> but only at the data packet that is sent (i.e., the buffer that you  
> receive
> when issuing a usb_interrupt_read() on that device), its no longer  
> clear what
> is what.
>
> a report descriptor is like:
>
> i'm a mouse
>  i have relatives axes
>   two of them
>  i have three buttons
>   arranged this way
> done.
>
> the resulting data packet would be <axis1><axis2><bitmap for buttons>
>
> however, it could specify itself that way also:
>
> i'm a mouse
>  i have three buttons
>   .....
>  there are two relative axis
>   ....
> done.
>
> wich, of course, results in a packet of <button-bitmap><axis1><axis2>
>
> to make things even more complicated, each axis could have his very  
> own report
> descriptor as well .... then it looks like:
>
> i'm a mouse
>  this is report #1
>   for one relative axis
>  end of this report
>  this is report #2
>   for one relative axis
>  end of this report
>  .....
> .....
>
> now, the data packet looks _completely_ different, actually there can  
> be
> serveral different packets, only distinguished by their report id as
> specified in the descriptor:
> <report-id 1><rel.axis x>
> _or_
> <report-id 2><rel.axis y>
> _or_
> <report-id 3><button #1>
> etc, etc.....
>
> while the access will be always the same via hid, it is differently by  
> means
> of the layout of the actual data.
>
> im not sure that it is the best idea to re-implement the hid  
> interpreter
> stuff. in case of "always same functions but different brands" stuff  
> like
> mice, joysticks, etc. it may be more usefull to give the object the  
> mapping
> of the data either as argument, or as cfg file. this would be a big
> performance gain also, since the whole interpretation stuff is gone.  
> sure,
> for simple things that may not matter, but what if you have 32 faders  
> to
> fiddle with? thats already quite some traffic....

For the goal of "just working" when you using [mouse], for example, the  
config file idea would make things much more complicated.  Personally,  
I think that USB HID has far too many element types, there is a lot of  
redundancy which is more likely to cause problems than help, IMHO.   
That's what I followed the Linux input event example, where they  
simplified things.  Perhaps this should not be called HID then.

I have been thinking that sequentially numbered types might work for  
the MultIO-style multi-axis controller.  Otherwise, how do you spec out  
88 specific axes in HID?  Here's what the USB spec has to say about  
they think a "Multi-Axis Controller" is:

"An input device used to orient eyepoints and or objects in 3  
dimensional  space. A Multi-axis Controller typically consists of six,  
variable axes (X, Y,  Z, Rx, Ry and Rz) and is used by CAD/digital  
content creation applications  for model manipulation and visualization  
in 3D space. The device may  incorporate zero or more buttons."

Is the MultIO using the "Ordinal Page" stuff?  That seems even more  
obtuse than the rest of USB HID.   Ug... design by corporate  
committee...  I am starting to think that maybe we should just define a  
new standard for sensorboxes, maybe based on OSC.  But then you'd loose  
the nice plug-n-play aspect of HID, like making your own joystick,  
mouse, etc.

.hc

>
> for "custom devices" like cui, arduino, multio, .... i dont see any  
> other way
> than to have seperate "core drivers" for each device ....
>
> [...snip...]
>>
>> The unified format is one of the essential themes of the [hid] toolkit
>> objects.  All of them expect input data in the range 0-1 and output
>> 0-1.  So even if you use the [hid_polar] object, which converts
>> cartesian coords to polar coords, the angle is also output in a range
>> from 0-1.  While this might seem like blasphemy to some  
>> mathematicians,
>> it makes it so that you can chain hid toolkit objects without having  
>> to
>> think about the rescaling the data each time.  And there is [hid2rad]
>> for the mathematicians ;).
>>
>
> yes, i think thats a very good idea. btw, its also no problem to do the
> conversion to/from float inside the firmware as well. im going to do  
> that ;-)
>
>> Also, the [joystick] object has a standard number of axes.  Its a  
>> basic
>> set that basically all joysticks should support.  Then if you want to
>> use any extra axes, you can use [hid] directly, but you loose the
>> cross-joystick compatibility of the patch.
>>
>
> right, but as said above, if it is wanted to bypass the os's hid  
> system and
> directly access the device, the object needs a way to know what is  
> what ....
>
> of course, when the hid-system is accessed from those objects, than it  
> doesnt
> matter because of hid doing the naming/numbering already .... so, if  
> it is
> not intended to drop "real hid access" and use libusb instead, you can  
> forget
> about all that ;-D
>
>
>> But the idea of having device-specific objects which then translate
>> into standard elements is interesting...
>>
>> .hc
>>
>
> greets,
>
> chris
>
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>

________________________________________________________________________ 
____

                   ¡El pueblo unido jamás será vencido!