Message-ID: <20061008124146.GA4710@aehallh.com>
Date:	Sun, 8 Oct 2006 08:41:46 -0400
From:	"Zephaniah E. Hull" <warp@...allh.com>
To:	"raise.sail@...il.com" <raise.sail@...il.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>, greg <greg@...ah.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-usb-devel <linux-usb-devel@...ts.sourceforge.net>
Subject: Re: [linux-usb-devel] [PATCH] usb/hid: The HID Simple Driver Interface 0.3.2 (core)

On Sun, Oct 08, 2006 at 11:07:49AM +0800, raise.sail@...il.com wrote:
> Dmitry Torokhov wrote:
> > I re-read these patches again and the main problem with the current
> > implementation is that it alters input devices's properties after
> > device has been registered and presented to userspace. That means that
> > hotplug users that presently can inspect device's capabilities and
> > decide if they are "interested" in device will not be able to do so
> > anymore. For example I think X event interface drivers examine input
> > devices and decide if it should be handled by as keyboard or pointing
> > device so it is possible for them to not notice that touchpad
> > capabilities were added to a keyboard later. For now the only thing
> > that is allowed to change after device has been registered is keymap.
> >
> > Then there is issue with automatic loading of these sub-drivers. How
> > do they get loaded? Or we force everything to be built-in making HID
> > module very fat (like psmouse got pretty fat, but with HID prtential
> > for it to get very fat is much bigger).
> >
> > The better way would be to split hid-input into a library module that
> > parses hid usages and reports and is shared between device-specific
> > modules that are "real" drivers (usb-drivers, not hid-sub-drivers).
> >

> I am sorry this reply so late, because of I had holiday for the National
> Day.
> 
> Well, however, I don't think this is problem. ~_~

I'm afraid that it really is a problem.

Existing user space, some of which I have written myself, is going to
respond very poorly to being told that an input device does X and Y, and
then abruptly having the device start doing Z on us.  No matter it's a
new few buttons, a new few keys, or a touch-pad added to the keyboard,
it's just not going to be happy, and it is most definitely not going to
actually support the new events.

This is a real killer.  You can remove the input device and reregister
it with new capabilities[0], you can wait to register until you know them
all, but you can't change those of an existing device without breaking
userspace.

0: If you keep all the ID identical, userspace may have the capabilities
cached.  This may also cause problems, but if Dmitry or Greg calls that
a userspace bug I'll believe them and find a workaround.  But existing
user space _may_ break in roughly the same ways as if you just change
capabilities on an existing input device, that said, remove and readd
would be greatly preferred just because it does give us a chance to see
that something changed.


Zephaniah E. Hull.
xf86-input-evdev maintainer.


-- 
	  1024D/E65A7801 Zephaniah E. Hull <warp@...allh.com>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

I could imagine that there might be some GPL project out there that
_deserves_ getting sued(*) and it has nothing to do with Linux.

                Linus

(*) "GNU Emacs, the defendent, did inefariously conspire to play
towers-of-hanoy, while under the guise of a harmless editor".

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)

Powered by blists - more mailing lists