typing the pipe symbol on finnish keyboard produces wrong character

[Timo Juhani Lindfors]

Steps to reproduce:
0) Use finnish keyboard layout
1) xpra start --no-daemon --start-child gnome-terminal --exit-with-children :7 -d all
2) xpra attach ssh:lindi1:7
3) hold altgr down
4) hit <
5) release altgr

Expected results:
5) gnome-terminal shows the pipe symbol

Actual results:
5) gnome-terminal shows some weird unicode character that resembles "i".

More info:
1) I'm using

git-svn-id: ​http://xpra.devloop.org.uk/svn/Xpra/trunk@121 3bb7dfac-3a0b-4e04-842a-767bc560f471

2) relevant xpra debug output:

read thread: got data '"*E\x83\xfb\xab\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x1b08310>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data '"*E\x83\xfb\xab\x00\x00\x00\x00\xff\xff'
got ['key-action', 1, 'ISO_Level3_Shift', 1, []]
now 1pressing keycode=108, keyname=ISO_Level3_Shift
main thread: processed all read data

read thread: got data '\xc2\x97g\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x1b08310>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data '\xc2\x97g\x00\x00\x00\x00\xff\xff'
got ['key-action', 1, 'bar', 1, []]
now 1pressing keycode=31, keyname=bar
main thread: processed all read data
DamageNotify received
  event was delivered to window itself
  not forwarding to WindowModel handler, it has no wimpiggy-damage-event signal
  forwarding event to a CompositeHelper handler's wimpiggy-damage-event signal
