lkml.org 
[lkml]   [2007]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Input: document the proper usage of EV_KEY and KEY_UNKNOWN
Date
On Friday 01 June 2007 00:08, 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.
>

You already do - do you let your users play games with force-feedback
joysticks? To load force feedback effect you need write permissions for
corresponding event device.

And we are talking about console owner here - with current desktop-oriented
distributions they already get access to host of otherwise restricted
devices.

> > > When the user logs
> > > out, you'll then need to unmap the key again and repeat as necessary for
> > > any new user who logs in.
> >
> > I think we should aim at the most common case - when there are no multiple
> > users on the box. Then the utility that detects KEY_UNKNOWN just saves the
> > mapping user chose and automatically reload keymap upon next reboot.
>
> The standard setup for home machines tends to be an account per family
> member.

That could be... Although it is desktops that are usually shared.
Hmm, I am trying to remember setup of the people I know... I think
the most common setup is a desktop in an easily accessible place
(kitchen) with a single account. Older kids/parents may have their
own desktop/laptops that are not shared.

> The standard setup in an office environment is likely to be
> multiuser.

Huh? In my limited experience everyone in the office gets its own box.
And I am not talking about software shop.

>
> > Note that KEY_UNKNOWN solution does not preculde futher customization on
> > per-user base once default action is established.
>
> No, but it makes it significantly more confusing. User 1 chooses a
> setup. This gets saved. User 2 remaps keys based on User 1's settings
> (which have been restored at bootup). User 1 alters key mapping. User 2
> suddenly becomes hugely confused.

One user is an administrator. He can alter the global keymap. If there
are multiple users he may need to be cautious.

> > >
> > > Alternatively, we could generate a keycode and then let the user map
> > > that to an X keysym. We've even already got code to do this.
> > >
> >
> > There is world outside of X.
>
> On machines like we're discussing (laptops, basically) it's a tiny
> world. Optimise for the common case, not the rare one.
>
> > > That's a ridiculously niche case, and can be handled in userspace. Just
> > > have udev do remapping when it detects multiple keyboards that both have
> > > KEY_PROG* layers, or let X have different keymaps for different input
> > > devices. We shouldn't make the (by far) common case significantly more
> > > difficult to deal with this one.
> > >
> >
> > No, it is not a niche case. I think it is much more common than the case where
> > you have multiple users for the same box using different keymaps. Even if box
> > is shared there most likely will be one person setting it up in the beginning
> > and the rest will follow his/her setup.
>
> How many users plug external keyboards with unlabelled keys into a
> laptop? No, I really don't think that's a common case at all.

I think quite a few people use external keyboards. I know that in my office
everyone with a laptop has a docking station and uses full keyboard with
it. I use external AT keyboard at home...

As far as unlabeled goes - they may be labeled but we may not know their
labels.

> The solution that satisfies the largest number of users with the
> smallest amount of work is the one where pressing a key on the keyboard
> results in X events being generated. Right now, that requires that the
> key generate a real keycode.
>

Again, it is not only about X. What if X is not running (or running but
nobody is logged in)? There are number of events (SUSPEND, WLAN switch,
undock request, etc) that should be handled by daemons not depending
on X.

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-06-01 06:41    [W:0.092 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site