You should find a perl script called in the xkb folder in my patch. To try it, all you have to do is download the latest version of the xkb configuration database here:

Copy the perl script in the root of the directory of maps, and then run it. The script will generate new keycode -> virtual keycode maps in a "xkb" sub directory. You may also use the existing maps from your XKB installation if you have it installed.

The majority of new lines of source code is made of macro definitions and arrays of structures used for mapping. Most of the actual code that isn't made out of definitions is in xkbkeymap.c.

The reason why we can't make a perl script that will export keymaps in the current format from the XKB configuration database is because it is much more easier and efficient to map keycodes -> virtual key codes instead of doing key sym -> keycode -> virtual key code. key syms are already mapped according to a keyboard layout, and we don't want to deal with that because it all gets messy when we start considering modifier keys and dead keys. For instance, when you consider key sym, a dead key on a particular keyboard layout would for instance map to dead_eacute. With the current keymaps, this would be mapped to a particular key and then sent, and then you have to make a keymap that will be able to do that for every keyboard layout. When basing ourselves on keycodes, you don't deal with that, you just map it directly to a scan code and the server takes care of doing the mapping according to its own keyboard layout.

About depending on buggy XKB API, well, my code is made so that it doesn't depend on XKB API at all. The only thing we are considering here is a part of the maps from the XKB configuration database, that serves as a basis to export our set of keycode -> virtual key code maps. Our exported maps are then included with rdesktop. You don't have about buggy XKB API, we're not using it at all, and I don't plan on depending on it.

The idea is to export part of the XKB configuration database to keycode ->virtual key code maps that we then include with rdesktop. I wrote the exporting script in perl, and I wrote parsing functions in rdesktop that loads the map. We do not depend on XKB API for anything in this process. I made it so that we can use it in non-XKB environments.

On Fri, May 15, 2009 at 3:34 PM, Peter Åstrand <> wrote:
On Fri, 15 May 2009, Marc-André Moreau wrote:

1) Re-using the numbers you have said, we currently have about 40 keymaps on a total of 120 possible keymaps that would constitute a complete set of keymaps. 40 is still one third of 120, so we're not even halfway done in order to bring full support for every keyboard layout.

True if you are just looking at the number or languages, but if you instead look at which countries and users that are actually using rdesktop, I would say that, in practice, we are covering almost all users and territories. We don't hear complains about missing keymaps from 2/3 of our users, right?

I understand that if we go on a case by case basis, adding keymaps for whatever keyboard layout someone needs, it does not require much effort. The problem is that not everybody using an unsupported keyboard layout would bother submitting a bug report, or getting to know rdesktop better in order to write a new keymap and then submit it. Less common keyboard layouts are most likely to remain unsupported. Also, even if the majority of the keymaps currently work well, it may happen that someone finds a bug in it and again it is no big deal to fix it. However, this work of adding keymaps and maintaining them on an on-demand basis as people find that their keyboard layout is unsupported or broken could be solved using a "one for all" solution. That's why I thought of XKB, because they already take care of doing that job.

I agree, in principle it's better if we can avoid having "our own" keymaps. I'm just concerned that this will in practice be very complicated. But I would be happy if you could prove that I'm wrong.

You have mentioned that XKB has a lot of bugs. I have taken a look at the bug reports for xkb:

And most of the bugs submitted are minor or cover aspects of the data base that we wouldn't even be using (such as
the symbolic key name to keysym translation). Also, if we bother doing the maintenance work for our own set of
keymaps, it would take just as much efforts to submit a bug report to XKB instead, and fix it on our side. We would
benefit from that, and XKB would benefit from us (if we find bugs in their database).

Yes, squashing bugs in the upstream XKB database is better than fixing our own keymaps, I agree, if we are just talking about the XKB data base.

However, if we are talking about using the runtime XKEYBOARD extension as well, like Ilya Konstantinov suggests, we might suffer from many other bugs.

Believe it or not, but the X.Org keyboard handling and input system is not at all stable, it's in more flux than ever. Eventually it might be very nice with MPX and everything, but the fact is that today, there are numerous problems both with XKB as well as the classical events.

Before going further, I need to explain more in depth the major differences between my method and the current one:

Wow, that was a lot of text...

So, to summarize:
Even if I'm using XKB as a basis to export new keymaps using my perl script, we really aren't doing anything related
to XKBlib or using any functions from it. The keycode -> virtual keycode -> scan code mapping is all done using my
code. We're not doing anything complex here. The only bugs that could affect us related to XKB would be a bug in the
keycode -> symbolic key code maps. My mapping of symbolic key codes to virtual key codes in my perl script is as
complete as I could make it. If a bug is found in my perl script, it is trivial to fix and re-export the database.

A quick summarize from my point of view: I'm positive to try to use the information in the XKB database. The idea of generating keymaps from it using a perl script or similar is nice. This way, however, we should in principle be able to keep the current keyboard implementation as-is. We could add minor enhancements say trying to detect the keyboard layout using XKB if available and things like that, but this would be small, independent enhancements that will work with the existing keymap format and existing keymaps.

Is there any reason why this approach cannot be used?

Patches must be small and reasonable atomic if I should be able to accept them with good confidence. I've downloaded your modified version and unpacked it over an existing rdesktop working copy, and the result is a "diff" which is 2693 lines long, and I haven't even included the "xkb" subdirectory. This is a lot. Small is beautiful.

Regards, ---
Peter Åstrand           ThinLinc Chief Developer
Cendio AB     
Wallenbergs gata 4
583 30 Linköping        Phone: +46-13-21 46 00