On Wed, 28 Mar 2007, Li Yu wrote: > I also sense this. we may need not such a complete layer at all. > Although the work of hiddev/rawdev support does not begin, however, as > the design, especially, let hiddev/rawdev live in HIDAL, I think this > may need a bit of abstract of transport layer.
JFYI the preliminary version of the hidraw interface is now in the hid/usbhid git tree, and has also been in a few recent -mm kernels already. > In current development implementation, the match process still can work > in traditional Vendor ID/Product ID way, but it do not reject other > means. If the author of driver hope to match for specific HID report, > just do it. In fact, the HIDAL only know the result of match process, > not how to do it. The crucial thing here is that all reports but the ones that the driver registered to will be processed in a standard way by the generic hid bus layer, and those reports that the driver registered to will be ignored by the layer, and passed for processing to the driver. > Er, What's mean of your "HUT", HID Usage Table? if so, I think I have > already explained we can do it.However, we should supply some convenient > API for this work. or HIT is other mysterious thing? ;) Yes, HUT is Hid Usage Table. You can obtain them from http://www.usb.org/developers/hidpage/#Usage_Tables Thanks, -- Jiri Kosina ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
