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. ~_~
All troubles are come from between the generic driver and the specific
driver. Let me use
some words to explain both in my mind. First, the generic driver, for
instance, some
chipsets or some kinds of device driver, it let us use the common
feature of device. but may
be not complete, because of some devices may have some advanced
features, or more powerful
implementation. The other task of the generic driver is support API for
the specific
driver. Second, the specific driver, it base on the generic driver, use
the service that
is supplied by the generic driver, this let us some advanced feature
that the generic
driver can not support. Moreover, this architecture must not be two
layers: it can stack
into more layers. Use HID subsystem as one example, the hid-core can be
as the generic driver
for the hid-input, hid-input can be see as the specific driver that use
hid-core. The next layer,
The hid-input can be as the generic driver for usbnek4k.
And, I think the library module of design is not the best solution, The
library module, it can not
activate one kernel control path by itself, The most problem of this
design is it let some simple
device have rather complex driver. I think the generic driver frame of
design is good choice.
So, I think, the role of hid-input should support such interface for
other devices, not split out as one library module.
May be, I have some wrongs, please correct me, thanks.
PS:
I apologized for wrote last email too hurry to lost some words for
Vincent Legoll in the announcement.
Goodluck.
-Liyu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
