Xpra version 0.15 on both server and client.
To reproduce:
xpra start :178 --input-method=uim --no-speaker --no-microphone --no-clipboard --start-child=xterm --start-child=chromium-browser -d keyboard
C:\Program Files (x86)\Xpra>start Xpra attach ssh:meingbg@x.uxu.se:178 -d keyboard
ÅÄÖåäö[]|ÅÄÖåäö[]|
repeatedly, alternating between xterm and chromium-browser.
Expected:
The visible entered text in both applications will be ÅÄÖåäö[]|ÅÄÖåäö[]|
after each time it is entered.
Actual:
The first few times, the visible entered text in will be ÅÄÖåäö[]|ÅÄÖåäö[]|
in both applications.
However, after a few repetitions, the visible text in chromium will be ||
, and in xterm ÅÄÖåäöÛÝü
.
Btw, logs form both ends are included, with -d keyboard.
(setting milestone)
Important data I found in the bug report zip file:
@mnbvc: is this correct? how do I set my windows keyboard to 'se'? How do I press those keys? (preferably specifying their exact location on a standard pc105 keyboard since I'm not going to have a 'se' keyboard at hand)
Can you please also try the latest beta (client and/or server) to see if it helps in any way?
Does it look like this one? http://johanegustafsson.net/projects/swerty/images/swerty.svg
Replying to antoine:
Important data I found in the bug report zip file:
- client OS: Windows Vista?
- server OS: Ubuntu 14.04
- keyboard layout: se
@mnbvc: is this correct?
Yes.
how do I set my windows keyboard to 'se'?
How to set your windows keyboard to 'se' on windows vista: Open control panel, search for "language", under heading "national settings and..." select "switch keyboard or other input devices". Go to tab "keyboards and language", click "switch keyboard". On tab "general", click "add". In the list, select "swedish (sweden)", "keyboard layout", "swedish". Click OK. Now, back on tab "general", there should be a selection box for "standard input language". Select "Swedish (Sweden) - Swedish". Click ok. Click ok.
How do I press those keys? (preferably specifying their exact location on a standard pc105 keyboard since I'm not going to have a 'se' keyboard at hand)
My guess is that the right Alt key on your keyboard is what becomes the "Alt Gr" key. You can confirm this by opening notepad and press for example AltGr?+7 to produce a "{". This will also confirm that swedish layout is active for newly created windows, which is what you'll need to reproduce the bug.
To write "ÅÄÖåäö" using US hardware and swedish software settings, press Shift+[ Shift+' Shift+; [ ' ;. Without swedish settings, this is what normally would produce the six-character string {":['; using a US keyboard. To write "[]" with swedish software settings, press AltGr?+8 AltGr?+9. I'm not sure how to write "|" on a US keyboard with swedish settings, but you could try AltGr?+| or AltGr?+` (the key to the left of 1), if it turns out not to be possible I hope the other characters are enough for debugging.
Can you please also try the latest beta (client and/or server) to see if it helps in any way?
Will do asap. Will update with results.
Does it look like this one?
No. The keyboard looks like this:
For my own reference, here's a US layout:
As per #817, I can now also test by changing the keyboard layout at runtime.
Keys (on UK Layout) | US Layout | UK Layout | Swedish Layout |
---|---|---|---|
Shift + [ | { | { | Å |
Shift + ' | " | @ | Ä |
Shift + ; | : | : | Ö |
[ | [ | [ | å |
' | ' | ' | ä |
; | ; | ; | ö |
8 | 8 | 8 | [ |
9 | 9 | 9 | ] |
AltGr? + \ | (unknown) | (nothing) | | |
Doing the same in an xpra session gives the same result.
Here's a simplified -d keyboard
log for those 6 key presses (grepped for "pressing"):
handle keycode pressing 50: key Shift_L handle keycode pressing 34: key Aring handle keycode unpressing 34: key Aring handle keycode pressing 48: key Adiaeresis handle keycode unpressing 48: key Adiaeresis handle keycode pressing 47: key Odiaeresis handle keycode unpressing 47: key Odiaeresis handle keycode unpressing 50: key Shift_L handle keycode pressing 34: key aring handle keycode unpressing 34: key aring handle keycode pressing 48: key adiaeresis handle keycode unpressing 48: key adiaeresis handle keycode pressing 47: key odiaeresis handle keycode unpressing 47: key odiaeresis
@mnbvc: I couldn't make it misbehave, what do I need to do to break it?
If you can reproduce it, the -d keyboard
log should be showing some sort of event when that happens.
(managed to reproduce it)
The problem comes from this sequence of keypresses when we press AltGr
:
handle keycode pressing 138: key Alt_R make_keymask_match(('mod5',)) current mask: set(['mod1']), wanted: set(['mod5']), ignoring=94/['bar'], keys_pressed={138: 'Alt_R'} found the key pressed for mod1: Alt_R make_keymask_match(remove) ('mod5',) modifier mod1 using 138, success: True keynames(mod5)=set(['ISO_Level3_Shift', 'Mode_switch']), keycodes=[113, 124, 8], nuisance=False make_keymask_match(add) ('mod5',) modifier mod5 using 113, success: True
So we press Alt_R
then unpress it, then press "mod5"...
That's because of this nasty piece of code I wrote a long long time ago to workaround AltGr
on 'fr' layouts: xpra/platform/win32/keyboard.py..
So r11246 makes it possible to disable this code completely by setting this environment variable before running the win32 client:
set XPRA_EMULATE_ALTGR=0 Xpra_cmd.exe attach ...
With this in place, I am unable to reproduce this particular bug... but I am also unable to type |
...
@mnbvc: there is a windows beta build available with this change, is this an improvement for you?
I could backport part of this to v0.14.x, and maybe even consider making this the default if I can find a better workaround for the 'fr' layout and missing |
.
Could also be related to #62, #602, #923, #759, #108
I believe that r11247 fixes this bug (see #923). I can type all the characters including |
and the keyboard no longer gets wedged in a bad state.
This is a server side fix, I will be making new test builds shortly.
@mnbvc: please let me know if that fixes things for you.
Not heard back, closing. Feel free to re-open if this is still a problem.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/824