From: Jonathan Conder <jonno.conder@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>, Linux Input <linux-input@vger.kernel.org>
Subject: Re: HID: Allow changing not-yet-mapped usages
Date: Wed, 15 Sep 2010 18:51:11 +1200 [thread overview]
Message-ID: <4C906CDF.6030700@gmail.com> (raw)
In-Reply-To: <20100915045822.GA21672@core.coreip.homeip.net>
On 15/09/10 16:58, Dmitry Torokhov wrote:
> Jiri,
>
> Currently HID only allows re-mapping of usages that have already been
> mapped by hid-input or one of the sub-drivers as keys. This,
> unfortunately, leads to sub-drivers multiplying by the hour and many
> of them only do initial setup of usages and waste memory once that is
> done.
>
> How about we also allow EVIOCSKEYCODE to establish mapping for
> not-yet-unmapped usages (usage->type == 0)? Then we could offload the
> task of setting up keymaps to udev.
>
> This depends on the large keycode handling patches that are in my tree
> in 'next' branch. Not tested past booting...
>
This is fine with me, if that matters. However, I'm not sure it could be
a catch-all solution. For example, the five numbered keys on these
Microsoft keyboards put the key number in the value field (rather than
usage->hid). Maybe you could reduce the number of sub-drivers needed by
using the vendor id alone for at least some of the quirks.
Jonathan
next prev parent reply other threads:[~2010-09-15 6:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-15 4:58 HID: Allow changing not-yet-mapped usages Dmitry Torokhov
2010-09-15 6:51 ` Jonathan Conder [this message]
2010-09-15 7:03 ` Dmitry Torokhov
2010-09-15 14:36 ` Jarod Wilson
2010-09-15 14:48 ` Jiri Kosina
2010-09-15 16:16 ` Dmitry Torokhov
2010-09-15 17:15 ` 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=4C906CDF.6030700@gmail.com \
--to=jonno.conder@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=jkosina@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.