On Mon, 12 Mar 2012, Stéphane Chatty wrote: > Just in case it makes a difference, I knew nothing about HIDP when I > wrote the message above. My point was rather that hid looks like a bus > to which several transport layers can connect (USB, Bluetooth, ZigBee, > etc), and that having USB-specific code in hid/ (as opposed to having it > in usb/) seems biased towards USB. I was (and am still) wondering how > much it limits future uses of the hid core by making it USB-dependent. > > In other words: is the hid core generic enough or are there steps to > take to make it more generic wrt transport layers? If we are talking > about restructuring parts of it, this seems like the right time to ask > :-) Let me answer by a bit of history here. Originally, there have been two copies of HID code in the kernel -- one for USB HID devices, one for Bluetooth HID devices. The parsers were not kept in sync, and there was a lot of code duplication, creating quite some mess. What I did back then in 2006 was that I have extracted the abstract HID parts into HID core, and made it transport-independent in principle, so that both USB HID and Bluetooth HID shared the common infrastructure, while implementing different transport protocols. Then we extended it a little bit further, making HID core a proper bus, to which individual drivers (independently on underlying transport protocol used) can register. Currently there are just Bluetooth (hidp) and USB (usbhid) transport implementations, with HID core being transport independent. Hope this helps, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
