final usb question

Sun Jun 8 21:02:50 UTC 2008

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.  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.

Last item is that using hid_locate to grab the hid_item_t for each item, and so
I looked at the "pos" field which is supposed to return the bit offset of the
data.  In using pure inspection, I have determined that the first byte has 3
bits in the bottom given to buttons, the rest there are fillers, then the
following 3 byte pairs (shorts) are each X, Y, and tip pressure.  This doesn't
agree with the stuff returned in the pos field, so I can't even cheat and read
the data, and use it myself...

What I think I can, must do, is to use the libusbhid to parse the report
descriptor, and use that data directly to derive my own bit offsets, and use my
own functions to parse out and scale the data.  I would rather use the stuff in
libusbhid, but I can't get anywhere with it.

That's unless I can get someone to clue me in.  You say Markus Brueffer is
writing another libusbhid?   Hmm, ok, I appreciate your CC'ing him.... or, I
really suspect I've bothered, overly bothered, enough folks at this point, and
maybe what I need to write at this point is small enough so that I could just
figure it out myself.  It won't look TOO ugly now that I have the real problem,
tha parsing, really taken care of.

Anyhow, if you don't really have any experience with libusbhid, or maybe could
tell me I'm wrong about being able to set the report ID, then I really guess I
have to be happy with where I'm at.  Thanks for listening to me.

> 
>> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFITEbWz62J6PPcoOkRAgXgAJsHrYdP6Pxr6qei9cvHmgg6dCysdACgpHBz
92MwqpKRQl4ge3rwi0GaTcQ=
=XiZQ
-----END PGP SIGNATURE-----