typing the pipe symbol on finnish keyboard produces wrong character about xpra HOT 14 CLOSED

2011-08-04 10:28:38: lindi commented

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

from xpra.

2011-08-04 10:38:26: lindi commented

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

from xpra.

2011-08-04 12:10:59: lindi commented

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

from xpra.

2011-08-05 17:15:04: antoine commented

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

from xpra.

2011-08-06 16:33:44: antoine commented

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..

from xpra.

2011-08-10 16:35:13: lindi commented

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.

from xpra.

2011-08-10 18:24:01: antoine changed status from new to accepted

from xpra.

2011-08-10 18:24:01: antoine commented

Replying to [comment:6 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!

from xpra.

2011-08-14 23:44:01: antoine commented

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.

from xpra.

2011-08-15 10:14:46: lindi commented

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

from xpra.

2011-08-15 14:10:09: antoine changed status from accepted to closed

from xpra.

2011-08-15 14:10:09: antoine changed resolution from ** to fixed

from xpra.

2011-08-15 14:10:09: antoine commented

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

from xpra.

2012-02-20 19:52:37: totaam

from xpra.