Xpra: Ticket #7: typing the pipe symbol on finnish keyboard produces wrong character

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


Thu, 04 Aug 2011 09:28:37 GMT - 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

Thu, 04 Aug 2011 09:38:26 GMT - 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

Thu, 04 Aug 2011 11:10:59 GMT - 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

Fri, 05 Aug 2011 16:15:04 GMT - Antoine Martin:

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


Sat, 06 Aug 2011 15:33:44 GMT - Antoine Martin:

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


Wed, 10 Aug 2011 15:35:12 GMT - 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.


Wed, 10 Aug 2011 17:24:01 GMT - Antoine Martin: status changed

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!


Sun, 14 Aug 2011 22:44:00 GMT - 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:

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.


Mon, 15 Aug 2011 09:14:45 GMT - Timo Juhani Lindfors:

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


Mon, 15 Aug 2011 13:10:09 GMT - Antoine Martin: status changed; resolution set

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


Mon, 20 Feb 2012 19:52:37 GMT - Antoine Martin: version, milestone set


Sat, 23 Jan 2021 04:43:03 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/7