hello all,
as for the recent discussion about the [hid] object, i just have uploaded two pdf documents to my site:
http://mamalala.de/Hut1_11.pdf - HID Usage Tables http://mamalala.de/HID1_11.pdf - HID Specs
of most interrest here are the usage tables, i think.
as you can see there, there is a number of choices how single number (event-type) is mapped to the hid-name. it all depends on the selected usage tables.
btw, i would say that it is a good idea to use the names as specified in that document. after all, its how that standard is defined.....
and i agree that hid is of limited use when it comes to many sensors/actuators. the problem is that all the data is parsed (as defined in the descriptors) in the hid driver of the os once, and a second time inside/after the [hid] object.
greetings,
chris
I used the names from Linux's input.h. The event naming scheme is derived from Linux rather than USB because its much cleaner. I guess that makes it less than pure "HID" because the Linux input system is HID plus ADB, PS/2, serial mice, AT, etc.
The names in [hid] could probably use a revamp. I chose deliberately short names because I thought strcmp() was used to compare the strings, but since Matju pointed out that symbol comparison is done by the pointer, the length of the symbol name won't affect comparison speed. But if the names are too long, they'll take up a lot of screen space.
As for less parsing, one of these days, I'll get around to making the OS-specific versions of [hid] which will just dump the data straight out from the OS without any cross-platform concerns. That might help with the sensor setups.
.hc
On Jul 6, 2005, at 1:29 PM, Christian Klippel wrote:
hello all,
as for the recent discussion about the [hid] object, i just have uploaded two pdf documents to my site:
http://mamalala.de/Hut1_11.pdf - HID Usage Tables http://mamalala.de/HID1_11.pdf - HID Specs
of most interrest here are the usage tables, i think.
as you can see there, there is a number of choices how single number (event-type) is mapped to the hid-name. it all depends on the selected usage tables.
btw, i would say that it is a good idea to use the names as specified in that document. after all, its how that standard is defined.....
and i agree that hid is of limited use when it comes to many sensors/actuators. the problem is that all the data is parsed (as defined in the descriptors) in the hid driver of the os once, and a second time inside/after the [hid] object.
greetings,
chris
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
hello all,
Am Samstag 09 Juli 2005 16:24 schrieb Hans-Christoph Steiner: [...snip...]
As for less parsing, one of these days, I'll get around to making the OS-specific versions of [hid] which will just dump the data straight out from the OS without any cross-platform concerns. That might help with the sensor setups.
.hc
yes, but only the parsing inside the hid object .... inside the os, it is still parsed. for continous controllers that might not be a big problem, but when it comes to single bits, as for buttons and led's, things become more complicated, and thus cpu-intensive.
for modern computers that is no problem at all, but we should think about small, portable devices (like a pda) also.
maybe there is a way to grab the data packets from hid devices _before_ they get parsed by the os? but then, using libusb seems the better way.... and that is available for linux, os-x and windows so far ....
greets,
chris
On Jul 9, 2005, at 10:35 AM, Christian Klippel wrote:
hello all,
Am Samstag 09 Juli 2005 16:24 schrieb Hans-Christoph Steiner: [...snip...]
As for less parsing, one of these days, I'll get around to making the OS-specific versions of [hid] which will just dump the data straight out from the OS without any cross-platform concerns. That might help with the sensor setups.
.hc
yes, but only the parsing inside the hid object .... inside the os, it is still parsed. for continous controllers that might not be a big problem, but when it comes to single bits, as for buttons and led's, things become more complicated, and thus cpu-intensive.
for modern computers that is no problem at all, but we should think about small, portable devices (like a pda) also.
maybe there is a way to grab the data packets from hid devices _before_ they get parsed by the os? but then, using libusb seems the better way.... and that is available for linux, os-x and windows so far ....
I fully support this idea, I am relatively new to embedded systems, but I know enough to see the vast potential. [hid] is not the place to make this work though. It seems that libusb is. I think that the same structure as [hid] could be applied to libusb: low-level C object to access the raw data with abstractions for higher level interfaces, like a [multio] abstraction. But I don't think I need to tell you that, since you gave me that idea in the first place when I was writing [linuxevent], etc. :).
.hc
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."
-John Gilmore