xpra erroneously sends meta key from windows #759

totaam · 2014-12-06T00:00:21Z

Issue migrated from trac ticket # 759

component: client | priority: critical | resolution: worksforme | keywords: keyboard win32

2014-12-06 00:00:21: tyler created the issue

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.

The text was updated successfully, but these errors were encountered:

totaam · 2014-12-06T00:00:40Z

2014-12-06 00:00:40: tyler uploaded file `bug report.zip` (994.3 KiB)

totaam · 2014-12-09T00:38:16Z

2014-12-09 00:38:16: antoine changed status from new to assigned

totaam · 2014-12-09T00:38:16Z

2014-12-09 00:38:16: antoine commented

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

totaam · 2014-12-10T00:00:36Z

2014-12-10 00:00:36: tyler uploaded file `flipped.png` (30.7 KiB)

totaam · 2014-12-10T00:05:34Z

2014-12-10 00:05:34: tyler commented

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

[[Image(flipped.png)]]

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

totaam · 2014-12-10T00:09:01Z

2014-12-10 00:09:01: antoine changed status from assigned to new

totaam · 2014-12-10T00:09:01Z

2014-12-10 00:09:01: antoine changed owner from antoine to tyler

totaam · 2014-12-10T00:09:01Z

2014-12-10 00:09:01: antoine commented

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?

totaam · 2014-12-10T17:26:13Z

2014-12-10 17:26:13: tyler commented

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.

totaam · 2014-12-10T17:29:18Z

2014-12-10 17:29:18: totaam commented

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.

totaam · 2014-12-10T19:22:47Z

2014-12-10 19:22:47: tyler commented

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

totaam · 2014-12-10T23:47:42Z

2014-12-10 23:47:42: antoine changed status from new to assigned

totaam · 2014-12-10T23:47:42Z

2014-12-10 23:47:42: antoine changed owner from tyler to antoine

totaam · 2014-12-10T23:47:42Z

2014-12-10 23:47:42: antoine commented

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.

totaam · 2014-12-10T23:56:42Z

2014-12-10 23:56:42: tyler commented

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.

totaam · 2014-12-11T00:28:10Z

2014-12-11 00:28:10: tyler commented

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

totaam · 2014-12-11T00:31:27Z

2014-12-11 00:31:27: antoine commented

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.

totaam · 2014-12-18T08:47:24Z

2014-12-18 08:47:24: totaam commented

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

totaam · 2015-01-16T08:07:38Z

2015-01-16 08:07:38: totaam changed status from assigned to new

totaam · 2015-01-16T08:07:38Z

2015-01-16 08:07:38: totaam changed owner from antoine to tyler

totaam · 2015-01-16T08:07:38Z

2015-01-16 08:07:38: totaam commented

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?

totaam · 2015-01-16T22:42:25Z

2015-01-16 22:42:25: tyler changed status from new to closed

totaam · 2015-01-16T22:42:25Z

2015-01-16 22:42:25: tyler changed resolution from ** to fixed

totaam · 2015-01-16T22:42:25Z

2015-01-16 22:42:25: tyler commented

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

totaam · 2015-07-06T06:33:31Z

2015-07-06 06:33:31: skew4 commented

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.

totaam · 2015-07-06T06:42:13Z

2015-07-06 06:42:13: antoine changed status from closed to reopened

totaam · 2015-07-06T06:42:13Z

2015-07-06 06:42:13: antoine removed resolution (was fixed)

totaam · 2015-07-06T06:42:13Z

2015-07-06 06:42:13: antoine commented

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

totaam · 2015-07-06T09:29:13Z

2015-07-06 09:29:13: antoine commented

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

totaam · 2015-07-17T04:46:23Z

2015-07-17 04:46:23: skew4 uploaded file `aero-snap-xprakeyboard-1.log` (22.4 KiB)

totaam · 2015-07-17T04:49:56Z

2015-07-17 04:49:56: skew4 commented

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.

totaam · 2015-07-17T05:03:12Z

2015-07-17 05:03:12: totaam edited the issue description

