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

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

[Jiri Kosina]

On Thu, 8 Mar 2012, Stéphane Chatty wrote:

> > What if we were to change the definition of a HID device on the
> > modalias level?
> > 
> > In practise, a HID device can be either an usb device, a hid device,
> 
> Just to be sure: do you mean "bluetooth device"? or is there such a 
> thing as a hid device per se? I'm asking because I've always been 
> surprised at seeing usbhid/ in hid/, which kind of breaks the potential 
> symmetry between USB and Bluetooth wrt hid.

Please don't get confused by the directory layout ... this has mostly 
non-technical reasons -- Marcel wanted to keep bluetooth/hidp under his 
wings, and I didn't have reasons to object strongly.

I am adding Marcel and Gustavo to CC just in case they have changed their 
mind, but it's definitely a side-topic in this discussion.
Marcel, Gustavo -- if you are interested in the whole discussion regarding 
potential extension of HID core infrastructure to better suit multitouch, 
please see the whole thread at http://marc.info/?t=133105322800006&r=1&w=4

-- 
Jiri Kosina
SUSE Labs

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

[Marcel Holtmann]

Hi Jiri,

> > > What if we were to change the definition of a HID device on the
> > > modalias level?
> > > 
> > > In practise, a HID device can be either an usb device, a hid device,
> > 
> > Just to be sure: do you mean "bluetooth device"? or is there such a 
> > thing as a hid device per se? I'm asking because I've always been 
> > surprised at seeing usbhid/ in hid/, which kind of breaks the potential 
> > symmetry between USB and Bluetooth wrt hid.
> 
> Please don't get confused by the directory layout ... this has mostly 
> non-technical reasons -- Marcel wanted to keep bluetooth/hidp under his 
> wings, and I didn't have reasons to object strongly.
> 
> I am adding Marcel and Gustavo to CC just in case they have changed their 
> mind, but it's definitely a side-topic in this discussion.

I have not changed my mind. HIDP is Bluetooth specific and should stay
there. Especially since we are currently discussing changes to make
things also work over Bluetooth Low Energy (LE), but that is a complete
different topic and it just started.

> Marcel, Gustavo -- if you are interested in the whole discussion regarding 
> potential extension of HID core infrastructure to better suit multitouch, 
> please see the whole thread at http://marc.info/?t=133105322800006&r=1&w=4

HIDP is just a transport driver in the end. And I heard that the Apple
Magic Trackpad actually does work nicely. Never tried it by myself.

Regards

Marcel

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

[Stéphane Chatty]

Hi Marcel and Jiri

> Hi Jiri,
>=20
>>>> What if we were to change the definition of a HID device on the
>>>> modalias level?
>>>>=20
>>>> In practise, a HID device can be either an usb device, a hid =
device,
>>>=20
>>> Just to be sure: do you mean "bluetooth device"? or is there such a=20=

>>> thing as a hid device per se? I'm asking because I've always been=20
>>> surprised at seeing usbhid/ in hid/, which kind of breaks the =
potential=20
>>> symmetry between USB and Bluetooth wrt hid.
>>=20
>> Please don't get confused by the directory layout ... this has mostly=20=

>> non-technical reasons -- Marcel wanted to keep bluetooth/hidp under =
his=20
>> wings, and I didn't have reasons to object strongly.
>>=20
>> I am adding Marcel and Gustavo to CC just in case they have changed =
their=20
>> mind, but it's definitely a side-topic in this discussion.
>=20
> I have not changed my mind. HIDP is Bluetooth specific and should stay
> there. Especially since we are currently discussing changes to make
> things also work over Bluetooth Low Energy (LE), but that is a =
complete
> different topic and it just started.

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 =
:-)

Cheers,

St.

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

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

[Stéphane Chatty]

Le 12 mars 2012 =E0 23:21, Jiri Kosina a =E9crit :

> On Mon, 12 Mar 2012, St=E9phane Chatty wrote:
>=20
>> Just in case it makes a difference, I knew nothing about HIDP when I=20=

