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

[Christian Klippel]

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 "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