On Sun, Oct 08, 2006 at 11:07:49AM +0800, [email protected] 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 <[email protected]> 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".
Attachment:
signature.asc
Description: Digital signature
- Follow-Ups:
- Re: [linux-usb-devel] [PATCH] usb/hid: The HID Simple Driver Interface 0.3.2 (core)
- From: Dmitry Torokhov <[email protected]>
- Re: [linux-usb-devel] [PATCH] usb/hid: The HID Simple Driver Interface 0.3.2 (core)
- References:
- Prev by Date: [PATCH] md: use BUILD_BUG_ON
- Next by Date: Re: Unable to find root fs with libata only 2.6.18-mm3
- Previous by thread: Re: [PATCH] usb/hid: The HID Simple Driver Interface 0.3.2 (core)
- Next by thread: Re: [linux-usb-devel] [PATCH] usb/hid: The HID Simple Driver Interface 0.3.2 (core)
- Index(es):