From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
linux-input@atrey.karlin.mff.cuni.cz,
ibm-acpi-devel@lists.sourceforge.net,
Richard Hughes <hughsient@gmail.com>,
linux-acpi@vger.kernel.org
Subject: Re: [ibm-acpi-devel] [PATCH] ACPI: thinkpad-acpi: add thinkpad keys to input.h
Date: Thu, 31 May 2007 00:01:47 +0100 [thread overview]
Message-ID: <20070530230146.GA8623@srcf.ucam.org> (raw)
In-Reply-To: <d120d5000705301325yf76d062vefbc79873d23e602@mail.gmail.com>
On Wed, May 30, 2007 at 04:25:03PM -0400, Dmitry Torokhov wrote:
> Consider ejecting a CD tray. You have a laptop with a key that maked
> eject CD. Because it is a new laptop there are no proper mapping yet
> so some adjustments are needed. With your scenario the kernel emits
> KEY_PROG26. User has first to adjust X keymap to map KEY_PROG26 to
> EjectCD event (simplifying). Then he goes into text console only to
> find out that his curses-based CD player does not recognize that key
> and also needs to be adjusted. And so on. Finally all applications are
> made aware of KEY_PROG26 amd user is happy. Couple of weeks later he
> goes and buys an external keyboard and it turns out that eject CD
> there is actually KEY_PROG21 so he need to go through second round of
> mapping for all applications. Not only that but button with volume
> increase happens to generate KEY_PROG26. Now what?
>
> Now consider in-kernel remapping to functional scancdes that I
> propose: user says that that key should generate KEY_EJECTCD and it
> starts working in all appliations recognizing that event. Adding the
> second keyboard into mix does not mess up the first one.
That makes absolute sense when a key has a defined function, but in the
case we're discussing it doesn't. So, we have two choices:
1) Map it to a specific function system-wide (so a default of
KEY_UNKNOWN is fine)
2) Map it to a specific function at the user level
If the key doesn't have anything printed on it, there is no correct
system-wide default. It's intrinsically a per-user preference. But for
the user to be able to decide what the key does, it has to generate a
keycode. Once it does that they can use one of the existing X
applications to bind that to an X keysym and then everyone is happy.
But for this to be possible a keycode has to be generated. We can either
set this at boot time or in the kernel. The only argument for doing it
at boot time is that userspace might have a better idea what the key
should map to. However, in the case of a blank key, how is userspace
going to have any more idea than the kernel does? The only sane default
is something like KEY_PROG1.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2007-05-30 23:01 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <11802004861625-git-send-email-hmh@hmh.eng.br>
[not found] ` <11802006651698-git-send-email-hmh@hmh.eng.br>
[not found] ` <11802006652128-git-send-email-hmh@hmh.eng.br>
[not found] ` <11802006652058-git-send-email-hmh@hmh.eng.br>
2007-05-26 17:31 ` [PATCH] ACPI: thinkpad-acpi: add thinkpad keys to input.h Henrique de Moraes Holschuh
2007-05-27 3:40 ` Dmitry Torokhov
2007-05-27 12:15 ` Henrique de Moraes Holschuh
2007-05-27 18:10 ` Henrique de Moraes Holschuh
[not found] ` <20070527121513.GC19562-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org>
2007-05-29 3:16 ` Dmitry Torokhov
[not found] ` <200705282316.32173.dtor-xOqKmqBdiMhF6kxbq+BtvQ@public.gmane.org>
2007-05-29 13:05 ` Henrique de Moraes Holschuh
2007-05-30 13:57 ` Dmitry Torokhov
2007-05-30 14:04 ` Matthew Garrett
2007-05-30 14:18 ` Dmitry Torokhov
2007-05-30 14:25 ` Matthew Garrett
2007-05-30 14:31 ` Dmitry Torokhov
2007-05-30 14:42 ` Matthew Garrett
2007-05-30 15:07 ` Henrique de Moraes Holschuh
2007-05-30 15:24 ` Henrique de Moraes Holschuh
2007-05-30 16:04 ` Dmitry Torokhov
2007-05-30 17:24 ` Henrique de Moraes Holschuh
2007-05-30 20:25 ` Dmitry Torokhov
2007-05-30 23:01 ` Matthew Garrett [this message]
2007-05-31 0:53 ` Making KEY_UNKNOWN really useful to userland Henrique de Moraes Holschuh
2007-05-31 4:33 ` Dmitry Torokhov
2007-05-31 22:28 ` [PATCH] Input: document the proper usage of EV_KEY and KEY_UNKNOWN Henrique de Moraes Holschuh
2007-05-31 23:33 ` Matthew Garrett
2007-06-01 0:13 ` Henrique de Moraes Holschuh
2007-06-01 0:24 ` Matthew Garrett
2007-06-01 1:29 ` Henrique de Moraes Holschuh
2007-06-01 1:44 ` Matthew Garrett
2007-06-01 2:11 ` Henrique de Moraes Holschuh
2007-06-01 3:33 ` Dmitry Torokhov
2007-06-01 4:08 ` Matthew Garrett
2007-06-01 4:37 ` Dmitry Torokhov
2007-06-01 13:13 ` Matthew Garrett
2007-06-01 14:04 ` Dmitry Torokhov
2007-06-01 14:19 ` Matthew Garrett
2007-06-01 15:06 ` Henrique de Moraes Holschuh
2007-06-01 15:21 ` Dmitry Torokhov
2007-06-01 14:51 ` Henrique de Moraes Holschuh
2007-06-01 14:19 ` Henrique de Moraes Holschuh
2007-06-20 10:21 ` Helge Hafting
2007-06-06 16:55 ` [PATCH] Input: document the proper usage of EV_KEY and KEY_UNKNOWN (v2) Henrique de Moraes Holschuh
2007-06-29 5:04 ` Dmitry Torokhov
2007-06-30 18:20 ` Henrique de Moraes Holschuh
[not found] ` <20070531005305.GC6883-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@public.gmane.org>
2007-05-31 10:37 ` Making KEY_UNKNOWN really useful to userland Richard Hughes
2007-05-31 12:48 ` Henrique de Moraes Holschuh
2007-05-31 14:37 ` Dmitry Torokhov
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=20070530230146.GA8623@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=dmitry.torokhov@gmail.com \
--cc=hmh@hmh.eng.br \
--cc=hughsient@gmail.com \
--cc=ibm-acpi-devel@lists.sourceforge.net \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-input@atrey.karlin.mff.cuni.cz \
/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).