On Thu, 29 Mar 2007, Li Yu wrote: > The last word is a question, what's the future of hiddev? It will merge > into hidraw later? I think so, but can't sure.
Hi Li, no, it won't, it doesn't provide compatible interface for purpose. hiddev has currently the following drawbacks: - USB-transport specific - uses in-kernel HID parser to parse reports and fill in usages and values. This is usually not what authors of the userspace drivers for HID devices want - the devices often have quirks or behave in a strange way, and making workarounds is more complicated when kernel parser operates on the received reports - only a few applications use it (acupsd, nut, hid2hcianything else?). All other drivers rather use libhid, which is built on top of libusb, in order to be able to receive and send really raw HID reports, and parse them on their own. This is however also USB-transport specific The purpose of hidraw is to provide the applications the same functionality they are having when using libhid/libusb, but in a transport-independent way, as it is hooked to generic HID layer, which works as a 'proxy' for different transports that use it. -- 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
