Message-ID: <d120d5000705031332o444415favd3f245ccdea95bea@mail.gmail.com>
Date:	Thu, 3 May 2007 16:32:33 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Roman Zippel" <zippel@...ux-m68k.org>
Cc:	"Michael Schmitz" <schmitz@...l.biophys.uni-duesseldorf.de>,
	"Geert Uytterhoeven" <geert@...ux-m68k.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-m68k@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Michael Schmitz" <schmitz@...ian.org>
Subject: Re: [patch 04/33] m68k: Atari keyboard and mouse support.

On 5/3/07, Roman Zippel <zippel@...ux-m68k.org> wrote:
> Hi,
>
> On Thu, 3 May 2007, Dmitry Torokhov wrote:
>
> > > I explained already at a earlier occasion, why this "generic" keycode
> > > thing is broken by design, which makes connecting multiple keyboards with
> > > different mappings impossible.
> > >
> >
> > No, I don't think so. Your points were:
> >
> > 1) You did not want to adjust your legacy keymap on Amiga
>
> Adjusting wouldn't be really a problem, if it had some value...
>
> > 2) You want userspace programs to know how to program scancodes for
> > every type of keyboard and have different keymaps for different type
> > of keyboards (So you need to have n_kbd_types *
> > n_international_mappings keymaps).
>
> I never said that. Many keyboard _types_ need a separate key mapping.
> Localization is a completely different problem (and could be solved via
> separate localization tables).
> Most of it can be solved in userspace and we wouldn't have to enumerate
> every possible single key the kernel never cares about in <linux/input.h>.
>

I am not sure that solving it all in userspace is right solution.
Consider a sleep button. It can be hooked up via ACPI, located on AT
keyboard, USB keyboard or even on a remote control or some userspace
daemon getting data from the network. If kernel just passes raw data
to userspace then userspace programs need to know all these potential
sources and handle them separately. But with unified input device
interface userspace program only needs to monotor appearance of new
event devices, latch onto them and wait for EV_KEY/KEY_SLEEP. And it
is not much burden for the kernel because kernel already interfaces
with all these devices. In fact there probably savings because kernel
uses single interface layer.

> > As far as 2) goes I think it is better to have unified keyboard map
> > across different types of keyboards and then overlay
> > internatinalization/other settings. And you still have per-keyboard
> > configurability as you can change scancode->keycode mapping on a
> > per-device basis via evdev ioctl.
>
> You still completely ignore the problem of how said application should
> properly support multiple keyboard mappings...
>

I am afraid this statement is too vague, we need to discuss specific
scenarios...

Consider this scenario:

You use 2 PS/2 keyboards with your laptop - built-in and external one
on a separate serio port. Your built-in has media keys generating some
non-standard scancodes. The external one also has same media keys but
generating different set of keycodes. With unified input events you
can "fix" your keboards to generate same input events and the rest of
your stack does not care.

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

Powered by blists - more mailing lists