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