From: Michael Tokarev <mjt@tls.msk.ru>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
linux-input <linux-input@vger.kernel.org>,
Jiri Slaby <jslaby@suse.cz>
Subject: Re: new modular hid?
Date: Wed, 14 Jan 2009 16:26:21 +0300 [thread overview]
Message-ID: <496DE7FD.8080406@msgid.tls.msk.ru> (raw)
In-Reply-To: <alpine.LNX.1.10.0901130958230.5377@jikos.suse.cz>
Jiri Kosina wrote:
> On Tue, 13 Jan 2009, Jiri Kosina wrote:
>
>>> I would agree with Michael here, it looks like we went a bit overboard
>>> with HID quirks. I think sensible solution would be to merge quirks into
>>> 3-4 files (one per device type) and maybe even compile keyboard quirks
>>> into hid core.
>> It might seem a too bit too much fine-grained right now, but my
>> longer-term plan was to have more sophisticated drivers also register
>> themselves to the HID bus, make use of the common parser, etc (Wacom comes
>> to mind, for example).
>> Having the quirks grouped together rather than nicely separate would then
>> bring us close to the previous total mess, when unrelated quirks were
>> glued together randomly in the spaghetti-code-way, which I really would
>> like to avoid as much as possible, it started to become unmaintainable.
>
> That being said, we of course need to think about the initrd issue brought
> up by Michael.
>
> Compiling everything into single driver back again in the end would of
> course be a solution, but I am afraid that it'd be quite difficult with
> the bus infrastructure in place.
I'm not sure I understand.
Let's take a look at my example, hid_bright. Without this module, my
keyboard does not work, even if usbhid&Co is loaded. But this module
does exactly two things:
hid_hw_start(hdev, HID_CONNECT_DEFAULT);
usbhid_set_leds(hdev);
(modulo error checking and the like). The leds (caps, scroll and num
locks) on this keyboard works without the last call (I just checked).
hid_hw_start() gets called from all other drivers too. So *to me*
it looks like this subdriver does exactly nothing useful. Yet
w/o it the (perfectly working before 2.6.28) keyboard does not
work.
Maybe, just maybe, it's possible to init stuff by default, and
get additional features or quirks later, when actually loading
the sub-driver? But any way, this "doing nothing" driver thing
seems to be wrong...
It's even more (to me): I don't understand the "hid bus" thing to
start with. How the autoload (with udev) works? I don't see any
modalias things in this module, `modinfo hid_bright' shows nothing
useful, and there are no useful modalias files in /sys/bus/hid/
either.
What mess was before the split? How it's different from the current
many-small-doing-nothing things?
Thanks!
/mjt
next prev parent reply other threads:[~2009-01-14 13:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-12 20:05 new modular hid? Michael Tokarev
2009-01-12 23:54 ` Jiri Kosina
2009-01-13 5:43 ` Dmitry Torokhov
2009-01-13 8:50 ` Jiri Kosina
2009-01-13 9:00 ` Jiri Kosina
2009-01-13 9:08 ` Dmitry Torokhov
2009-01-14 13:26 ` Michael Tokarev [this message]
2009-01-14 13:39 ` Jiri Kosina
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=496DE7FD.8080406@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=dmitry.torokhov@gmail.com \
--cc=jkosina@suse.cz \
--cc=jslaby@suse.cz \
--cc=linux-input@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).