From: Helge Hafting <helge.hafting@aitel.hist.no>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
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: Wed, 20 Jun 2007 12:21:16 +0200 [thread overview]
Message-ID: <4678FF9C.2050700@aitel.hist.no> (raw)
In-Reply-To: <20070601141910.GB8211@khazad-dum.debian.net>
Henrique de Moraes Holschuh wrote:
> On Fri, 01 Jun 2007, Matthew Garrett wrote:
>
>> On Thu, May 31, 2007 at 11:33:10PM -0400, Dmitry Torokhov wrote:
>>
>>> On Thursday 31 May 2007 21:44, Matthew Garrett wrote:
>>>
>>>> It's not trivial at all. You need to introduce a mechanism for noting a
>>>> KEY_UNKNOWN keypress. It then needs to signal the user (dbus is probably
>>>> the best layer for this), but you need to ensure that you only signal
>>>> the user who is currently at the keyboard. This needs to be presented to
>>>> the user via some sort of UI, which will then need to signal some sort
>>>> of privileged process to actually change the keymap.
>>>>
>>> Not necessarily priveleged - you most likely already change ownership
>>> of event devices to user who is logged at console (so your force feedback
>>> joysticks work).
>>>
>> If you let users alter the kernel keymap, then you need to implement
>> support for resetting the kernel keymap on exit. Otherwise it's a
>> trivial DoS.
>>
>
> True, and unfortunately this is not something that can be done right with
> what we have now and playing with udev. Oh dear, I was too hasty to think
> that we had all the infrastructure needed already...
>
> Changing system-wide keymap should be a privileged operation. Changing
> per-user keymaps should not screw up any system-wide keymap changes made by
> the administrator, and it needs to go away for the next user.
>
> And for multi-user systems, you likely need to be able to switch keyboard
> maps when VTs are switched. This does not look like an easy thing to fix
> properly.
>
From a design standpoint, keyboard layour should obviously
be a per-VT thing. One mapping table per VT, switching happening
automatically as every keypress gets filtered throught the
current VT.
Simple design, but perhaps that is more work than anyone
care to do on the current stuff. It can also be argued that the
actual keyboard necessarily is the same for all VT's, so
they ought to all use the same layout. If my "x" is in an
odd place, then it is so for all VT's, if there are "volume control"
buttons, then they exist for all VT's and so on.
In the multiseat case there are several possibly dissimiliar
keyboards, but then they have separate event devices too.
Helge Hafting
next prev parent reply other threads:[~2007-06-20 10:21 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 ` [ibm-acpi-devel] " Matthew Garrett
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 [this message]
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=4678FF9C.2050700@aitel.hist.no \
--to=helge.hafting@aitel.hist.no \
--cc=dtor@insightbb.com \
--cc=hmh@hmh.eng.br \
--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;
as well as URLs for NNTP newsgroup(s).