damage 1 (88, 170, 20, 20)
writing ['draw', 1, 88, 170, 20, 20, 'rgb24', '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...]
write thread: waiting for data to write
  forwarded
write thread: writing 'B.\xd7,F\xcb5"\x02r\xa0\xd2\x01\x91\xf6b\x1d\x8f$R/\xd6q\xbbQ\xbdX\xcbD\xb4`\x81\x07\x1d\xd6\xe0""Y\x8d\xb8\xba\x87\x980![M*\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._maybe_queue_more_writes of <xpra.protocol.Protocol object at 0x1b08310>>
write thread: waiting for data to write
read thread: got data '\xc2\x97g\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x1b08310>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data '\xc2\x97g\x00\x00\x00\x00\xff\xff'
got ['key-action', 1, 'bar', 0, []]
now 0pressing keycode=31, keyname=bar
main thread: processed all read data

read thread: got data '"\xca\x06\xb0[\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x1b08310>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data '"\xca\x06\xb0[\x00\x00\x00\x00\xff\xff'
got ['key-action', 1, 'ISO_Level3_Shift', 0, []]
now 0pressing keycode=108, keyname=ISO_Level3_Shift
main thread: processed all read data

[Timo Juhani Lindfors]

Just for reference. The finnish keyboard layout:

​http://en.wikipedia.org/wiki/File:KB_Finnish_Multilingual.svg

It seems that if I use the left GUI key (aka "Windows key") instead of altgr I can produce the pipe symbol:

read thread: got data '"\xe4\x1c\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x28c1310>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data '"\xe4\x1c\x00\x00\x00\x00\xff\xff'
got ['key-action', 1, 'Super_L', 1, []]
now 1pressing keycode=133, keyname=Super_L
main thread: processed all read data

read thread: got data '"\xc69\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x28c1310>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data '"\xc69\x00\x00\x00\x00\xff\xff'
got ['key-action', 1, 'less', 1, ['super']]
now 1pressing keycode=94, keyname=less
main thread: processed all read data
DamageNotify received
  event was delivered to window itself
  not forwarding to WindowModel handler, it has no wimpiggy-damage-event signal
  forwarding event to a CompositeHelper handler's wimpiggy-damage-event signal
damage 1 (600, 0, 20, 20)
writing ['draw', 1, 600, 0, 20, 20, 'rgb24', '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...]
  forwarded
write thread: waiting for data to write
write thread: writing "B*\xd6\xcc\x0cF\xa7\x0cF\x8b\xb5\xd1bm\xb4X\x03\x85\x001k,H\x9aa'\xc6@j\xa9I\x05\x00\x00\x00\xff\xff"
Queueing main thread call to <bound method Protocol._maybe_queue_more_writes of <xpra.protocol.Protocol object at 0x28c1310>>
write thread: waiting for data to write
read thread: got data '"\xc69\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x28c1310>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data '"\xc69\x00\x00\x00\x00\xff\xff'
got ['key-action', 1, 'less', 0, ['super']]
now 0pressing keycode=94, keyname=less
main thread: processed all read data

read thread: got data '"\xd29\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x28c1310>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data '"\xd29\x00\x00\x00\x00\xff\xff'
got ['key-action', 1, 'Super_L', 0, ['super']]
now 0pressing keycode=133, keyname=Super_L
main thread: processed all read data

[Timo Juhani Lindfors]

Just for completeness I ran the client with "-d all" as well and used altgr:

KeyPress event received
  event was delivered to window itself
  no handler registered for this window, ignoring event
writing ['key-action', 1, 'ISO_Level3_Shift', True, []]
Queueing main thread call to <bound method Protocol._maybe_queue_more_writes of <xpra.protocol.Protocol object at 0x8f987ac>>
write thread: waiting for data to write
write thread: writing '"J%\xd8-\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._maybe_queue_more_writes of <xpra.protocol.Protocol object at 0x8f987ac>>
write thread: waiting for data to write

KeyPress event received
  event was delivered to window itself
  no handler registered for this window, ignoring event
writing ['key-action', 1, 'bar', True, []]
Queueing main thread call to <bound method Protocol._maybe_queue_more_writes of <xpra.protocol.Protocol object at 0x8f987ac>>
write thread: waiting for data to write
write thread: writing '\xc2\xe7\x16\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._maybe_queue_more_writes of <xpra.protocol.Protocol object at 0x8f987ac>>
write thread: waiting for data to write
read thread: got data 'B.\xd5,\xc0U\xf9h\xa9\x86/\x04\x07*\x15\x10i\xefh\xa9Fj\x9b\x80\xbc\x92x\xb4T#5\x9cI*\x96(T\x9c\n\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._handle_read of <xpra.protocol.Protocol object at 0x8f987ac>>
read thread: waiting for data to arrive
main thread: woken to handle read data
main thread: found read data 'B.\xd5,\xc0U\xf9h\xa9\x86/\x04\x07*\x15\x10i\xefh\xa9Fj\x9b\x80\xbc\x92x\xb4T#5\x9cI*\x96(T\x9c\n\x00\x00\x00\xff\xff'
got ['draw', 1, 88, 0, 20, 20, 'rgb24', '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...]
main thread: processed all read data
writing ['key-action', 1, 'bar', False, []]
Queueing main thread call to <bound method Protocol._maybe_queue_more_writes of <xpra.protocol.Protocol object at 0x8f987ac>>
write thread: waiting for data to write
write thread: writing '\xc2\xe7\x16\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._maybe_queue_more_writes of <xpra.protocol.Protocol object at 0x8f987ac>>
write thread: waiting for data to write

writing ['key-action', 1, 'ISO_Level3_Shift', False, []]
Queueing main thread call to <bound method Protocol._maybe_queue_more_writes of <xpra.protocol.Protocol object at 0x8f987ac>>
write thread: waiting for data to write
write thread: writing '"\xca\x06\xb0[\x00\x00\x00\x00\xff\xff'
Queueing main thread call to <bound method Protocol._maybe_queue_more_writes of <xpra.protocol.Protocol object at 0x8f987ac>>
write thread: waiting for data to write

[Timo Juhani Lindfors]

With

--- a/src/xpra/client.py
+++ b/src/xpra/client.py
@@ -267,6 +267,7 @@ class ClientWindow(gtk.Window):
     def _key_action(self, event, depressed):
         modifiers = self._client.mask_to_names(event.state)
         name = gtk.gdk.keyval_name(event.keyval)
+        log.debug("_key_action: name=%s keyval=%s state=%s" % (repr(name), repr(event.keyval), repr(event.state)))
         # Apparently some weird keys (e.g. "media keys") can have no keyval or
         # no keyval name (I believe that both give us a None here).  Another
         # reason to overhaul keyboard support:

I see

_key_action: name='ISO_Level3_Shift' keyval=65027 state=<flags 0 of type GdkModifierType>
_key_action: name='bar' keyval=124 state=<flags GDK_MOD5_MASK of type GdkModifierType>
_key_action: name='bar' keyval=124 state=<flags GDK_MOD5_MASK of type GdkModifierType>
_key_action: name='ISO_Level3_Shift' keyval=65027 state=<flags GDK_MOD5_MASK of type GdkModifierType>

and with

--- a/src/wimpiggy/lowlevel/bindings.pyx
+++ b/src/wimpiggy/lowlevel/bindings.pyx
@@ -1407,6 +1407,8 @@ cdef GdkFilterReturn x_event_filter(GdkXEvent * e_gdk,
                     pyev.window = _gw(d, e.xany.window)
                     pyev.hardware_keycode = e.xkey.keycode
                     pyev.state = e.xkey.state
+                    log(pyev.hardware_keycode)
+                    log(pyev.state)
                 elif e.type == damage_type:
                     log("DamageNotify received")
                     damage_e = <XDamageNotifyEvent*>e

I see

108
0

94
128

108
0

when I hit altgr. This is:

oregano:~$ xmodmap -pke|grep " 94 "
keycode  94 = less greater less greater bar brokenbar
oregano:~$ xmodmap -pke|grep "128 "
keycode 128 =

But note that

oregano:~$ xmodmap -pke|grep 124
keycode 124 = XF86PowerOff NoSymbol XF86PowerOff

[Antoine Martin]

r122 restores the code which guesses the keyboard layout when "setxkbmap -query" cannot be used.

[Antoine Martin]

if this does not restore the missing pipe key, please provide:

• "setxkbmap -print" and "setxkbmap -query" (on client)
• the last svn revision which worked correctly (probably r117 or r120)
• with latest r122, the output from the client and server log file (info level should suffice - no need to hit any keys yet)
• anything else you think might help..

[Timo Juhani Lindfors]

sauna:~$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+fi+inet(evdev)"	};
	xkb_geometry  { include "pc(pc105)"	};
};

sauna:~$ sid setxkbmap -query
rules:      evdev
model:      pc105
layout:     fi

Nothing really worked correctly out of the box IIRC. With r71 running

 setxkbmap -print | (unset XAUTHORITY; DISPLAY=:7 ssh lindi1 xkbcomp - :7) 

manually works.

[Antoine Martin]

Replying to lindi:

Nothing really worked correctly out of the box IIRC. With r71 running

 setxkbmap -print | (unset XAUTHORITY; DISPLAY=:7 ssh lindi1 xkbcomp - :7) 

manually works.

r72 does exactly that (implemented it after we discussed this on IRC). r88 adds better support for level (shift/caps)
r117 should not make much of a difference and r120 is the one that removes the layout guessing, which is restored in r122.

So I would have expected r88 or r117 to work in your case. If they do not, then I am stumped!

[Antoine Martin]

r127 ensures that the new keymap is applied whenever the user changes the keyboard mapping (no need to re-connect)

r128 brings raw keycode support: if available on the server (we check the remote version), then we send this hardware_keycode (along with some other attributes which are also available and may be useful in the future - they are cheap to send, but changing the protocol is not)

This seems to work very well here, I can even print some unusual characters which I found on the Finish keyboard map picture, like these ones:

ø¡”»«“„<>°¿

The strange thing is that I can't seem to produce them in my regular (not through xpra) terminal session and browser.. no idea why.

Some useful pointers:

• ​gtk.gdk.Keymap
• ​gtk.gdk.KEY_PRESS
• ​Modifierkey and ​what are the-meta super and hyper keys were useful for figuring out which modifier to use for "group" in fallback mode (was hardcoded to 0 previously)

Hopefully this fixes your problem without making anything worse, or breaking someone else's layout like previous releases have done...
I am particularly interested in test reports on systems with old versions of setxkbmap (those which are unable to use setxkbmap -query), as we may have to use fallback mode for those if the keymap is not applied properly.

[Timo Juhani Lindfors]

I can verify that with r130 all my keys appear to work, thanks!

[Antoine Martin]

this code will be in the next release, once tested on MS Windows and Mac OS X.