From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Dmitry Torokhov <dtor@insightbb.com>,
Richard Hughes <hughsient@gmail.com>,
linux-acpi@vger.kernel.org, linux-input@atrey.karlin.mff.cuni.cz,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Input: document the proper usage of EV_KEY and KEY_UNKNOWN
Date: Thu, 31 May 2007 22:29:28 -0300 [thread overview]
Message-ID: <20070601012928.GD5407@khazad-dum.debian.net> (raw)
In-Reply-To: <20070601002435.GA2621@srcf.ucam.org>
On Fri, 01 Jun 2007, Matthew Garrett wrote:
> On Thu, May 31, 2007 at 09:13:04PM -0300, Henrique de Moraes Holschuh wrote:
> > Well, we already produce KEY_UNKNOWN anyway, and the stuff you quoted above
> > just makes KEY_UNKNOWN useful for something instead of keeping it as an
> > useless notice to the user that some key (which one? who knows!) was
> > pressed.
>
> Given existing userspace, it's never useful to generate KEY_UNKNOWN.
> Adding extra information to the event doesn't alter that.
It will not break anything, and it is trivial to write an application to
intelligently handle KEY_UNKNOWN+scancode events. This really is not a
reason to not do it, at all.
> > Perhaps what you dislike re. KEY_UNKNOWN is the part where KEY_UNKNOWN+scan
> > code is declared to be the prefered way to report keys that do not have a
> > specific function? Your reply seems to indicate this, but I am not sure I
> > really understood what you meant.
>
> Yes.
That could easily be removed or switched around but...
> > I am not exactly in love with the idea of using KEY_UNKNOWN in place of
> > stuff like KEY_FN_F1 either (I'd prefer to just bump up KEY_MAX and have
> > more posicional keycodes), but Dmitry is being quite clear that he does not
> > want to increase KEY_MAX to add more positional keycodes.
>
> I think using positional keycodes would also be a mistake. We just need
> a slightly larger set of keycodes representing user-definable keys.
> There's 4 of them already - I really can't imagine there being many
> keyboards with a significantly larger set of unlabelled keys.
I had this exact PoV, too, until Dmitry reminded me that keycodes are
*global* to the system in practice, and that different keys (as in keys that
have no correlation between their position, labels or lack thereof, and
function) in different input devices would end up mapped to KEY_PROGx by
default.
And in that scenario, KEY_UNKNOWN (i.e. "please remap me to what you want
this key to do for real") makes a lot more sense, given that we don't have
all the positional keycodes we need, and more are not being added.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
next prev parent reply other threads:[~2007-06-01 1:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <11802004861625-git-send-email-hmh@hmh.eng.br>
[not found] ` <d120d5000705301325yf76d062vefbc79873d23e602@mail.gmail.com>
[not found] ` <20070531005305.GC6883@khazad-dum.debian.net>
[not found] ` <200705310033.51230.dtor@insightbb.com>
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 [this message]
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
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=20070601012928.GD5407@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=dtor@insightbb.com \
--cc=hughsient@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-input@atrey.karlin.mff.cuni.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.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