Re: Bug#85629: keymap for RiscPC
> OK - but that looks like it took the i386 code, and simplified
> it to the bones, and applied a transformation to turn PC codes
> into old Acorn codes.
Ah, but they're not PC codes - they're the bare bones codes that are sent
over the wire. We don't have a PC controller that does the translation
of raw scan codes into the conventional codes that Linux PC keymaps use.
The keyboard may look like a PC keyboard, it may act like a PC keyboard,
but it does _NOT_ behave like a PC keyboard.
My other objection to changing this is that it _always_ comes up in the
middle of a stable kernel series, and changing the keyboard API during
such a time is a definitely not on. If you want to do it, do it at the
start of a development series.
I'm getting a strong sense of deja vue because I've explained this all
before on several occasions, and each time the subject falls silent.
Maybe this time it won't.
> Russell, I do not know anything about RiscPC or Acorn keyboards,
> but people are unhappy because they have a PC keyboard and would
> like to apply PC keymaps, while this driver first maps symbols
> away, so that users have to undo this driver translation before
> they can use a PC keymap.
PC keymaps won't work without translation of ps2 codes to pc keyboard
codes. Also, at the time I wrote it, it was more important that backward
compatibility with the older A5000 keyboard was maintained (since that was
the sole map that the ARM X server knew about).
Yes, they have something that _looks_ like a PC keyboard, but as far as
the hardware/software interface is concerned it is _not_ a PC keyboard.
It is this concept that people seem to have great difficulty in grasping.
If someone would like to write the necessary i8042 keyboard controller
functionality and put it in Linux...
> Can this change? Or is there a good reason?
> Why does keyb_ps2.c have this keycode_translate?
To make it absolutely clear, ps2 keyboard codes != pc keyboard codes.
Russell King (email@example.com) The developer of ARM Linux