xpra erroneously sends meta key from windows

[tyler]

alt-meta is being sent to intellij when using the alt key. On x11, the alt key works as expected.

In emacs, gnome-terminal, and I assume others the meta key is stuck on after pressing windows-left (or any direction). Pressing windows twice after that un-sticks the meta key. Also not a problem in x11.

If I log the keys from xev, a single press of the left direction key yeilds a sequence of about 10 KeyRelease and KeyPress events for Alt_L, Alt_R, Meta_L, and finally a release for Left. The final events for the modifier keys are all presses.

The intellij break happens no matter what and cannot be fixed by pressing the windows key twice.

[Antoine Martin]

Key mapping, and Alt / Meta in particular is really difficult to get right.
10 key events is quite excessive!

[tyler]

Also when I launch intellij (or any program) from win-switch on the linux box everything is upside-down and mirrored.

You can see in the flipped.png I attached alt-u is being sent as alt-meta-u as well.

[Antoine Martin]

Oh!

That's got to be the weirdest bug I've seen in a long time!
Could this be opengl related? Can you try turning it off to see if it helps?

[tyler]

yes, disabling opengl does fix the mirroring problem. Now I just need to figure out how to make that the default for winswitch!

When starting some programs (like terminal) I get the following error when OpenGL is enabled:

Gdk-ERROR **: The program 'Xpra' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 1072 error_code 8 request_code 72 minor_code 0)

