#7 closed defect (fixed)
typing the pipe symbol on finnish keyboard produces wrong character
| Reported by: | Timo Juhani Lindfors | Owned by: | Antoine Martin |
|---|---|---|---|
| Priority: | critical | Milestone: | 0.0.7.x |
| Component: | client | Version: | 0.0.7.24 |
| Keywords: | Cc: |
Description
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
Change History (12)
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
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
comment:3 Changed 10 years ago by
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
comment:4 Changed 10 years ago by
r122 restores the code which guesses the keyboard layout when "setxkbmap -query" cannot be used.
comment:6 follow-up: 7 Changed 10 years ago by
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.
comment:7 Changed 10 years ago by
| Status: | new → accepted |
|---|
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!
comment:8 Changed 10 years ago by
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.
comment:10 Changed 10 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | accepted → closed |
this code will be in the next release, once tested on MS Windows and Mac OS X.
comment:11 Changed 9 years ago by
| Milestone: | → 0.0.7.x |
|---|---|
| Version: | → 0.0.7.24 |
comment:12 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/7
copyleft 2010 - 2021
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: