Re: [PATCH] Input: document the proper usage of EV_KEY and KEY_UNKNOWN

[Dmitry Torokhov]

On 6/1/07, Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote:
> On Fri, 01 Jun 2007, Dmitry Torokhov wrote:
> > On 6/1/07, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote:
> > What I am trying to say - there already EVIOCSKEYCODE ioctl in the
> > kernel. And for force feedback devices to work you need to nable
> > writing to corresponding /dev/input/eventX thus opening possibility to
> > alter the keymap table. I guess you coudl analyze capabilities of a
> > device and only relax permissions for devices that have FF...
>
> Agreed. CAP_SYSADMIN or somesuch should be required for some of those
> IOCTLs, at least on keyboards. I don't see a problem with a digitizing
> tablet relaxing that to allow anyone, for example, so it makes sense to punt
> this test to the driver level (and not input layer level), or to make it
> configurable somehow from the driver level before registering the input
> device.

That is going to be a bitch to implement for HID devices which can be
all of the above at once.

> > Anyway, I think that we don't want ordinary users to alter hardware
> > keymapping, it should indeed be priveleged operation done by box's
> > administrator. Hopefully the infrastructure (hal/udev/whatever) will
> > be able to load proper keymap at boot time so even that is not needed.
> >
> > Why I think using kernel remapping_in addition_ to X remapping is better:
>
> Agreed.
>
> > The biggest cons for KEY_UNKNOWN + scancode is that presently we do
> > not have the code to iteract with user.
>
> Actually, it is more like "we don't have it, and it is non-trivial to do it
> right", if I understood Matthew correctly.

Yes, here I agree. There are quirks to be worked out.

There is one more thing. If we alias KEY_FN_ESC through KEY_FN_B as
KEY_GENACT* this will give us 20 general-purpose actions. If we add
something like EVIOGSCANCODE to retrieve reverse mapping then
distributions like Matthew's can just scan new input devices in udev
and remap to KEY_GENACT* while we employ KEY_UNKNOWN + scancode on
kernel level.

> > >> > 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.
> > >
> > >Standard is that everyone gets their own machine, but usually everyone
> > >has an account on all of them.
> >
> > Which is never used (except remotely)...
>
> Oh yes, it *is* used, and very much so.

Ok, different experiences I guess...

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