getting my new graphic tablet cooperating with gimp

[Markus Brueffer]

Am Donnerstag, 14. Februar 2008 20:23:32 schrieb Chuck Robey:
> Markus Brueffer wrote:
> >> I appreciate the extra information.  In fact, I am having one heck of a
> >> time trying to figure out exactly how to parse this.  I am reading with
> >> the HID1_11 spec on my knee at all times, but I swear, I have never seen
> >> such a poorly written document!
> >
> > It's not _that_ bad, but it surely lacks several clarifications in some
> > areas and some information on specific topics is scattered across the
> > whole document.
>
> Maybe I'm not used to the style, but reading this reminds me of the first
> few times I plowed my way thru the sgml spec, before I finally realized
> those guys weren't trying to get anything done, they were trying only to
> lay a foundation for a foundation for a way to get things done.  Getting
> past that was difficult, and I find specific sections of the usbhid spec
> just as difficult.  There is little or no linkage between the sections that
> describe features, and the sections that demonstrate how to use those
> features.  As one example (which I think I've finally figured out), section
> 4.2 (Subclass), the subparagraph below that titled ""Subclass Codes" uses
> the term (in italics) of bInterfaceSubClass.  It describes one usagfe where
> it would be zero (0), but doesn't bother to say  what the other use would
> be, nor give any example of what context you'd want to use this statement.

There are currently only 2 types of subclasses for HID devices: no subclass 
(0) and boot interface subclass (1). Mice or keyboards e.g. can choose to 
implement 2 modes: boot mode and report mode. In boot mode, the data that the 
mouse returns is layed out in a specific way (described in appendix B), which 
is always the same, so there is no need to implement a full fledged HID 
report descriptor parser. This is especially usefull in very early boot 
stages like for the BIOS. When the system loads the operating system, the 
mouse gets switched into report mode and all features are available from that 
point.

For the meaning of an "Interface" you should have a look at the USB spec 
itself, expecially how usb devices are made up w.r.t. the different 
descriptors and what they mean.

> I've written specs myself, but never one that did such a great job of
> obfuscation.  I doubt, strongly, that any of you could do as badly (unless
> you were going thru perhaps 3 levels of language translation, that would do
> it).  Anyhow, that's the reason why I am not yet finished in figuring out
> the parsing of my own unit's config dump.
>
> > Best thing to get started is IMHO to get an idea about what reports are
> > and to get the raw report descriptor of a simple device (e.g. a mouse if
> > it's not from a keyboard/mouse combo) and start decoding it by hand. The
> > sources of the libusbhid parser might be of help as well, although it
> > contains several bugs and isn't spec compliant in several cases, but it
> > might get you an idea of what's going on. Furthermore playing with
> > usbhidctl might be of help.
> >
> > I have written a completly new fully spec compliant HID parser which is
> > soon ready for public consumption as part of a new libhid. It contains
> > many comments and should be easy to understand. The data representation
> > directly takes the tree-like structure of a decoded report descriptor
> > into account so that it's easy to write drivers that only handle one or
> > more specific application collections. Furthermore physical descriptors
> > are supported and the data handling functions hide the concept of report
> > IDs so that it's less error prone to develop HID drivers (ums(4) e.g.
> > doesn't support reports other than report 0 which is the reason that many
> > of todays mice don't work). The parser itself will hopefully replace our
> > current in-kernel HID parser.
>
> OK, couple more questions: would the state of your new libhid be far enough
> along that it might be possible for me to study it?  If it were, could I
> get a copy, if I agreed that you are giving me the copy for study only,
> that I'm not to release it anywhere myself?

Nope, not yet, as there are some parts still in flux. Additionally some 
documentation is still missing, especially documentation for the tree itself, 
that is being built by the parser. I'll send you a copy as soon as it's 
ready.

> Another thing, is there any  way, beyond my forcing the action in patched
> code, to get the uhid driver to claim my device?  I mean, some system
> configuration method to force this, like it used to be possible back a long
> time ago in the old usbd.conf?  I might be able to figure some things out,
> if I could experiment with usbhidctl, if I could use it thru uhid.

Not that I know of. But getting uhid(4) to recognize the device is actually 
quite easy. Please send me the output of udesc_dump (sysutils/udesc_dump in 
ports) for that device and I'll send you a patch.

> >> I am having a terrible time trying to figure out
> >> the actual scope of each statement, which refers to what.  I don't run
> >> any piece of Windows stuff here, so many of the pieces of demo software
> >> I have found on the web do me no good.
> >
> > I didn't find any windows software that really made it easier to
> > understand the spec. It's IMHO easier to directly get your hands dirty
> > and to read the code of an HID parser.
>
> You;'re going to tell me it's easier to read the code than read the spec,
> and in the same breath tell me that the spec isn't so badly written?

You should have a look at the code with the spec at hand of course.

> >> I'm not giving up, I keep on making new discoveries, but if anyone knows
> >> of a description of HID that involves some real use of English, I sure
> >> would appreciate a pointer to it.
> >
> > If you have any specific questions, please drop me a mail.
>
> Look, I'll be honest, I'm kinda embarrassed at the level questions I need
> answered, I'm probagbly not going to ask them here on the mail list.  If I
> were to start up a usbhid channel on freenode, anyone might come up there
> and answer questions?

Sure (actually I joined that channel on friday, but unfortunately you were 
afk).

Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20080217/0151cc12/attachment.pgp