Date: Sun, 8 Jun 2008 21:32:50 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Chuck Robey <chuckr@telenix.org> Cc: markus@freebsd.org, FreeBSD USB List <FreeBSD-usb@freebsd.org> Subject: Re: final usb question Message-ID: <200806082132.51357.hselasky@c2i.net> In-Reply-To: <484BEE1C.8040903@telenix.org> References: <484BEE1C.8040903@telenix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Chuck, On Sunday 08 June 2008, Chuck Robey wrote: > 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! You mean if you can set another USB configuration ? > > 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. Have you looked into "hid_get_data()" and stepped through it? > > 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. I never used it. I probably will one day and it seems like there are some bugs that needs to be fixed according to you :-) > > 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 was "Markus Brueffer" I think. > > I really don't want to completely roll my own here, but so far, that's the > only path open to me. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200806082132.51357.hselasky>