totaam · 2015-07-17T05:03:12Z

2015-07-17 05:03:12: totaam commented

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

totaam · 2015-07-17T05:23:21Z

2015-07-17 05:23:21: skew4 uploaded file `xpra-info-grep-keyboard-1.txt` (47.7 KiB)

totaam · 2015-07-17T05:25:19Z

2015-07-17 05:25:19: skew4 uploaded file `xmodmap-pke-1.txt` (13.5 KiB)

totaam · 2015-07-17T05:25:45Z

2015-07-17 05:25:45: skew4 uploaded file `xmodmap-pm-1.txt` (0.4 KiB)

totaam · 2015-07-17T05:30:53Z

2015-07-17 05:30:53: skew4 commented

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.

totaam · 2015-07-17T05:34:52Z

2015-07-17 05:34:52: totaam commented

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?

[[BR]]

Note: I tend to be using different keyboard layouts + Keyla ...
[[BR]]
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.

totaam · 2015-07-17T05:53:30Z

2015-07-17 05:53:30: skew4 commented

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?)

totaam · 2015-07-17T05:55:35Z

2015-07-17 05:55:35: totaam commented

(you're still not interested in Xpra client logs?)
[[BR]]
I am always interested in logs, preferably trimmed ones.
Especially those with -d keyboard.

totaam · 2015-07-17T06:22:06Z

2015-07-17 06:22:06: skew4 uploaded file `xpra-client-debug-keyboard-2.txt` (11.6 KiB)

totaam · 2015-07-17T06:25:34Z

2015-07-17 06:25:34: skew4 commented

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

totaam · 2015-08-12T00:23:43Z

2015-08-12 00:23:43: stimut commented

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?

totaam · 2015-08-12T00:26:50Z

2015-08-12 00:26:50: stimut uploaded file `xpra-keyboard-linux-server.log` (369.5 KiB)

totaam · 2015-08-12T00:27:52Z

2015-08-12 00:27:52: stimut uploaded file `xpra-keyboard-linux-client.log` (60.4 KiB)

totaam · 2015-10-30T12:26:49Z

2015-10-30 12:26:49: antoine changed status from reopened to new

totaam · 2015-10-30T12:26:49Z

2015-10-30 12:26:49: antoine changed owner from tyler to skew4

totaam · 2015-10-30T12:26:49Z

2015-10-30 12:26:49: antoine commented

@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?

totaam · 2015-12-05T10:50:23Z

2015-12-05 10:50:23: antoine changed priority from major to critical

totaam · 2015-12-05T10:50:23Z

2015-12-05 10:50:23: antoine commented

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

totaam · 2015-12-06T01:55:12Z

2015-12-06 01:55:12: skew4 commented

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

totaam · 2015-12-08T05:12:59Z

2015-12-08 05:12:59: antoine changed status from new to closed

totaam · 2015-12-08T05:12:59Z

2015-12-08 05:12:59: antoine set resolution to worksforme

totaam closed this as completed Dec 8, 2015

totaam added the v0.14.x label Jan 22, 2021

xpra erroneously sends meta key from windows #759

xpra erroneously sends meta key from windows #759

Comments

totaam commented Dec 6, 2014

2014-12-06 00:00:21: tyler created the issue

totaam commented Dec 6, 2014

2014-12-06 00:00:40: tyler uploaded file bug report.zip (994.3 KiB)

totaam commented Dec 9, 2014

2014-12-09 00:38:16: antoine changed status from new to assigned

totaam commented Dec 9, 2014

2014-12-09 00:38:16: antoine commented

totaam commented Dec 10, 2014

2014-12-10 00:00:36: tyler uploaded file flipped.png (30.7 KiB)

totaam commented Dec 10, 2014

2014-12-10 00:05:34: tyler commented

totaam commented Dec 10, 2014

2014-12-10 00:09:01: antoine changed status from assigned to new

totaam commented Dec 10, 2014

2014-12-10 00:09:01: antoine changed owner from antoine to tyler

totaam commented Dec 10, 2014

2014-12-10 00:09:01: antoine commented

totaam commented Dec 10, 2014

2014-12-10 17:26:13: tyler commented

totaam commented Dec 10, 2014

2014-12-10 17:29:18: totaam commented

totaam commented Dec 10, 2014

2014-12-10 19:22:47: tyler commented

totaam commented Dec 10, 2014

2014-12-10 23:47:42: antoine changed status from new to assigned

totaam commented Dec 10, 2014

2014-12-10 23:47:42: antoine changed owner from tyler to antoine

totaam commented Dec 10, 2014

2014-12-10 23:47:42: antoine commented

totaam commented Dec 10, 2014

2014-12-10 23:56:42: tyler commented

totaam commented Dec 11, 2014

2014-12-11 00:28:10: tyler commented

totaam commented Dec 11, 2014

2014-12-11 00:31:27: antoine commented

totaam commented Dec 18, 2014

2014-12-18 08:47:24: totaam commented

totaam commented Jan 16, 2015

2015-01-16 08:07:38: totaam changed status from assigned to new

totaam commented Jan 16, 2015

2015-01-16 08:07:38: totaam changed owner from antoine to tyler

totaam commented Jan 16, 2015

2015-01-16 08:07:38: totaam commented

totaam commented Jan 16, 2015

2015-01-16 22:42:25: tyler changed status from new to closed

totaam commented Jan 16, 2015

2015-01-16 22:42:25: tyler changed resolution from ** to fixed

totaam commented Jan 16, 2015

2015-01-16 22:42:25: tyler commented

totaam commented Jul 6, 2015

2015-07-06 06:33:31: skew4 commented

totaam commented Jul 6, 2015

2015-07-06 06:42:13: antoine changed status from closed to reopened

totaam commented Jul 6, 2015

2015-07-06 06:42:13: antoine removed resolution (was fixed)

totaam commented Jul 6, 2015

2015-07-06 06:42:13: antoine commented

totaam commented Jul 6, 2015

2015-07-06 09:29:13: antoine commented

totaam commented Jul 17, 2015

2015-07-17 04:46:23: skew4 uploaded file aero-snap-xprakeyboard-1.log (22.4 KiB)

totaam commented Jul 17, 2015

2015-07-17 04:49:56: skew4 commented

totaam commented Jul 17, 2015

2015-07-17 05:03:12: totaam edited the issue description

totaam commented Jul 17, 2015

2015-07-17 05:03:12: totaam commented

totaam commented Jul 17, 2015

2015-07-17 05:23:21: skew4 uploaded file xpra-info-grep-keyboard-1.txt (47.7 KiB)

totaam commented Jul 17, 2015

2015-07-17 05:25:19: skew4 uploaded file xmodmap-pke-1.txt (13.5 KiB)

totaam commented Jul 17, 2015

2015-07-17 05:25:45: skew4 uploaded file xmodmap-pm-1.txt (0.4 KiB)

totaam commented Jul 17, 2015

2015-07-17 05:30:53: skew4 commented

totaam commented Jul 17, 2015

2014-12-06 00:00:40: tyler uploaded file `bug report.zip` (994.3 KiB)

2014-12-10 00:00:36: tyler uploaded file `flipped.png` (30.7 KiB)

2015-07-17 04:46:23: skew4 uploaded file `aero-snap-xprakeyboard-1.log` (22.4 KiB)

2015-07-17 05:23:21: skew4 uploaded file `xpra-info-grep-keyboard-1.txt` (47.7 KiB)

2015-07-17 05:25:19: skew4 uploaded file `xmodmap-pke-1.txt` (13.5 KiB)

2015-07-17 05:25:45: skew4 uploaded file `xmodmap-pm-1.txt` (0.4 KiB)

2015-07-17 06:22:06: skew4 uploaded file `xpra-client-debug-keyboard-2.txt` (11.6 KiB)

2015-08-12 00:26:50: stimut uploaded file `xpra-keyboard-linux-server.log` (369.5 KiB)

2015-08-12 00:27:52: stimut uploaded file `xpra-keyboard-linux-client.log` (60.4 KiB)