The alt key still produces an alt-meta for intellij though =(. Running xen from the linux box to the linux box does not report that the meta key is being pressed at all.

[Antoine Martin]

Please provide the opengl information, from the bug report tool or from the gl_check.py utility.
Then we can make it disabled by default on this broken driver.

[tyler]

libGL error: failed to load driver: nouveau
libGL error: Try again with LIBGL_DEBUG=verbose for more details.
2014-12-10 09:34:44,470 OpenGL_accelerate module loaded
2014-12-10 09:34:44,470 Using accelerated ArrayDatatype
2014-12-10 09:34:44,471 
2014-12-10 09:34:44,471 
2014-12-10 09:34:44,471 OpenGL properties:
2014-12-10 09:34:44,471 * GLU extensions           : GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess 
2014-12-10 09:34:44,471 * GLU version              : 1.3
2014-12-10 09:34:44,471 * display_mode             : ALPHA, SINGLE
2014-12-10 09:34:44,471 * gdkgl_version            : 1.4
2014-12-10 09:34:44,471 * gdkglext_version         : 1.2.0
2014-12-10 09:34:44,471 * has_alpha                : True
2014-12-10 09:34:44,472 * opengl                   : 2.1
2014-12-10 09:34:44,472 * pygdkglext_version       : 1.1.0
2014-12-10 09:34:44,472 * pyopengl                 : 3.1.0
2014-12-10 09:34:44,472 * renderer                 : Software Rasterizer
2014-12-10 09:34:44,472 * rgba                     : True
2014-12-10 09:34:44,472 * shading language version : 1.20
2014-12-10 09:34:44,472 * vendor                   : Mesa Project
2014-12-10 09:34:44,472 * zerocopy                 : False

[Antoine Martin]

r8233 will disable opengl automatically when we detect the "Software Rasterizer" - I may backport this to v0.14.x
I just hope that we're not unnecessarily penalizing other users.. can you tell us which distro and version you are using?
The big libGL error:... warnings are ominous.

Until then, you can turn off opengl by default on those systems using:

echo "opengl=no" >> ~/.xpra/xpra.conf

Note: we have digressed somewhat, this ticket was originally about key presses. And I still need to look into that.

[tyler]

Red Hat Enterprise Linux Workstation release 6.4 (Santiago)

Yes, sorry for the digression. Probably should have split into 2 issues when I realized they weren't related.

[tyler]

I updated xpra on windows and linux with today's release. The meta key problem is fixed in intellij on linux, but from windows left alt-a sends alt-meta-A and right alt-a sends alt graph-A

[Antoine Martin]

There have not been any fixes to the keyboard code since 0.14.9.

So the problem may not be fixed, just not triggered yet after you re-installed.

[Antoine Martin]

Backported the blacklisting of the "Software Rasterizer" in r8252.

[Antoine Martin]

I believe many of the extra keys that were being pressed were because we had various bugs in the forwarding and parsing of the keyboard data structures - these should be fixed by r8477 + r8475 + r8474 (which will be backported to the 0.14.x branch).

As for AltGr, this is a tricky one (see #62) and I am very reluctant to go anywhere near it unless it can be proven to be a real blocker for something.

tyler: can I close this ticket?

[tyler]

left alt key seems to be working, that's enough for me. Close away.

[skew4]

In which version was this bug fixed? I just upgraded my Windows client to 0.15.2 and it is still very much there (I'm referring to the bug in the description, not the OpenGL noise in the middle).

This bug triggers every time I use an Aero Snap keyboard shortcut (e.g.: win+left or win+right) to snap an Xpra window. If that window is xev then I can see the crazy modifiers listed in the original description. These modifiers can have very surprising and not desired effects.

Hitting the Windows key alone put things back in order. So does switching focus to some other window (Xpra or not) and back.

I'm brand new to Xpra and very impressed by it except for this bug. Please let me know what I can do to help.

[Antoine Martin]

As per comment:14, the bug is still there?

[Antoine Martin]

@skew4: you can help by providing logs with -d keyboard from both client and server, limited to just when pressing the problematic keys so we don't have thousands of lines to parse through.

[skew4]

The problem went away and it just re-appeared suddenly without me doing anything unusual, just using Xpra normally.

Server keyboard log just attached. Log timeline:

• The trigger: Windows+Left (aero snap)
• 10 seconds later, I press 'f'. Does not work
• A bit later, I press 'g'. Still does not work.
• A bit later, I move the mouse inside the window. The keyboard log goes crazy, whereas mouse movement normally shows nothing in this log.
• A bit later, I press the Windows key again but alone this time. This always make the problem go away.
• 'f' works.
• 'g' works.

Sorry I could not find how to enable logs on my Windows client, where I suspect the problem lies? My client log file is almost empty and does not grow at all while this is bug happening (or... ever). Is there something I can drop in my session file maybe? Or even better, is there a way to enable debug on the Windows client at run time without restarting like I found on the server?

I could also use logging category suggestions.

[Antoine Martin]

That's interesting - definitely something fishy going on here, and I think I have seen this before:

make_keymask_match(remove) () modifier mod1 using 108, success: False
remove mod1 with keycode 108 did not work - trying to undo it!
make_keymask_match(remove) () modifier mod1 using 64, success: False
remove mod1 with keycode 64 did not work - trying to undo it!
make_keymask_match(remove) () modifier mod1 using 205, success: False
remove mod1 with keycode 205 did not work - trying to undo it!
make_keymask_match(remove) () modifier mod1 using 204, success: False
remove mod1 with keycode 204 did not work - trying to undo it!
handle_key(132,True,f,102,41,()) keyboard_sync=True

We try and try again to unset mod1, and fail...
Here's what I've got in your 7 months old xpra info (found in the bug report zip file) - maybe you can post a more up to date xpra info?

keyboard.modifier.mod1.client_keys : (((18, 'Alt_L'), 'Alt_L'), ((92, 'Alt_R'), 'Alt_R'), ((91, 'Alt_L'), 'Alt_L'), ('Alt_L', 'Alt_L'), ((164, 'Alt_L'), 'Alt_L'), ((165, 'Alt_R'), 'Alt_R'), ('Meta_L', 'Meta_L'))
keyboard.modifier.mod1.keys      : ('Meta_R', 'Alt_R', 'Meta_L', 'Alt_L')

Can you post from the server:

• xmodmap -pke
• xmodmap -pm

[skew4]

Info requested attached. Please delete the -1-2.txt file if you can, it's just a mis/doubleclick/duplicate.

Note the original zip file/config wasn't from me, I found this old bug only recently.

There seems to be a couple of other ways to recover from the bug besides the Windows key, but so far it's the simpler and faster.

Do you not need the keyboard logs on the client too? I could use some guidance/Windows FAQ here.

And... too late! The bug just disappeared after disconnection/reconnection. Gone; at least for now. Curious: does the Windows launcher completely restarts the whole client on disconnections? For sure the server wasn't.

Note: I tend to be using different keyboard layouts + Keyla (laptop vs docking station mismatch - don't ask). Could that matter? I use Keyla because Windows 7 keyboard layouts are a real pain: ​http://superuser.com/questions/13324/switching-keyboard-layout-in-windows-globally
Next time this happens I'll kill Keyla to see if it makes any difference. Probably not since I must be one of the only 3-4 people using Keyla in the whole world and this bug was filed by someone else.

[Antoine Martin]

Thanks for the data.

• mod1 is:

  mod1        Alt_L (0x40),  Alt_R (0x6c),  Alt_L (0xcc),  Meta_L (0xcd)
  

Which matches what we expect from comment:18.
The keycodes we try to press (108, 64, 205, 204) are the same too. (just shown in hex by xmodmap)

• and the keycodes also match what we expect:

  keycode  64 = Alt_L Meta_L Alt_L Meta_L Alt_L Meta_L
  keycode 108 = Alt_R Meta_R Alt_R Meta_R Alt_R Meta_R
  keycode 204 = Alt_L NoSymbol Alt_L NoSymbol Alt_L
  keycode 205 = Meta_L NoSymbol Meta_L NoSymbol Meta_L
  

I have no idea why virtually unpressing those keys doesn't unset mod1. This should work.

Since the problem goes away when you press the windows key, maybe you can capture the -d keyboard output of when you press it?

Note: I tend to be using different keyboard layouts + Keyla ...

Please mention this first, this may or may not be related, but it is highly relevant to the bug. At least it gives a clue. Could be a key that is pressed with one layout, and does not exist in the new layout.

[skew4]

The bug came back in force. After disconnecting and reconnecting it still happens every time. Next I killed and restarted the Xpra client and it's gone again.

The log attached does cover the Windows key workaround near the end of it, see the timeline in comment:17

Another, confirmed way to "unstick" the modifier is to click on any non-Xpra window.

Sorry about Keyla. I just killed it and it makes no difference. I actually use four layouts, sorry I should have mentioned that too: US, US-international, UK, UK-extended. I'll go down to just US and see if it helps.

(you're still not interested in Xpra *client* logs?)

[Antoine Martin]

(you're still not interested in Xpra *client* logs?)

I am always interested in logs, preferably trimmed ones.
Especially those with -d keyboard.

[skew4]

So, some news:

I disabled Keyla, kept only one layout, logged out and back in and the bug is still very much there.

I finally inferred that I could just drop: debug=keyboard in the session file on the client side. Surprise: everything looks fairly normal in the client log file to my ignorant eye. Timeline of the client log file (a few blank lines added, nothing removed)

• press f, g: everything's fine
• Windows+Left (or right) to trigger the bug
• press f, g: does not work, modifier madness
• Windows key to unstick the modifier
• press f, g: works fine again

[Tim Brown]

I'm also experiencing this problem, but on (Ubuntu Trusty) Linux.

Specifically when using the Intellij IDE and I press <alt>+<anything> it gets received as <alt>+<meta>+<anything>. When I use xev, it looks like <meta> is _not_ sent, so the issue might be limited to Intellij (or java or something).

I have attached server and client logs from using -d keyboard. I only pressed <alt>+<f7> and nothing else. I left all the keymap stuff at the beginning of the logs in case they are useful.

Any ideas about what might be going wrong?

[Antoine Martin]

@stimut: your log files look just fine, so this may be a different problem:

handle keycode pressing 64: key Alt_L
handle keycode pressing 73: key F7
handle keycode unpressing 73: key F7
handle keycode unpressing 64: key Alt_L

No idea why applications would see other keys in this case!

---

@skew4: your bug also looks different from the original bug in this ticket, a bit more similar to #814 in fact.

I finally got around to testing this on a Windows 7 box, and I see what "Windows+Left" and "Windows+Right" do. I can't seem to trigger the bug yet, but it sounds similar to some problems we have had before with Alt+Tab on various platforms: the key is trapped by the OS which then does the window resizing (or whatever), at which point we may lose the keyboard input and not realize the key has been unpressed. This may also have something to do with the multiple layouts. If I can reproduce it somehow, I should be able to fix it.. easier said than done. Do you have any clues with regards to the multiple keyboard layouts and how I should set things up to reproduce?

Can you please also try the ​latest beta (client and/or server) to see if it helps in any way?

[Antoine Martin]

Unless someone can give me steps to reproduce with win7, I will have to close this ticket as "worksforme".

[skew4]

@antoine: unfortunately I'm not using xpra right now since a distro upgrade broke it somehow, didn't find the time to investigate how yet. I fell back on Cygwin/X.

My issue wasn't reproducible all the time but I'm fairly sure I saw it even with a single keyboard layout.

Unless Trac doesn't allow re-opening issues feel free to close.

[migration script]

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