Date: Sun, 08 Jun 2008 10:35:08 -0400 From: Chuck Robey <chuckr@telenix.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: FreeBSD USB List <FreeBSD-usb@FreeBSD.org> Subject: final usb question Message-ID: <484BEE1C.8040903@telenix.org>
next in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans, this is the big question, requires more thought, so if you don't have enough time on hand, give this a skip for a while. I'm CC'ing this to the FreeBSD-USB list, it's conceivable that I might get lucky there, too. This replaces my last usb question, because (even though I think the answer to that one confirms the utter insanity of the people who wrote the USB-HID spec), I have absolute confirmation of the fact that I cannot, in situations where the report descriptor has multiple sections ID'd by multiple report IDs, force the USB peripheral to send me the report ID that makes the best sense, and I must be satisfied with whatever the device sends me. That's ridiculous, but I wrote down the reference, just so I could look back at it and confirm to myself that I wasn't dreaming any of this. As a better illustration of that, my tablet has report IDs 7, 8, and 9. ID# 7 is the only one that matches well, but the device manufacturer has set it up to respond ONLY with report ID# 9. If I _could_ change that, I surely would, and I spent a LOT of time investigating until I absolutely found hard confirmation of the fact that I can't. If you get lucky and have a mfr sending all of the report ID's, you then can toss out the ones you don't like, but if they only send one (as in my case), well, you're screwed. What a stupid spec! My question now regards parsing of the input data using FreeBSD-supplied functions (which seems to me to mean things in libusbhid). Even though I can get hid_get_item and then hid_locate() to work for me, it's only by ignoring incorrect return values. Past that, the final point would be to use hid_get_data() to select and scale the data (which I gather through a read() of a scanned-for device such as uhid0) EXCEPT that I cannot get anything but a integer zero to return to me. Darn hid_get_data() just doesn't work. I'm probably missing some code assumption that didn't get illustrated in the man page. The only example I can get for it (the kernel code) is in dev/usb/ums.c, using the code in sys/dev/usb/hid.c, BUT the proto for this kernel code just looks _really_ different than the proto for the libusbhid functions. Headers and declarations are set up to make it really evil to try to use the kernel code in the user-mode code. I'm possibly going to have to adapt the kernel code to see if it can be forced to run in usermode. Does the libusbhid stuff work? Is there any sort of example, anywhere? Or, should I copy and adapt the kernel code? I could do the 3rd item, but it also seems like a really bad way to go. What's the right path here? Am I being stupid in missing the obvious? There's even one other question ... I'd heard some while back that someone else was preparing a separate implementation of the hid code. Do you know of anything like that, anything I could maybe replace the libusbhid code with? I really don't want to completely roll my own here, but so far, that's the only path open to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIS+4cz62J6PPcoOkRAgSXAJ9FQ8H2HvTBx95S6w0eP2vqdfm5JwCfenrR wOa4RxEDdbmj6+kAGohLaf0= =8pCH -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?484BEE1C.8040903>