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

[Christian Klippel]

hi all,

Am Dienstag 24 Januar 2006 18:59 schrieb Hans-Christoph Steiner:
[...snip...]

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

true, using some kind of config file would make it more complicated at the 
start. there arent that many element types, dont confuse that with the hid 
names of the elements. there are either bitfields for stuff like keys, 
indicators, etc, and numerical elements whose range/size is defined in the 
descriptor as well. plus, they can be either absolute or relative values.

after all, it just boils down to what bits belong to buttons, lights, etc, and 
what bytes belong to numerical values. how they are named from hid can be 
completely disregarded when it comes to the raw data packet. its just 
important to know how the value fields are arranged in the incomming report.

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

yeah ... i must admit that i didnt found anything that could be nearly 
describe the unit, so i stuck with the multi-axis controller, wich it is kind 
of, just with a bit more axes....

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

yes, because if i would use the generic desktop page, the sliders would move 
your mouse actually.... well, at least two or three of them ....

also, the multio is really a pid device (as per definition), but i choosed hid 
becasue that is what most systems have implemented. the pid classes were not 
that well supported under linux at the time i wrote the first firmware.

in fact, the multio has way too much i/o capabilities for (at least the linux) 
hid / event system. for example, not all inputs are supported by default, 
becasue of some #define's in the linux drivers ... like, "#define ABSMAX 64", 
so that axes from > 64 arent rtecognized anymore. led's are even worse, 
becasue only a few are possible...... but this comes into play only if you 
really want to use 4 userboards at once ....

besides that, hid limits the functionality of the box in a way that there is 
no way to send setup-messages to the device, unless i would pack them into 
some really obscure report descriptor ...... not to forget the need to work 
around the hid specifics of value settings .....

after all, using hid was done only to have a simple, out-of-the-box way to use 
the device, without needing any special drivers ....

probably the most flexible and simple way is to enumerate such devices as 
usb-serial adapters with the cdc class. that way, any serial port accessing 
application can use the device..... and, i think that generic drivers for cdc 
devices are also available on any os ..... however, the multio will do 3 
types ...

> .hc
>

greets,

chris