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. Markus
signature.asc
Description: This is a digitally signed message part.
