keyTouch and desktop environments

Marvin Raaijmakers

17-01-06

Introduction

Many keyboards and notebooks have extra function keys. The user can bind actions to these keys. Under Linux kernel 2.4 we could just bind a keysymbol to the keycode of a key and then run a program that grabs it. However since kernel 2.6, not all extra function keys have a keycode under X.

It would be of course nice when your favorite desktop environment includes a program for configuring extra function keys. There is already an application available that allows us to do this. This program is called keyTouch and provides a complete solution to the extra function key problem. It is a good idea that the development team of a desktop environment cooperates with the keyTouch project. Why this is a good idea will be explained in the rest of this article.

The problem

First we should understand what main problem is if you want to configure extra function keys.

The main problem is that X does not receive key events anymore. This is because Linux kernel 2.6 works a bit different than the previous ones. It now always tries to present the same set of keycodes (we will call these "universal keycodes") to userspace, no matter what type of keyboard (PS/2 or USB) or architecture. And because it operates with keycodes in the input core, and the hardware specific scancodes are abstracted by the specific keyboard driver, it doesn't use the scancodes anymore. However, some programs want scancodes. Therefore the kernel creates for such programs scancodes form the keycodes (by using a fixed mapping table). X is a program which wants scancodes and internally converts these to keycodes.

Note: It is very important to realize that the keycodes used by X internally are not equal to the universal keycodes the kernel provides.

The reason why for some keys X does not receive an event is because those keys do not have a kernel keycode (and therefore no scancode will be sent to X). You should understand that when the kernel wants to provide universal keycodes, some function keys are unknown to the kernel. That means the kernel doesn't know what key it is and because of that it will have no keycode. When such key is pressed the kernel will give us a message like this:

atkbd.c: Unknown key pressed (translated set 2, code 0x92 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e012 <keycode>' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0x92 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e012 <keycode>' to make it known.

So it is the task of the user to assign keycodes for unknown keys. In the kernel header file linux/input.h the user can find the universal keycode of the key.

After making the key known to the kernel. The user has to find out what X keycode it has under X, bind a keysymbol to the keycode and configure a program so that it grabs the extra function key.

The solution

KeyTouch is the solution to everything that was discussed in the previous section. This section describes how it works.

First keyTouch will have to assign the universal kernel keycodes to the scancodes of the extra function keys. Because the user tells keyTouch what keyboard he/she is using, the program knows which keys are on the keyboard. keyTouch uses for every keyboard model a keyboard file. Such a file contains a list of keys and for every key its name, scancode and the kernel keycode that will be assigned to the key. With this information keyTouch assigns the kernel keycodes to the scancodes. This is done at boot-time and when the user changes his/her keyboard.

After assigning the keycodes we need to know what keycode a key has under X. KeyTouch uses a "kernel keycode" to "X keycode" conversion table to do this job.

Keytouchd will be started when the user starts an X session. This program grabs all extra function and executes the appropriate action when a key is pressed.

Extra function keys are not shortcuts

You might think there is already a program for configuring extra function keys for my desktop environment. However this is not true, because that program allows you to bind shortcuts to actions. KeyTouch allows you to bind actions to extra function keys. These are two different things, for two different goals (take time to think about this).

Why cooperating?

Why is it so important that developers of desktop environments cooperate with the keyTouch project, so that something like a standard will be established? There are several reasons for that.

First because there will be a standard. This means that the configuration under desktop environment A is the same as under desktop environment B.

Another reason is that the wheel will not have to be reinvented. The good quality knowledge and the code of the keyTouch project can be re-used.

Resources can be shared. This means that information about the keyboards can be shared and that the collection of information will grow faster.

A very important and technical reason it that keycodes have to be assigned to scancodes (note: this can only be done by root). This can only be done by one program because otherwise the system will be messed up.

How to cooperate?

There are many different ways to cooperate, but more important is that we cooperate. My plan is that the keyTouch project, GNOME and KDE go and sit around the table and discuss this subject. Please send an e-mail to: marvinr <at> users <dot> sf <dot> net