atom feed4 messages in org.freebsd.freebsd-usbUSB device probing
FromSent OnAttachments
Chuck RobeyJun 17, 2008 4:33 pm 
Hans Petter SelaskyJun 17, 2008 11:45 pm 
Chuck RobeyJun 18, 2008 12:53 am 
Hans Petter SelaskyJun 18, 2008 1:40 am 
Subject:USB device probing
From:Hans Petter Selasky (
Date:Jun 17, 2008 11:45:31 pm


Can you do a udesc_dump of your troublesome device ?


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.