[BRLTTY] brltty commands and X keysyms

[Samuel Thibault]

Hi,

The current encoding scheme of commands in brltty doesn't allow for
unicode characters, and doesn't define all useful keycodes (it lacks
alt-gr for instance).  In addition to that, before beginning to write
bindings of BrlAPI is several langages (java/python/perl/ocaml at
least), we'd like to think about using something more "standard" for
coding keys in the BrlAPI protocol.

We then got the idea of just using X keysym values, not by depending on
the X <X11/keysymdef.h> header for providing the keysym macros, but by
defining brltty commands in a way similar to X11 keysyms.  There are
several advantages:
- It already includes all keysyms and modifiers that brltty defines
(not braille commands and at2 scancodes, but see below), plus unicode
characters.
- It is a well-known standard way of encoding keysyms.
- If new keys appear on keyboards, we don't need to care about how to
encode them, we can just follow X consortium's decision.
- It makes the XWindow pseudo-braille driver, the At-Spi and Hurd screen
drivers and xbrlapi quite more pretty.

The issue is that X keysyms are coded on 29bits, plus modifiers (there
are 8 of them).  That means that this doesn't fit in an int anymore.
Long longs may be used since C99 asserts that they are at least 64bits
wide. The low 29bits part may hold the X keysym (or a braille command if
the 31st bit is set, for instance), and the hi part hold modifiers and
flags ("repeat" for instance).

That still means changing types everywhere in braille drivers.  And the
compiler doesn't help much, since implicit integer casts just truncate
values without a single warning.  I have done such change in my own
checkout of the sources, and got it to work fine with the XWindow
braille driver.  Of course, that doesn't mean that it will work for all
other drivers.  The typical effect of a missing change is that flags and
modifiers don't work anymore.

If the burden of modifying all drivers (and testing that they all still
work!) is too high, we may for now use such encoding in BrlAPI only, and
convert codes on the fly.

What do people think about this?

Samuel and Sebastien