Re: [PATCH 4/5] HID: autoload hid-multitouch as needed

[Jiri Kosina]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/