Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 08 Jun 2008 21:53:47 -0400
From:      Chuck Robey <chuckr@telenix.org>
To:        Hans Petter Selasky <hselasky@c2i.net>
Cc:        markus@freebsd.org, FreeBSD USB List <FreeBSD-usb@freebsd.org>
Subject:   Re: final usb question
Message-ID:  <484C8D2B.40404@telenix.org>
In-Reply-To: <200806082310.56920.hselasky@c2i.net>
References:  <484BEE1C.8040903@telenix.org> <200806082132.51357.hselasky@c2i.net> <484C46D6.6050908@telenix.org> <200806082310.56920.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

> 
> --HPS
> 
> 

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

iD8DBQFITI0rz62J6PPcoOkRAoK6AKCPJJX0SJWjS/5grGbPSYg6tCBqZACfR5wY
8XasXa0B86VIMP4A/rBjR7A=
=0CBd
-----END PGP SIGNATURE-----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?484C8D2B.40404>