From owner-freebsd-usb@FreeBSD.ORG Sun Jun 8 19:31:24 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 448F0106564A; Sun, 8 Jun 2008 19:31:24 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 677DB8FC15; Sun, 8 Jun 2008 19:31:23 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=UlUzKLwsL7l1WSYqPADo3w==:17 a=sIWp1DIkpb0L2ECTMsIA:9 a=JC3dhOkaaBjt-6gSLAEA:7 a=ZS2F4cMFTkmgrsm7HRpPDvY_gk8A:4 a=50e4U0PicR4A:10 Received: from [62.113.132.30] (account mc467741@c2i.net [62.113.132.30] verified) by mailfe02.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 969191626; Sun, 08 Jun 2008 21:31:21 +0200 From: Hans Petter Selasky To: Chuck Robey Date: Sun, 8 Jun 2008 21:32:50 +0200 User-Agent: KMail/1.9.7 References: <484BEE1C.8040903@telenix.org> In-Reply-To: <484BEE1C.8040903@telenix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806082132.51357.hselasky@c2i.net> Cc: markus@freebsd.org, FreeBSD USB List Subject: Re: 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 19:31:24 -0000 Hi Chuck, On Sunday 08 June 2008, Chuck Robey wrote: > 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! You mean if you can set another USB configuration ? > > 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. Have you looked into "hid_get_data()" and stepped through it? > > 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. I never used it. I probably will one day and it seems like there are some bugs that needs to be fixed according to you :-) > > 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? That was "Markus Brueffer" I think. > > I really don't want to completely roll my own here, but so far, that's the > only path open to me. --HPS