final usb question

Markus Brueffer markus at
Mon Jun 9 12:36:55 UTC 2008

Am Sonntag, 8. Juni 2008 22:53:42 schrieb Chuck Robey:
> Hans Petter Selasky wrote:
> > 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 ?
> That's what I'm saying SHOULD be possible, but it isn't.  Why have report
> ID's if you can't use them?  That's why I say it's loony.    The general
> response I have had is, sometimes multiple reports are sent, but that's
> contradicted by most of the stuff I've read, so I disbelieve it... hid
> reports are limited to 8 bytes, so thinking that more than one report is to
> be sent sounds wrong.

They are not, see chapter 8.4 in the HID spec for constraints of reports.

> I was so incensed when I found the truth, I 
> memorized the page I read it in, so if you feel like checking me, do you
> have a copy of that pdf book
> USB_Complete_3rdEdition.pdf ??  If you don't, you really should, I could
> send you a copy, it's freely available on the net.  Anyhow, the stuff on
> page 363 is what I finally tripped over.  It took me quite a while to find
> it, and it says flatly that the transmitted report (if more than 1 is
> defined in the report descriptor) can't be changed.
> Mine always reports ID#9, and since my ID#7 is far better, I wanted that
> one, but I guess I can live with it.
> >> 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 :-)
> I don't trust myself, I do make silly errors.
> My test program is so completely screwed up because I have experimented
> rather freely, I would really be embarrassed to show it to you, but I can
> get nothing returned excepting a zero from hid_locate (although it DOES
> seem to work anyhow) and nothing except zero from hid_get_data(), but since
> that's where it's supposed to return data, it is more than a little
> upsetting.
> Beyond that (as I recently posted on the usb list) I have found what looks
> to me to be another oddity of libusbhid: there are some comments about the
> type of data (signed or unsigned) being uncertain, however, looking at the
> HID spec, top paragraph of page 38, the type of data is clearly delineated.
>  The libusbhid seems to have a bias toward signed, but all the data in my
> device is unsigned.

This is one of the numerous bugs in libusbhid which will be fixed by the new 
HID code I'm working on.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
Url :

More information about the freebsd-usb mailing list