final usb question

[Markus Brueffer]

Am Sonntag, 8. Juni 2008 16:35:08 schrieb Chuck Robey:
> 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!

Just because you don't understand the reasoning behind this part of the spec, 
it doesn't make it ridiculous automatically, so please stop bashing the spec 
as it doesn't help in any way.

In your case the report IDs directly correspond to 3 different top level 
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 
instead of requireing a special driver for the whole device or interface. 
This isn't supported by our HID code, yet, but it will be (I'm working on 
that part).

If your tablet only uses report ID 9 regardless of what device (pen or mouse) 
you use on it, this is certainly the vendor's fault but not the fault of the 
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  
examples on how to use libusbhid functions. hid_get_data() is being used 
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 kernel
> 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, the 
same than the counterparts in libusbhid.

> 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.
>
> 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
-------------- 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 : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20080609/623cded2/attachment.pgp