final usb question

[Hans Petter Selasky]

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