From owner-freebsd-usb@FreeBSD.ORG Wed Jun 18 00:53:36 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 C5F54106566B for ; Wed, 18 Jun 2008 00:53:36 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9F2348FC18 for ; Wed, 18 Jun 2008 00:53:36 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 5998 invoked from network); 18 Jun 2008 00:53:35 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 18 Jun 2008 00:53:35 -0000 Message-ID: <48585A0C.5010506@telenix.org> Date: Tue, 17 Jun 2008 20:42:52 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: Hans Petter Selasky References: <4857E4D3.2090904@telenix.org> <200806180146.57555.hselasky@c2i.net> In-Reply-To: <200806180146.57555.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: freebsd-usb@freebsd.org Subject: Re: USB device probing 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: Wed, 18 Jun 2008 00:53:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans Petter Selasky wrote: > Hi, > > Can you do a udesc_dump of your troublesome device ? This may sound stupid, but I don't know what a udesc_dump is. Do you mean, dump the full report descriptor? If so, I have that in both hex and also somewhat translated, via Kai's krepdump (or my own dumper). I don't have to use krepdump anymore, I know 2 other methods to do it now, so tell me if you meant the report desctiptor or not. Beyond that, I have figured out a useable method for getting around that problem of when I can detect which section of the report descriptor is being used (what report ID is in the first byte of each data report). I can just decide, at the beginning of every data gathering loop, to dump every single report ID being used in the report descriptor, and select the final one. Then, later on, when I'm getting every report, I can easily add a quick test of the first byte (the report ID) against the one I'm using. If they differ, I reparse the report descriptor again, now using the ID I received, and rebuild all my data field callouts, then start to report the data again. As long as the report ID is even minimally stable (and it only sends one report, which mine does) then I'll be fine this way. I can still do init stuff only at init time, which I need to do for my Xinput module. Correct me if I am wrong (and the USB-Complete book on page 363 agrees with me) that I have no way to require a particular report ID to come out to me. I'm supposed to expect the vendor to send me one report for each included report ID, and then I just pick and choose the one I like. Sure would be nice if that really happened. More and more, I'm getting the idea that a lot of HID devices are programmed horribly. Course, I haven't seen all that many yet. I just really dislike that USB HID spec, it's nowhere near as good as any other spec I've ever read. > > --HPS > > On Tuesday 17 June 2008, Chuck Robey wrote: >> OK, this won't slow me up, but at some point before I finish, I need an >> answer to this question. I've written a USB test program, to prove to >> myself that I have a firm handle on all of the required USB functions for >> my graphic tablet Xorg Xinput driver. It ahs a single problem: my graphic >> tablet, and (it seems) all of the many tablets that are OEM copies of mine >> (the UC-Logic family of tablets), their report descriptors all have >> multiple report ID's defined in their report descriptor. They are, >> however, only sending a single report, and it's neither the first, nor the >> most logical report ID for them to have decided upon. >> >> The way I tell right now which one they're sending is because the first 8 >> bits of each input report is always set to the report ID. My problem is, I >> don't get any input, if the user has just booted the machine, and hasn't >> moved the stylus around on the tablet yet. There's nothing in the input >> buffer yet. I don't think I can hang the input driver, waiting upon the >> first user input, because that stuff is all done in the preInit phase, and >> needs to be reported and set up for later parsing. >> >> Anybody know of any way to sort of goose the tablet, to FORCE an input >> report? I don't care a whit about the rest of the fields at this point, >> it's prior even to my reading of the report descriptor, so I'm not parsing >> the input yet, just trying to probe out the report ID. >> >> I'd feel really amateurish if I needed just to set a WAG for the report ID. >> Hell, I don't even know the universe the report IDs can be set from yet. I >> need that first input report. >> _______________________________________________ >> freebsd-usb@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-usb >> To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIWFoMz62J6PPcoOkRAq1wAJ4yJCRVR0f/8ETTH7N1rHOzft/pUwCdGWgr OFWTpR0H8jct6j908QasbDk= =7Hjx -----END PGP SIGNATURE-----