From owner-freebsd-usb@FreeBSD.ORG Mon Jun 9 02:02:54 2008 Return-Path: Delivered-To: FreeBSD-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 903031065677 for ; Mon, 9 Jun 2008 02:02:54 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.freebsd.org (Postfix) with ESMTP id 693828FC20 for ; Mon, 9 Jun 2008 02:02:54 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 17055 invoked from network); 9 Jun 2008 02:02:53 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 9 Jun 2008 02:02:53 -0000 Message-ID: <484C8D2B.40404@telenix.org> Date: Sun, 08 Jun 2008 21:53:47 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: Hans Petter Selasky References: <484BEE1C.8040903@telenix.org> <200806082132.51357.hselasky@c2i.net> <484C46D6.6050908@telenix.org> <200806082310.56920.hselasky@c2i.net> In-Reply-To: <200806082310.56920.hselasky@c2i.net> X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: markus@freebsd.org, FreeBSD USB List Subject: Re: final usb question X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2008 02:02:54 -0000 -----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-----