More about XKB

[M. Gerards]

Hi,

I've been working on the XKB console-client plugin for some weeks
now. In this mail I will inform you what I have done, what needs to be
done and how XKB globally works. This is a huge mail for something
simple like a keyboard, but well... I hope many people understand more
about keyboards than they did before they read this mail and can give
me some feedback :).


Before you can understand what it does you first have to know what it
is. This plugin is no driver (as it is now), but it is an additional layer 
between
the console-client and the driver. XKB is the X Keyboard Extention,
the X way to have amlost full control over your keyboard. It's more
than a keyboard map. It has many accesibility features and actions
that can be bound to keys. 

scancodes
=========

Everything what this XKB plugin will do is based on a keyboard
event. Every keypress and release will generate one or more
scancodes. These scancodes are not the same for all keyboards. All AT
and PS/2 keyboards can generate set 2 scancodes. An example of a set 2
scancode is 0x1C, this will be generated when you press "A". When you
release this key 0xF0, 0x1C will be generated.

There are several other sets. The most important in this case is set
1. This set is used by default on the PC. The controller on the PC's
motherboard translates the set 2 scancodes to set 1 scancodes. This
set differs much from set 2. For example when "A" is press the
scancode 0x1E is generated, when the key is released 0x9E is
generated.

keycodes
========

Many operating systems don't use scancodes directly. There are several
problems with scancodes. One problem is that multiple scancodes
correspond with a single keypress. Another problem is that scancodes
are different on other systems. The solution to this problem was
translating scancodes to keycodes. Keycodes are always the same for
that implementation and have a fixed size. So it doesn't matter what
kind of scancodes the keyboard produces, you will always get the right
(the same) keycode. 

Keymap
======

Keycodes are still useless for end users most of the time. The final
step is the translation from keycodes to symbols. Users also want to
modify the behaviour of the "keyboard", this can be done with
modifiers. Modifiers are usual keys like Shift, Control and Alt. The
old fashioned way of mapping keycodes to symbols is really simple. A
keymap is stored in memory. A row exists for every key, a column
exists for every (combination of) modifier(s). Here is a small
example:

keycode 38 is key "A"
keycode 56 is key "B"

keycodes
NONE
Shift
Alt
Shift+Alt
38
        a       A       �        �
56
        b       B               '

 XKB 
=====

The way XKB implements keymaps differs from this. XKB doesn't have
such a simple table. Instead of that it uses a more flexible solution.


Before I can explain how this solution work you need to know what a
keytype is. A keytype describes how a key should respond to modifiers
and to which modifiers it should respond. Keytypes can automaticly be
determined by XKB, if someone is curious how it works I can explain
how this works. Showing a keytype is much simpler than describing what
it is. An example I copied from my XKB configuration:

    type "KEYPAD" {
        modifiers= Shift+NumLock;
        map[Shift]= Level2;
        map[NumLock]= Level2;
        level_name[Level1]= "Base";
        level_name[Level2]= "Number";
    };

The map[] option is really important. It describes the combination of
modifiers that determine the shift level. In this example the shift
level will be "Level2" when the shift key is pressed. When a
combination of modifiers isn't described the shift level will be
"Level1", so when no modifiers are pressed the shift level will be
"Level1".

The shift level will determine which symbol will be generated. Here is
a part of my XKB configuration to show what happens:

    key <AC01> {
        symbols[Group1]= [               a,               A ],
        symbols[Group2]= [              ae,              AE ]
    };

In this example you can see multiple groups. Group one can be used to
generate "a" or "A". XKB determines which one to use with the shift
level. So when you press "Shift" the shift level will change to
"Level2" and "A" will be the result when you press the key "A".

The group is a set of character that belongs together. This can be an
alphabet or some symbols. 

More XKB stuff
==============

XKB has more features than just determining symbols. It is possible to
bind actions to keys. These actions can change modifiers (Set, Clear, Lock or
Latch), switch (virtual) consoles, etc. 

