Xpra trac archive

Xpra: Ticket #759: xpra erroneously sends meta key from windows

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.


Sat, 06 Dec 2014 00:00:40 GMT - tyler: attachment set

Tue, 09 Dec 2014 00:38:15 GMT - Antoine Martin: status changed

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

Wed, 10 Dec 2014 00:00:35 GMT - tyler: attachment set

Wed, 10 Dec 2014 00:05:34 GMT - 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.

Wed, 10 Dec 2014 00:09:00 GMT - Antoine Martin: owner, status changed

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?

Wed, 10 Dec 2014 17:26:13 GMT - 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.

Wed, 10 Dec 2014 17:29:18 GMT - 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.

Wed, 10 Dec 2014 19:22:46 GMT - 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

Wed, 10 Dec 2014 23:47:41 GMT - Antoine Martin: owner, status changed

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.

Wed, 10 Dec 2014 23:56:42 GMT - 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.

Thu, 11 Dec 2014 00:28:10 GMT - 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

Thu, 11 Dec 2014 00:31:27 GMT - 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.

Thu, 18 Dec 2014 08:47:23 GMT - Antoine Martin:

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

Fri, 16 Jan 2015 08:07:38 GMT - Antoine Martin: owner, status changed

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?

Fri, 16 Jan 2015 22:42:25 GMT - tyler: status changed; resolution set

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

Mon, 06 Jul 2015 05:33:30 GMT - 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.

Mon, 06 Jul 2015 05:42:12 GMT - Antoine Martin: keywords, status changed; milestone set; resolution deleted

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

Mon, 06 Jul 2015 08:29:12 GMT - 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.

Fri, 17 Jul 2015 03:46:23 GMT - skew4: attachment set

Fri, 17 Jul 2015 03:49:55 GMT - 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:

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.

Fri, 17 Jul 2015 04:03:11 GMT - Antoine Martin: description changed

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:

Fri, 17 Jul 2015 04:23:21 GMT - skew4: attachment set

Fri, 17 Jul 2015 04:25:18 GMT - skew4: attachment set

Fri, 17 Jul 2015 04:25:45 GMT - skew4: attachment set

Fri, 17 Jul 2015 04:30:53 GMT - 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.

Fri, 17 Jul 2015 04:34:52 GMT - Antoine Martin:

Thanks for the data.

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)

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.

Fri, 17 Jul 2015 04:53:30 GMT - 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?)

Fri, 17 Jul 2015 04:55:35 GMT - 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.

Fri, 17 Jul 2015 05:22:06 GMT - skew4: attachment set

Fri, 17 Jul 2015 05:25:33 GMT - 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)

Tue, 11 Aug 2015 23:23:43 GMT - 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?

Tue, 11 Aug 2015 23:26:50 GMT - Tim Brown: attachment set

Tue, 11 Aug 2015 23:27:51 GMT - Tim Brown: attachment set

Fri, 30 Oct 2015 12:26:48 GMT - Antoine Martin: owner, status changed

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

Sat, 05 Dec 2015 10:50:22 GMT - Antoine Martin: priority changed

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

Sun, 06 Dec 2015 01:55:12 GMT - 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.

Tue, 08 Dec 2015 05:12:58 GMT - Antoine Martin: status changed; resolution set

Sat, 23 Jan 2021 05:05:08 GMT - migration script:

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