Keymap issues with matching keyboard layouts

[GoogleCodeExporter]

I cannot reproduce this in a new instance of xpra, however I have an 
instance running which is exhibiting this behaviour and can therefore run 
tests on it.

The symptom is that the following keys: <>|\@{}[] have become the 
following, respectively: ZX¬-Q&)89

This is the case on all applications I've tested with, and regardless of 
connection point - on the server or elsewhere. The both machines have the 
same language and keyboard settings ($LANG=en_GB.UTF-8, 
$GDM_KEYBOARD_LAYOUT=gb).

Trying to reproduce this, all I could get was that after running xterm 
twice on the xpra display, Alt_L would appear to be held down and so odd 
characters would be printed from most keys. Pressing Alt_L fixes this, but 
not the original problem.
Of note is that, on my keyboard layout, < (shift+comma) is replaced with Z,  
and if I press AltGr (ISO_Level3_Shift) Shift and Z, I get a < - the same 
pattern works for all keys. If I AltGr and the character that displays when 
I hit one of the dodgy keys, I get the character I want.

xmomdap -pk reports a slightly different layout - but nothing for the 
normal punctuation keys that are affected.

Original issue reported on code.google.com by thefishf...@gmail.com on 26 Apr 2010 at 2:32

[GoogleCodeExporter]

Further testing shows that this happens if you enable GTK themes with the by 
starting 
xpra with dbus and gnome-settings-daemon, but not otherwise.

I'm not sure why this is. After some more poking, I discovered the root cause 
of the 
problem - server.py:435

 return self._keymap.get_entries_for_keyval(keyval)[0][0]

This will fail if get_entries_for_keyval returns more than one keycode for a 
given 
keyval - i.e. in my case if you look up the keyval '60' (for '<') then it 
returns the 
following:

 ((52, 0, 3), (59, 0, 1))

This is because you can either obtain the < symbol from the z-key at keyboard 
level 
3, or from the comma key at level 1.
I've looked at the code and it looks like it will be complicated to determine 
what 
the current group and level are. XKB defines rules for working this out and you 
can 
print them with xkbcomp, but I don't know how to access this stuff with GDK.

An immediate work-around is to remove duplicate keys from your keymap, or to 
just use 
some kind of generic rule for determining the keyboard level, and ignore the 
group. 
This would probably solve it for one type of keyboard only, though.

Original comment by thefishf...@gmail.com on 27 Apr 2010 at 6:08