Date: Mon, 9 Jun 2008 14:24:17 +0200 From: Markus Brueffer <markus@FreeBSD.org> To: freebsd-usb@freebsd.org Subject: Re: final usb question Message-ID: <200806091424.23154.markus@FreeBSD.org> In-Reply-To: <484BEE1C.8040903@telenix.org> References: <484BEE1C.8040903@telenix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1391206.TanApH1FDV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 8. Juni 2008 16:35:08 schrieb Chuck Robey: > This replaces my last usb question, because (even though I think the answ= er > to that one confirms the utter insanity of the people who wrote the USB-H= ID > 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 th= at > 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.=20 > 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! Just because you don't understand the reasoning behind this part of the spe= c,=20 it doesn't make it ridiculous automatically, so please stop bashing the spe= c=20 as it doesn't help in any way. In your case the report IDs directly correspond to 3 different top level=20 application collections: ID 7: Digitizer Pen ID 8: Mouse (relative coordinates) ID 9: Mouse (absolute coordinates) This way, each application collection can be handled by a generic driver=20 instead of requireing a special driver for the whole device or interface.=20 This isn't supported by our HID code, yet, but it will be (I'm working on=20 that part). If your tablet only uses report ID 9 regardless of what device (pen or mous= e)=20 you use on it, this is certainly the vendor's fault but not the fault of th= e=20 HID 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. As I told you before in private mail, see the source of usbhidctl(1) for =20 examples on how to use libusbhid functions. hid_get_data() is being used=20 there as well. > 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 kern= el > code to see if it can be forced to run in usermode. The kernel has its own HID functions which are mostly, but not entirely, th= e=20 same than the counterparts in libusbhid. > Does the libusbhid stuff work? Is there any sort of example, anywhere?=20 > 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? That would be me. Markus --nextPart1391206.TanApH1FDV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEABECAAYFAkhNIPcACgkQ1I0Qcnj4qNQccQCgqFqFIME++IP6IjWiJsABwmb+ +IYAn0wqFifeWnC0X7HPZePfGqsPlcBa =8bex -----END PGP SIGNATURE----- --nextPart1391206.TanApH1FDV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200806091424.23154.markus>