Message-Id: <6E17845C-6F9F-4CB6-AA5D-DEEDCD2089E8@enac.fr>
Date:	Thu, 8 Mar 2012 12:21:51 +0100
From:	Stéphane Chatty <chatty@...c.fr>
To:	"Henrik Rydberg" <rydberg@...omail.se>
Cc:	Jiri Kosina <jkosina@...e.cz>,
	"benjamin.tissoires" <benjamin.tissoires@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] HID: autoload hid-multitouch as needed


Le 8 mars 2012 à 11:57, Henrik Rydberg a écrit :

> On Wed, Mar 07, 2012 at 10:36:41PM +0100, Jiri Kosina wrote:
>> On Tue, 6 Mar 2012, benjamin.tissoires wrote:
>> 
>>> From: Benjamin Tissoires <benjamin.tissoires@...c.fr>
>>> 
>>> The code is inspired from the one present in the bttv module.
>>> 
>>> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@...c.fr>
>>> ---
>>> 
>>> As I mentioned in the mail 0/5, I'd really like to have your opinion on this
>>> one. I copied the code from bttv, but it forces us to change hid_device which
>>> is not very good for ABI changes reasons.
>> 
>> Haven't closely inspected the patch yet, I will comment on it later. But 
>> generally, I wouldn't be worried about changing hid_device per se ... it's 
>> not really an ABI, it's not exported to userspace.
>> 
>> It's internal kernel-ABI, yes. But we are free to change that in any way 
>> we wish.
>> 
>> -- 
> 
> Thanks for having another go at this problem. Obviously, it is hard to
> find a completely satisfactory solution to auto-loading in the current
> hid framework. This latest attempt somehow comes close to the smallest
> hackery that makes it possible. If we want to go beyond that, I think
> we need to restructure more than the internal hid device
> representation.

Yes. I'm not sure it is what you have in mind, but my personal feeling is that the parsing of report descriptors could be restructured to make things clearer. It was designed with a simple HID-field-to-evdev-field mapping in mind, and multitouch breaks this.


> 
> 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.

> a single interface on a usb bus, a special class determined by examining
> the reports, etc. Yet, the hid modalias contains only bus type, vendor
> and product id. This is true for the generic usb and bluetooth drivers
> (and some very special drivers), but not really for the other devices.
> If we were to extend the modalias description, we could cater for a
> whole tree of hid devices. For instance, the usb id 1234 could be
> handled by the generic usb bus driver. The multitouch sub-device
> 1234:MT could be handled by hid-multitouch. The mouse device
> 1234:Mouse could be handled by some other driver, etc. All the driver
> handling could be automated in userland using the same udev mechanism
> we have today, if only the hid uevents were modified to incorporate
> the needed extra information.

No comments on this, I need to read up on modaliases before being able to comment at all. I have a vague feeling that we are going to end up debating where it is decided to assign a device to a driver (today it's done in the kernel, you seem to suggest userland), but I know too little about modaliases to be sure.


> 
> Would this be a problematic change in userland, or would it be a
> feasible, in principle?
> 
> Thanks,
> Henrik

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists