From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "jonsmirl@gmail.com" <jonsmirl@gmail.com>
Cc: Linux Input <linux-input@vger.kernel.org>,
Jiri Kosina <jkosina@suse.cz>,
Mauro Carvalho Chehab <mchehab@redhat.com>,
Jarod Wilson <jarod@redhat.com>
Subject: Re: ir-core and default IR maps
Date: Sat, 6 Nov 2010 23:01:47 -0700 [thread overview]
Message-ID: <20101107060147.GC3823@core.coreip.homeip.net> (raw)
In-Reply-To: <AANLkTikfeu4DnV8E7rKahUdu2k_d08BOFZjLzBMRA2o+@mail.gmail.com>
On Sat, Nov 06, 2010 at 06:08:57PM -0400, jonsmirl@gmail.com wrote:
> I thought about this some more and I think the default maps should
> stay in the drivers. The maps are marked __init so they don't take any
> room after they are loaded. This is an important piece and plug and
> play and we should keep it. Only the keymaps for default remote
> controls that ship with the specific hardware should be included in
> the driver. All other keymaps are in user space.
>
Plug and play does not have to be implemented in kernel and udev is
perfectly capable doing it in userspace for us. Embedded products that
absolutely not want to ship udev and want to limit themselves to a
single vendor-supplied remote will have to adjust their startup scripts
to load the proper keymap.
Keymap in the kernel are needed for devices that are required to boot
(keyboards) - and even then it might be only basic keymap, not the full
multimedia goodness with 300+ distinct keys. I am not accepting any new
mappings for AT keyboard driver and I believe both I and Jiri would like
to delete bunch of HID sub-drivers that only do key remapping.
Attempting to keep keymaps in several places will likely cause them to
diverge, makes user confused where changes should be applied and who is
the authoritative source is, that is why it makes sense to remove them
from the kernel.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2010-11-07 6:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-06 22:08 ir-core and default IR maps jonsmirl
2010-11-07 6:01 ` Dmitry Torokhov [this message]
2010-11-07 14:36 ` jonsmirl
2010-11-08 7:23 ` Dmitry Torokhov
2010-11-08 13:09 ` Mauro Carvalho Chehab
2010-11-08 13:34 ` jonsmirl
2010-11-08 13:41 ` jonsmirl
2010-11-08 14:14 ` Mauro Carvalho Chehab
2010-11-09 6:32 ` Dmitry Torokhov
2010-11-09 10:21 ` Mauro Carvalho Chehab
2010-11-10 6:51 ` Dmitry Torokhov
2010-11-10 13:30 ` Mauro Carvalho Chehab
2010-11-11 1:37 ` Dmitry Torokhov
2010-11-09 12:07 ` jonsmirl
2010-11-08 14:11 ` Mauro Carvalho Chehab
2010-11-08 15:07 ` jonsmirl
2010-11-08 15:38 ` Jarod Wilson
2010-11-08 16:33 ` Mauro Carvalho Chehab
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=20101107060147.GC3823@core.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=jarod@redhat.com \
--cc=jkosina@suse.cz \
--cc=jonsmirl@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=mchehab@redhat.com \
/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).