From: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
To: "Randy Dunlap" <rdunlap@xenotime.net>
Cc: "raise.sail" <raise.sail@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-usb-devel <linux-usb-devel@lists.sourceforge.net>,
greg <greg@kroah.com>
Subject: Re: [PATCH] usb/hid: The HID Simple Driver Interface 0.3.2 (core)
Date: Fri, 29 Sep 2006 13:35:56 -0400 [thread overview]
Message-ID: <d120d5000609291035q7dad5f7fqcb38d4d8b3b211e5@mail.gmail.com> (raw)
In-Reply-To: <20060929095913.f1b6f79d.rdunlap@xenotime.net>
On 9/29/06, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On Fri, 29 Sep 2006 16:24:15 +0800 raise.sail wrote:
>
> > Changelogs:
> >
> > 1. A bugfix for clear usage process.
> >
> > This driver requires:
> > 1. [PATCH] usb: HID Simple Driver Interface 0.3.1 (Kconfig and Makefile), this patch can be used without any change.
> >
> > PS: Who is the maintainer of the input subsystem today? Should I forward this mail to him/her?
>
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).
--
Dmitry
next prev parent reply other threads:[~2006-09-30 12:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-29 8:24 raise.sail
2006-09-29 16:59 ` Randy Dunlap
2006-09-29 17:35 ` Dmitry Torokhov [this message]
2006-10-08 3:07 ` raise.sail
2006-10-08 12:41 ` [linux-usb-devel] " Zephaniah E. Hull
2006-10-08 14:09 ` Dmitry Torokhov
2006-10-09 3:28 ` Liyu
2006-10-09 3:28 ` Liyu
2006-10-08 18:51 ` Anssi Hannula
2006-10-09 3:35 ` Liyu
2006-10-09 22:52 ` Anssi Hannula
2006-10-09 3:42 ` Dmitry Torokhov
2006-10-09 22:53 ` Anssi Hannula
2006-10-10 5:15 ` Dmitry Torokhov
2006-10-10 7:08 ` Liyu
-- strict thread matches above, loose matches on Subject: below --
2006-09-29 8:21 raise.sail
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d120d5000609291035q7dad5f7fqcb38d4d8b3b211e5@mail.gmail.com \
--to=dmitry.torokhov@gmail.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=raise.sail@gmail.com \
--cc=rdunlap@xenotime.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®