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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
