Date: Sun, 17 Feb 2008 17:07:00 +0100 From: Markus Brueffer <markus@freebsd.org> To: Chuck Robey <chuckr@chuckr.org> Cc: freebsd-usb@freebsd.org Subject: Re: getting my new graphic tablet cooperating with gimp Message-ID: <200802171707.03988.markus@freebsd.org> In-Reply-To: <47B49534.3060207@chuckr.org> References: <47AE28EB.7070205@chuckr.org> <200802140506.52864.markus@FreeBSD.org> <47B49534.3060207@chuckr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2540010.3hL36d79Dl Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 se= en > >> 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 th= at > describe features, and the sections that demonstrate how to use those > features. As one example (which I think I've finally figured out), secti= on > 4.2 (Subclass), the subparagraph below that titled ""Subclass Codes" uses > the term (in italics) of bInterfaceSubClass. It describes one usagfe whe= re > 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= =20 (0) and boot interface subclass (1). Mice or keyboards e.g. can choose to=20 implement 2 modes: boot mode and report mode. In boot mode, the data that t= he=20 mouse returns is layed out in a specific way (described in appendix B), whi= ch=20 is always the same, so there is no need to implement a full fledged HID=20 report descriptor parser. This is especially usefull in very early boot=20 stages like for the BIOS. When the system loads the operating system, the=20 mouse gets switched into report mode and all features are available from th= at=20 point. =46or the meaning of an "Interface" you should have a look at the USB spec= =20 itself, expecially how usb devices are made up w.r.t. the different=20 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 ma= ny > > 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 enou= gh > 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=20 documentation is still missing, especially documentation for the tree itsel= f,=20 that is being built by the parser. I'll send you a copy as soon as it's=20 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 lo= ng > 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= =20 quite easy. Please send me the output of udesc_dump (sysutils/udesc_dump in= =20 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 kno= ws > >> 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= =20 afk). Markus --nextPart2540010.3hL36d79Dl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHuFun1I0Qcnj4qNQRAvZoAKCobw+pTHvXnBRlUnxohZW2OsYYMACg2VeU WBnZdmi6UU4+dqzOBfeJ2gs= =bFim -----END PGP SIGNATURE----- --nextPart2540010.3hL36d79Dl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802171707.03988.markus>