Several problems have arisen with keysyms that require a thorough update of the
a) Unicode (ISO 10646) has now become the single universal character set
standard that we wished would have been available when keysyms were first
introduced. Keysyms identify both function keys and real characters. For each of
the latter, it is time that we introduce one single official mapping to the
equivalent Unicode character to clarify its exact meaning.
b) For a number of keysyms, the meaning and historic origin has been lost in
time. If we really cannot locate anyone who has a good idea about what some
keysym was once meant to be good for, and where it came from, it is probably
time to declare that keysym officially as deprecated. We should be able to
answer for each keysym questions about its purpose and origin, especially if
there is no obvious mapping to Unicode.
c) No new keysym values should be introduced in the future for real characters.
New values should remain reserved for new function keys (READ EMAIL, EJECT DVD,
EXIT HOLODECK, whatever), which are outside the scope of Unicode. Instead, there
should be a simple algorithmic mapping between any Unicode character and the
corresponding new keysym value. XFree86 has already established the convention
that a Unicode character 0xabcdef is represented by the keysym value 0x01abcdef
unless another widely used keysym was already assigned to it.
d) Some XFree86 developers unfamiliar with the Unicode mapping convention and
the allocation to the keysym space added unfortunately new keysyms for Arabic,
Vietnamese, old Irish orthography and other characters. In the interest of
compatibility, either XFree86 should remove these (or replaces them with
Unicode-based values), or we will have to add them to the X11 standard.
e) We may want to retire additional keysyms for which there are no indication
that they are widely used, in favor of the direct Unicode mapping. An inspection
of the keyboard mapping files in major distributions should give a good idea of
what is actually in use.
f) Even with an algorithm mechanism in place to automatically generate new
keysym values from Unicode positions, we still need a mechanism to respond
quickly to users who want to add additional keysym macro definitions, in order
to keep keyboard layout files readable and free of hex codes.
Overall goal of this revision should be that the relationship between keysym and
Unicode values becomes as simple and long-term stable as is possible without
causing serious backwards compatibility problems.
A wiki page on this issue is now available on
which details the changes made in the drafts below.
A draft update for the file xc/doc/specs/XProtocol/X11.keysyms is on
This is a substantial rewrite of the official definition of the keysyms.
A PDF formatted version of the above is on
A proposed cleaned-up version of keysymdef.h is on
All of these are now mature enough for final review, after which I'd like to
include them into the CVS tree.
On 2004-09-26 I've checked in completely revised new versions of
and minor associated updates to
This is to
- officially add the Unicode keysym range to the protocol spec, such that
a Unicode character C with 0x100 <= C <= 0x10ffff can be represented by
the keysym value C + 0x01000000,
- officially add Unicode mappings for the legacy keysyms to the spec,
- move some of the new keysyms that XFree86 had added, and which
were not in the protocol spec, into this Unicode keysym range,
- make the keysym-number <-> keysym-name-string conversion
routines able to handle full 29-bit keysyms