Re: Keyboard Cursor Keys

From: Philippe Verdy (
Date: Tue Nov 30 2004 - 12:19:12 CST

  • Next message: Peter Kirk: "Re: Relationship between Unicode and 10646"

    From: "Peter R. Mueller-Roemer" <>
    > Doug Ewell wrote:
    >>Robert Finch wrote:
    >>>'m trying to implement a Unicode keyboard device, and I'd rather have
    >>>keyboard processing dealing with genuine Unicode characters for the
    >>>cursor keys, rather than having to use a mix of keyboard scan codes
    >>>and Unicode characters.
    >>This will quickly spiral out of control as you move past the "easy"
    >>cases like adding character codes for cursor control functions.
    > the "easy" cases like adding character codes for cursor control functions
    > are not so easy when you have a short phrase or R-text (Right-to Left)
    > embedded in a line of Englisch (L-text).

    This is not related to the Robert's concern about why he has to use a mix of
    scan codes and Unicode characters in a keyboard driver.

    Effectively scan codes are not characters, but this is how a keyboard
    communicate with the OS, before the OS translate these scancodes into
    characters, according to a keyboard map.

    When there's no plain-text character associated to a key, the keyboard map
    will not map characters, but will leave these scan codes mostly intact (in
    fact Windows drivers translate some physical scancodes to logical scancodes
    to translate some functions which have various positions depending on
    keyboard, but that should be treated as equivalent.

    With MSKLC, you won't notice these changes in the generated customized
    table, because this translation is performed either in the BIOS, or in the
    keyboard hardware, or in a default scancode map within the generic keyboard
    driver, so that the effective keyboard mapping is from the pair of a virtual
    (translated) scancodes and keyboard mode, to characters. The virtual
    scancodes are simpler, and also hide some details about the special byte
    0x00 that can prefix some extension keys before their actual scancode.

    Also the physical scancodes are defined on 7 bits only, the 8th one
    corresponding to a keypress or keyrelease status; keyboards may generate
    multiple keypress scancodes at regular intervals as long as the key is
    maintained pressed (the rate of this autorepeatition is not specified in the
    keyboard mapping, but with an external setting, depending on user's
    preferences, sent to the running keyboard driver, which may give this rate
    information to the hardware as a configuration command.

    Several scancode translations are performed in the generic keyboard driver,
    such as recognizing the AltGr key of European keyboard as equivalent to
    Ctrl+Alt (if this is enabled in a flag set in the custom keyboard map), or
    the translation of AltGr+keys on the numeric pad to compose either local OEM
    characters or local "ANSI" characters. Note however that the generic
    keyboard driver included in MSKLC has no support for the composition of
    characters per their Unicode hexadecimal code point; for such a thing, you
    need a custom driver code, and not only a simple mapping table. Same thing
    if you want to support more complex input modes (for example with Asian
    character sets), that can't be represented easily with a simple table of
    pairs combining a "current state mode" and a logical scancode.

    Keyboard drivers also contain several other hardware specific commands to
    set some advanced features in keyboards, and MSKLC will not let you program
    them, but the generic driver it contains will contain several standard
    features, enabled with a physical keyboard interface driver.

    What remains to the application is a set of keypress/keyrelease events with
    a virtual (translated scancode), that an application may trap if the
    application does not want that these events be translated through the
    keyboard mapping in the generic driver. The generic driver then intercepts
    the untrapped events, and translate them to characters according to the key
    mapping table you have created in MSKLC.

    Most applications will then be interested only in trapping some function
    keys that never generate a character in the mapping table, and will leave
    the other virtual scancodes (the VK_<key> codes) translated by the installed
    local keymap, which will generate other character events.

    The form of the generated character events depends on the intercepting
    application: if the application with the keyboard focus is Unicode-aware, it
    will wait for Unicode char events, and the keyboard mapping will then send
    these characters; if the application with the keyboard focus is waiting for
    characters using some legacy interface emulation (BIOS, DOS, or Windows
    ANSI), the mapping will be used, but the Unicode characters in the keymap
    will first be transcode into the appropriate charset. If an Unicode
    character can't be converted into the appropriate charset, the application
    will receive an error event, that by default will take the form of a sound
    event, or the generation of a default character, and sometimes a combination
    of boths. Such events won't occur for virtual keys that have no mapping to a
    Unicode character in the localized keymap.

    Note: Virtual keys is what allows many models of keyboard to be unified,
    including keyboards designed for the same language family or country
    (notably to filter the differences between notebook and desktop keyboards,
    or between keyboards with more or less OEM keys). No application should
    depend on scancodes. Note however that some scancodes cannot be generated on
    all keyboards, so a keymap should be designed carefully to check that
    there's an alternate method (even if it's not as easy to strike as a single
    key) to generate the same characters or functions.

    Other keyboard drivers work differently, notably on other systems than
    Windows, or for some application-mode keyboard drivers like Tavultesoft's
    Keyman that works on top of an existing generic keyboard driver, that
    already preprocess the physical scancodes into virtual key codes.

    All this is out of topic for Unicode which is only concerned by the encoding
    of characters, not the scancodes, or virtual keys used by function keys like
    Arrows or F1 or even the Enter key (which is not by itself mapped directly
    to a CR Unicode character but first as a virtual key with keyboard state
    flags or mode), or the definition of bits in keyboard state modes: they are
    not characters, do not generate plain-text information, so it's normal that
    they have no Unicode code point associated with them!

    This archive was generated by hypermail 2.1.5 : Tue Nov 30 2004 - 12:22:35 CST