Keyboard (re)mappings

Sean M. Burke sburke at CPAN.ORG
Fri Nov 19 03:07:05 UTC 2004


At 02:09 PM 2004-11-18, MiaKalish at LFP wrote:
>But can you tell me more about the keyboard abstraction layer? I must have
>missed that in my tours.

Think of it as a state machine construct (or series of them, some in
hardware, some in BIOS, some as actual drivers) at the input/output layer
of the OS.  The input events to the system are the physical readings of
keys being pressed or released, and the output events are ASCII/Unicode/etc
characters.  Inbetween you can think of there being a lookup table
representing the keymap for the particular keyboard driver, such as you can
change under the Keyboard or Language section in MSWin Control
Panel.  (Although even that layer can be extended by such a program as
Keyman or 3DKeyboard.)

Basically, this layer (as implemented in all modern operating systems) is
made necessary by exactly the problems you've forseen, and solves them.  It
also makes it easy for application-level programs to deal with the keyboard
-- programmers do not want to have to deal with scancodes and
shift/control/alt modifiers and capslock/numlock state; they want
characters -- e, w, X, control-F3, whatever.

The only exceptions I've ever run into in my decades of using nonstandard
keyboard layouts are three programs:

1) an old version of MSKermit for MSDOS.  For various reasons, its
programmers had to occasinoally bypass the normal OS-level keyboard API,
and deal right with scancodes the case of keystrokes that had no
representation as character, like shift-alt-numlock.  This only affected
terminal emulation of those very odd keys tho, and was easily fixable.

2) An Atari 2600 emulator that runs under MSWin.  It used raw scancodes, so
when its docs said that 'r' was mapped to the emulated Reset button, it
actually meant whatever the fourth key on the first letterrow, which is
where my 'p' key is.

3) a Commodore 64 emulator under MSWin.  Basically the same situation as
with the Atari.

And there is another sort of problem, a lesser one, which I've run into
only with MSWindows Winamp.  When its docs say that the 'v' key means Stop,
they're correct regardless of where the 'v' key happens to be in your
particular keymap.  But they lose their mnemonic value under non-QWERTY
keymaps, because the z x c v b keys are supposed to correspond, in that
order, to the |<  >  ||  []  >|  buttons on the GUI.  I haven't found this
to be a big problem.

In other words:  don't worry.  Unless you need to use that Commodore 64
emulator.

--
Sean M. Burke    http://search.cpan.org/~sburke/



More information about the Ilat mailing list