On Mon, May 18, 2009 at 2:34 AM, Peter Ĺstrand <astrand@cendio.se> wrote:
On Sat, 16 May 2009, Marc-André Moreau wrote:

3) Once the keycode->virtual key code map is loaded, I use keycodes at run time and map them to virtual key codes,
then to scan codes. ANY X program receives the keycodes. Look in xwin.c.

Sure, but that doesn't mean that they are usable.

keycodes alone are unreliable as they are
hardware dependent, but that was the whole point of using the XKB *database* to map them a consistent naming system
(XKB key names / virtual key codes).

The problem is just that you are using one mapping at build time (the XKB database) but another at runtime (the current Xserver keyboard mapping). This means that you cannot trust that the keycodes are the same: They can differ in a number of cases: When the used version of the XKB database differs, when you are running another platform at runtime (say, Solaris), when you move between "normal" and "evdev" systems, if you use Xvnc etc etc.

For a normal application, looking at the "keycode" is simply a big no-no.

Using the "keysyms" is the preferred approach; works on all platforms.

No, no! You're missing the point again. Please understand that keysyms are already translated according to the local keyboard layout and that we do NOT want to deal with them. keycodes are codes that correspond to one key on the keyboard, but the code may differ according to your keyboard. That is where XKB keynames are used: keycodes are mapped to an XKB keyname that is consistent for all keyboards. the XKB keynames are then used by XKB to correctly map a keycode to a keysym. If you're thinking of using keysyms, you're doing it wrong. What you need is the map from keycode (inconsistent) to XKB keynames (consistent). My code already uses that, and does not depend on XKB _at all_. The maps are included with rdesktop so that you do not rely on XKB. It works on all platforms, and better than with keysyms.

To summarize:

keycodes: inconsistent numbers corresponding to a key on a keyboard

XKB keynames: _consistent_ naming of keys on a keyboard

keysym: resulting character that corresponds to a keystroke, and varies according to the keyboard layout.

Sorry if I'm losing my patience a little bit, but I don't understand why you keep arguing on this when all you have to do is take a look at my source code and what I've done. I carefully thought of all of this. My solution should satisfy both of you if you at least cared a little more about trying it.

exporting keycode -> XKB keynames maps to keycode -> virtual key code maps and then including that with rdesktop is definitely the most efficient way to do it that won't depend on XKB at all.

It provides a consistent and reliable way to do it, independently of any XKB installation. Remember, we're just using an exported version of the data, and nothing from the XKB API. It works on systems that do not have XKB installed. And it works better than using keysyms which are already translated according to the keyboard layout.

Another simple argument against keysyms: for instance, you have an azerty keyboard. It doesn't matter if you have an azerty keyboard, you will still have to send the scan codes corresponding to Microsoft virtual key codes. This means that to send 'A', you will have to send 'Q' and it will be interpreted on the server end according to an azerty keyboard layout to result with an 'A'. Now, try to make that kind of translation simple when dealing with that kind of problems. keysyms are already translated according to keyboard layout and we are trying to avoid that, we want the data _raw_. To achieve that we take the scan code and we translate it to a consistent virtual key code, and we send it's corresponding scan code, and that's it. We don't deal with the keysyms or the current keyboard layout at all and we certainly do not want that. keycodes are available on all systems just like keysyms are. look at xwin.c again if you don't trust me.

By the way, microsoft solved the problem of inconsistent keycodes with virtual key codes. on UNIX, they just made a different but equivalent system with the XKB keynames. We're just mapping one system to the other, and it works perfectly. Key 'Q' is still key 'Q', no matter if it is an azerty keyboard with the letter 'A' written on it. This is only meaningful when the key strokes are translated to resulting characters, not before that.