I have a feeling that I'm getting terribly misunderstood. In case my wording wasn't correct, I was referring to "XKB keynames" with the words "symbolic key names".

Ilya, I agree with you except for using the XKB API. Let me explain what my code is doing:

I made a perl script that reads the keycode -> XKB keynames. I understand the power of XKB key names, they provide a hardware independent naming for keys, somehow like virtual key codes. That is what we want to use, and not key syms. The reason why I am converting these maps to a different format is because XKB key names have to be mapped to virtual key codes so that they can be used more conveniently with rdesktop. So, my perl script exports part of the XKB maps to keycodes -> virtual key codes maps that are ready to be used by rdesktop, completely independent of an XKB-aware X server.

When we initially discussed this a few months ago, many people have expressed their concern that rdesktop should remain compatible with systems that do not have XKB. Instead of having one way for XKB-aware systems and a different one for those that have, I thought of a consistent one that would work for both. What I came up with was the idea of using only a small part of the maps of XKB in an easy to use format, and that I would write my own parsing functions to load it. This way, a system without XKB would be able to use my code without any problem, because we simply aren't depending on XKB or anything from the XKB API.

So, to clarify the obvious misunderstandings:

I am NOT adding any dependency on XKB, or using the XKB API or anything.

I am using the XKB key names, the names that make abstraction of the hardware itself to bring consistent naming of the keys. These are mapped to virtual key codes when the key maps are exported from the XKB configuration database. These new maps should then be included with rdesktop, they really don't take space and it allows us to support systems without XKB.

When rdesktop starts, it tries to detect the current keyboard type, and also the current keyboard layout. Keyboard layout detection is only used to announce to the server what keyboard layout to use. Keyboard _type_ detection is used to load the corresponding keycode -> virtual key code map.

So, once the keycode -> virtual key code map is loaded, rdesktop is able to map each keystroke directly to a virtual key code. The virtual key code is then mapped to a scan code that is sent. I suggest you take a look at my source code, especially keyboard.h and xkbkeymap.c, it should clarify things.

On Fri, May 15, 2009 at 10:49 AM, Ilya Konstantinov <future@shiny.co.il> wrote:
On Fri, May 15, 2009 at 5:34 PM, Peter Ĺstrand <astrand@cendio.se> wrote:


Guys, I don't know why you insist on completely *missing* the one main thing which XKB gives you:reliable (runtime)
[ X11 keysym -> hardware key ] mapping

Well, basically I don't know how XKB works or what kind of capabilites it has. I'm planning to try to learn it, but digging through the 155 pages XKB protocol specification doesn't sound like much fun...

So there, I'm giving you a rundown :)

In any case, I wouldn't start with the spec. The spec is the API reference when using libXkb. Just to understand the architecture, I'd read Ivan Pascal's doc:
http://pascal.tsu.ru/en/xkb/internals.html

Instead, you choose to focus on locales, languages, keyboard names and variants and whatnot. Why? There is no need to know whether the keyboard is English or Lithuanian,

Perhaps not for sending a suitable scancode, but one needs to tell the remote desktop which keymap to use.

Yes, you're referring to the "secondary keyboard language LCID" in the RDP init packet.
You can do this through heuristics, e.g. by parsing the _XKB_RULES_NAMES root window property. (You don't need the XKB API for that.)
Without XKB, you can determine it from the locale.

It's a best-effort guess thing, really. It has nothing to do with keyboard mapping; it's just about trying to pass a piece of the local user preferences to the remote machine, to provide a more familiar desktop on the remote machine.

Simply do this:
1. Read the XKB *keyname* -> X11 keycode (NOT keysym) mapping (dynamically from the server - use the XKB API)
2. Reverse it (make it a keycode->keyname map)
3. Write a mapping (even statically, in code!) which maps XKB *keynames* to AT (RDP) scancodes. This mapping should
be used instead of the rdesktop keymap facility.

So basically, you want the rdesktop keymaps to map "XKB keynames to scancodes", instead of "keysyms to scancodes"? I guess that's possible. But what should rdesktop do with Xservers that doesn't support XKB?

When the XKB extension is not available, we should fall back to the existing facility (the one which uses rdesktop keymap files).