From owner-freebsd-usb@FreeBSD.ORG Sun Jun 8 14:44:17 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 C21A8106564A for ; Sun, 8 Jun 2008 14:44:17 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.9]) by mx1.freebsd.org (Postfix) with ESMTP id 98DD98FC0A for ; Sun, 8 Jun 2008 14:44:17 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 24355 invoked from network); 8 Jun 2008 14:44:17 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 8 Jun 2008 14:44:17 -0000 Message-ID: <484BEE1C.8040903@telenix.org> Date: Sun, 08 Jun 2008 10:35:08 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: Hans Petter Selasky 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 List Subject: final usb question 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: Sun, 08 Jun 2008 14:44:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans, this is the big question, requires more thought, so if you don't have enough time on hand, give this a skip for a while. I'm CC'ing this to the FreeBSD-USB list, it's conceivable that I might get lucky there, too. This replaces my last usb question, because (even though I think the answer to that one confirms the utter insanity of the people who wrote the USB-HID spec), I have absolute confirmation of the fact that I cannot, in situations where the report descriptor has multiple sections ID'd by multiple report IDs, force the USB peripheral to send me the report ID that makes the best sense, and I must be satisfied with whatever the device sends me. That's ridiculous, but I wrote down the reference, just so I could look back at it and confirm to myself that I wasn't dreaming any of this. As a better illustration of that, my tablet has report IDs 7, 8, and 9. ID# 7 is the only one that matches well, but the device manufacturer has set it up to respond ONLY with report ID# 9. If I _could_ change that, I surely would, and I spent a LOT of time investigating until I absolutely found hard confirmation of the fact that I can't. If you get lucky and have a mfr sending all of the report ID's, you then can toss out the ones you don't like, but if they only send one (as in my case), well, you're screwed. What a stupid spec! My question now regards parsing of the input data using FreeBSD-supplied functions (which seems to me to mean things in libusbhid). Even though I can get hid_get_item and then hid_locate() to work for me, it's only by ignoring incorrect return values. Past that, the final point would be to use hid_get_data() to select and scale the data (which I gather through a read() of a scanned-for device such as uhid0) EXCEPT that I cannot get anything but a integer zero to return to me. Darn hid_get_data() just doesn't work. I'm probably missing some code assumption that didn't get illustrated in the man page. The only example I can get for it (the kernel code) is in dev/usb/ums.c, using the code in sys/dev/usb/hid.c, BUT the proto for this kernel code just looks _really_ different than the proto for the libusbhid functions. Headers and declarations are set up to make it really evil to try to use the kernel code in the user-mode code. I'm possibly going to have to adapt the kernel code to see if it can be forced to run in usermode. Does the libusbhid stuff work? Is there any sort of example, anywhere? Or, should I copy and adapt the kernel code? I could do the 3rd item, but it also seems like a really bad way to go. What's the right path here? Am I being stupid in missing the obvious? There's even one other question ... I'd heard some while back that someone else was preparing a separate implementation of the hid code. Do you know of anything like that, anything I could maybe replace the libusbhid code with? I really don't want to completely roll my own here, but so far, that's the only path open to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIS+4cz62J6PPcoOkRAgSXAJ9FQ8H2HvTBx95S6w0eP2vqdfm5JwCfenrR wOa4RxEDdbmj6+kAGohLaf0= =8pCH -----END PGP SIGNATURE-----