[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d120d5000705031217h64db0644qb1e8bc8d8af6e78c@mail.gmail.com>
Date: Thu, 3 May 2007 15:17:32 -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.
Hi Roman,
On 5/3/07, Roman Zippel <zippel@...ux-m68k.org> wrote:
> Hi,
>
> On Thu, 3 May 2007, Michael Schmitz wrote:
>
> > > > + for (i = 1; i < 0x72; i++) {
> > > > + atakbd_keycode[i] = i;
> > > > + set_bit(atakbd_keycode[i], atakbd_dev->keybit);
> > >
> > > It looks like this driver is not using standard input event codes.
>
> Actually it does, it just sort of works because Atari generates mostly
> AT keycodes.
>
But not the input core codes, does it?
> > > If
> > > Roman does not want to adjust keymaps on Amiga and Atari that should
> > > be handled in legacy keyboard driver (drivers/char/keyboard.c). As it
> > > is programs using /dev/input/eventX have no chance of working.
>
> 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
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).
Answering 1) I sent you once a patch for review that would have amikbd
send raw scancode events in additional to standard input events and
drivers/char/keyboard.c pick these raw events on amiga so both legacy
driver and evdev could work, but I never heard from you.
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.
--
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