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