Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Jun 2008 03:41:52 +0200
From:      Hans Petter Selasky <hselasky@c2i.net>
To:        Chuck Robey <chuckr@telenix.org>
Cc:        freebsd-usb@freebsd.org
Subject:   Re: USB device probing
Message-ID:  <200806180341.53623.hselasky@c2i.net>
In-Reply-To: <48585A0C.5010506@telenix.org>
References:  <4857E4D3.2090904@telenix.org> <200806180146.57555.hselasky@c2i.net> <48585A0C.5010506@telenix.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

See /usr/ports/sysutils/udesc_dump

You need to make your device show up like ugen.

--HPS

On Wednesday 18 June 2008, Chuck Robey wrote:
> 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"





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