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
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
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
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
r122 restores the code which guesses the keyboard layout when "setxkbmap -query" cannot be used.
if this does not restore the missing pipe key, please provide:
setxkbmap -print
" and "setxkbmap -query
" (on client)
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.
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!
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.
I can verify that with r130 all my keys appear to work, thanks!
this code will be in the next release, once tested on MS Windows and Mac OS X.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/7