>> wrote the message above. My point was rather that hid looks like a =
bus=20
>> to which several transport layers can connect (USB, Bluetooth, =
ZigBee,=20
>> etc), and that having USB-specific code in hid/ (as opposed to having =
it=20
>> in usb/) seems biased towards USB. I was (and am still) wondering how=20=

>> much it limits future uses of the hid core by making it =
USB-dependent.
>>=20
>> In other words: is the hid core generic enough or are there steps to=20=

>> take to make it more generic wrt transport layers? If we are talking=20=

>> about restructuring parts of it, this seems like the right time to =
ask=20
>> :-)
>=20
> Let me answer by a bit of history here. Originally, there have been =
two=20
> copies of HID code in the kernel -- one for USB HID devices, one for=20=

> Bluetooth HID devices.
> The parsers were not kept in sync, and there was a lot of code=20
> duplication, creating quite some mess.
>=20
> What I did back then in 2006 was that I have extracted the abstract =
HID=20
> parts into HID core, and made it transport-independent in principle, =
so=20
> that both USB HID and Bluetooth HID shared the common infrastructure,=20=

> while implementing different transport protocols.
>=20
> Then we extended it a little bit further, making HID core a proper =
bus, to=20
> which individual drivers (independently on underlying transport =
protocol=20
> used) can register.
>=20
> Currently there are just Bluetooth (hidp) and USB (usbhid) transport=20=

> implementations, with HID core being transport independent.
>=20
> Hope this helps,

Very useful clarification, thanks. Now, I guess I understand why Marcel =
wants to keep hidp in bluetooth/. And, to be honest, things would have =
been clearer to me when I explored the handling of the USB/HID class if =
I had found a hid (or usbhid) directory in usb/ rather than a usbhid =
subdirectory in hid/: it did not make the above situation very obvious =
to me. Don't you think we could go along with Marcel and move usbhid to =
usb/?

St.

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

[Jiri Kosina]

On Tue, 13 Mar 2012, Stéphane Chatty wrote:

> > 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,
> 
> Very useful clarification, thanks. Now, I guess I understand why Marcel 
> wants to keep hidp in bluetooth/. And, to be honest, things would have 
> been clearer to me when I explored the handling of the USB/HID class if 
> I had found a hid (or usbhid) directory in usb/ rather than a usbhid 
> subdirectory in hid/: it did not make the above situation very obvious 
> to me. Don't you think we could go along with Marcel and move usbhid to 
> usb/?

It seemed to be convenient back then, and it's still convenient for me in 
some sense, as I am maintaining both HID core and USB HID, but bluetooth 
guys are maintaining the bluetooth transport.

But I don't have strong opinion either way, I can as well move usbhid to 
drivers/usb and maintain it there (will need to talk to Greg about it 
first of course). But frankly, I don't see it making things magically 
clear for everyone :)

-- 
Jiri Kosina
SUSE Labs

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

[Stéphane Chatty]

Le 13 mars 2012 =E0 17:13, Jiri Kosina wrote:

> On Tue, 13 Mar 2012, St=E9phane Chatty wrote:
>>=20
>> Very useful clarification, thanks. Now, I guess I understand why =
Marcel=20
>> wants to keep hidp in bluetooth/. And, to be honest, things would =
have=20
>> been clearer to me when I explored the handling of the USB/HID class =
if=20
>> I had found a hid (or usbhid) directory in usb/ rather than a usbhid=20=

>> subdirectory in hid/: it did not make the above situation very =
obvious=20
>> to me. Don't you think we could go along with Marcel and move usbhid =
to=20
>> usb/?
>=20
> It seemed to be convenient back then, and it's still convenient for me =
in=20
> some sense, as I am maintaining both HID core and USB HID, but =
bluetooth=20
> guys are maintaining the bluetooth transport.
>=20
> But I don't have strong opinion either way, I can as well move usbhid =
to=20
> drivers/usb and maintain it there (will need to talk to Greg about it=20=

> first of course). But frankly, I don't see it making things magically=20=

> clear for everyone :)


I agree it's neither very important nor a magic bullet. But this =
confused at least one person (me) when exploring the code for the first =
time :-)

St.