Am Montag, 9. Juni 2008 03:53:47 schrieb Chuck Robey: > Hans Petter Selasky wrote: > > On Sunday 08 June 2008, Chuck Robey wrote: > >> 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. > > > > There will soon be a utility that can do this, so that you can run: > > > > usbconfig -u ugen0 -c 1 > > > > for example to select configuration index 1 for your device. Please note > > that there will be one ugen device for every USB device present in the > > future! And I'm in the future :-) > > Most likely possibility: you (like one other person already) is > misinterpreting what I'm talking about. Being that I tend to be a bit > loose about terminology sometimes (and sometimes too often) it's likely my > fault. Just to see if I can run over what the other person meant, I'm very > much NOT talking about the thing that the USB HID spec calls a "report > type", one example being the input type, or feature, etc. I am talking > about a subset of HID report descriptors that are written with multiple > "report ID" fields (see HID spec page 36), like the one with my UC-Logic > graphic tablet, which is written with report IDs 7, 8, and 9. Most HID > devices (and only HID devices have these report descriptors anyhow) have > only a single report ID, and so they don't actually have the explicit > report ID line (they let it default to zero).
Actually they don't let it default to 0 as 0 is not allowed for a report ID. They just don't specify a report id which is a subtle, but important difference. If a report id is specified (regardless if only one or more), the report is prefixed by one byte which specifies the id. If no report id field is in the report descriptor, the report is not prefixed with such a report id byte. > Other devices, which DO have > multiple report ID's, have small enough reports to have multiple reports > fit in a single data report (those are limited by spec to 8 bytes). It is not limited by 8 bytes (see my other mail). Furthermore, no device reports several reports in a single data report, unless it is horribly broken. Maybe you mean something different here, if so, please stick to the nomenclature as defined in the HID spec. > The > report ID, for ones with multiple ID's, forms the first byte of the data > report. My tablet reports 0x09 as the first byte, I wish it would report a > 0x07. The reference I gave you is unmistably clear in saying that it is > not possible to cause a device to change the report ID's it sends. My > device needs 7 data bytes, 8 with the leading report ID, which is VERY > unfortunately an 0x09, not the 0x07 which would really be optimal. > > Another possibility occurs, though: my reference, the USB Complete book, > page 363, is just plain wrong. That possibility is what fuels this email. > Maybe there IS a way ... God knows, the USB HID spec is such an incredible > POS that getting it wrong can't even be blamed on an otherwise very good > programmer. I have read many specs in my life, never seen one even close > to being as bad as that one (although I admit most of the specs I have > dealt with were communications oriented, I was mostly a commuications > engr.) > > If you have any reference to any method which might exist to send any data > pattern at all to a USB HID device, to cause it to change the report ID > coding (scaling, etc) that it follows, I sure would appreciate you telling > me that. Don't even need to tell me how, I will read myself (although I > would like that, I am so desperate to get such, I would really appreciate > it in any form I could get it, whatsoever). I have commented on this in detail already in private mail some time ago, so I won't repeat it here. Markus
signature.asc
Description: This is a digitally signed message part.
