Date: Mon, 9 Jun 2008 14:24:44 +0200 From: Markus Brueffer <markus@freebsd.org> To: freebsd-usb@freebsd.org Subject: Re: final usb question Message-ID: <200806091424.45235.markus@freebsd.org> In-Reply-To: <484C8D2B.40404@telenix.org> References: <484BEE1C.8040903@telenix.org> <200806082310.56920.hselasky@c2i.net> <484C8D2B.40404@telenix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1817618.jOfArEqI5v Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 wro= te > >>>> 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 se= nd > >>>> 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 ve= ry > 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= =2E=20 They just don't specify a report id which is a subtle, but important=20 difference. If a report id is specified (regardless if only one or more), t= he=20 report is prefixed by one byte which specifies the id. If no report id fiel= d=20 is in the report descriptor, the report is not prefixed with such a report = id=20 byte. > Other devices, which DO have=20 > 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=20 reports several reports in a single data report, unless it is horribly=20 broken. Maybe you mean something different here, if so, please stick to the= =20 nomenclature as defined in the HID spec. > The=20 > 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= =2E=20 > 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, s= o I=20 won't repeat it here. Markus --nextPart1817618.jOfArEqI5v Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEABECAAYFAkhNIQ0ACgkQ1I0Qcnj4qNTh3ACfeTwe7lbu//Eu0cPB2a9u/0Bv uJUAn3qGus9A29zFZ2ZAX5BLGsKa9Oo7 =re2F -----END PGP SIGNATURE----- --nextPart1817618.jOfArEqI5v--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200806091424.45235.markus>