Another cool feature of XKB is Xaccess, a set of accesibility features
for XKB.


What I have done
================

There are two ways to store XKB configuration files: In a human
readable way and in a machine readable way. The last method, the
compiled keymap is the one I use. These files (XKM files) can be
generated from the human readable ones. Currently this has to be done
manually.I've implemented routines that can read and parse a great
amount of available sections. 

I've also implemented routines to determine modifiers and routines to
convert scancodes to keycodes and keycodes to keysymbols. Also some
actions are supported.

This is almost enough to support most keymaps.

What needs to be done
=====================

- Scancode->Keycode convertion is far from perfect. Currently this
  translation is hardcoded and only set 1 is supported. I want to have a
  configuration file in which new sets can be added or changed. I have
  seen some mails in which users complain about the XKB solution
  (hardcoded). This should be done right from the beginning IMHO. To
  support this we need a data format for the configuration files that is
  compatible with all possible sets. 

- The code still doesn't behave *exactly* as XKB does. The wanted
  behaviour of XKB is described in "The X Keyboard Extension: Protocol
  Specification". This is important to fix because of compatibility. I
  can fix most of these behaviour problems very quickly.

- Deadkey support. See what the problems are in my previous mails to the
  list, or ask me.

- Implementing all XKB actions and add specific Hurd actions. I'm
  thinking about actions like scrolling, etc. Does someone have some
  nice ideas? :))

- Many small features are not implemented yet. I'm talking about
  things like Overlays, etc. If someone uses a feature that I didn't
  descibe in this mail, please tell me, otherwise I'll consider them
  as low priority.

- Implementing AccessX. This can be a real problem. I think we have to
  implement auto repeat of keys ourselves before this can be
  supported. I'm not 100% sure and hope someone has a solution to
  problems like:

  Slow keys, an AccessX control that will only accept a key when it is
  pressed for x milliseconds, is activated. When the used hold the key
  down both XKB and the keyboard will record how long. After Slowkeys
  has accepted the key the keyboard will not wait long before more
  keypresses are generated by the keyboard. Much faster than normal
  because the first symbol is delayed.

  I expect other AccessX controls will have simular problems.

- Latching of modifiers isn't supported at all yet, but adding this
  feature should be very easy.

- Indicators aren't supported yet because the compatibility map isn't
  read and parsed yet. In this section describes the behaviour of the 
indicators.

- A userspace driver. I think the XKB part and the driver should be
  seperate.

- The console and X. Because I have never tried X on GNU/Hurd I'm
  asking: is switching from the console to X and back currently
  supported? This is how it is done for GNU/Linux:

      ioctl(xf86Info.consoleFd, VT_ACTIVATE, specialkey - KEY_F1 + 1);

  This isn't really XKB stuff, but I think it is a nice feature to
  have.

  Another thing that is important for X is access to the
  keyboard. Marcus suggested using a repeater for X. I assume this
  repeater will be a translator that will be readable and writable and
  that the reader (X) will get everything a writer (the
  console-client) has written to it. (I'm describing this to make sure
  we are talking about the same thing).

  I wonder: what kinds of information can X read from this repeater?
  Scancodes or keycodes? I think Keycodes is the best solution
  because in that case X doesn't have to worry about the hardware at
  all and because the current code to convert scancodes to keycodes in
  X IMHO sucks. A problem with this repeater can be the commands X
  wants to pass to the keyboard (Like setting the LEDs), right?


Although this mail is huge, it still isn't complete. I'm sure I forgot
a lot of important things. Please ask me questions if you don't
understand something or if you just want information. This mail should
be understandable for people without much knowledge about keyboards.

I hope I can release all of this in the form I wanted before the end
of this year. I think I can sends some code that doesn't implement all
of this sooner so people can use their XKB keymap.

Thanks,

Marco Gerards