From: Philippe Verdy (verdy_p@hotmail.com)
Date: Tue Nov 30 2004 - 12:19:12 CST
From: "Peter R. Mueller-Roemer" <pmr@informatik.uni-frankfurt.de>
> 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