Cant press multiple keys at once?

[totaam]

Issue migrated from trac ticket # 668

component: client | priority: critical | resolution: worksforme | keywords: input keyboard multiple keys

2014-09-04 08:27:04: kokoko3k created the issue

---

I was just trying to play a racing game remotely.
It uses the Up arrow key to accelerate and the LEFT and RIGHT arrow key to turn the car.
When i push the UP arrow key to accelerate and then use LEFT or RIGHT while keeping UP pushed, the car slows down.

A quick tool i found to test out is xkeycaps, it shows a keyboard and lights up the keys pressed, you can check by yourself that pushing two keys at once wont work with xpra.

[totaam]

2014-09-04 08:28:42: kokoko3k commented

---

Forgot to set the version, sorry.
I'm using 0.14.3 by winswitch.

[totaam]

2014-09-04 10:39:56: totaam changed priority from major to critical

[totaam]

2014-09-04 10:39:56: totaam changed status from new to assigned

[totaam]

2014-09-04 10:39:56: totaam changed owner from antoine to totaam

[totaam]

2014-09-04 10:39:56: totaam commented

---

Confirmed.

[totaam]

2014-09-04 13:33:27: totaam commented

---

Here's what I'm seeing with -d keyboard:

• client side:

parse_key_event(<gtk.gdk.Event at 0x33635f8: GDK_KEY_PRESS keyval=Up>, True)= 
    <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Up', 'pressed': True, 'keyval': 65362, 'keycode': 111}>
handle_key_action(ClientWindow(1), 
    <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Up', 'pressed': True, 'keyval': 65362, 'keycode': 111}>) wid=1
send_key_action(1, 
    <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Up', 'pressed': True, 'keyval': 65362, 'keycode': 111}>)
parse_key_event(<gtk.gdk.Event at 0x3363508: GDK_KEY_PRESS keyval=Left>, True)=
    <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Left', 'pressed': True, 'keyval': 65361, 'keycode': 113}>
handle_key_action(ClientWindow(1), 
    <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Left', 'pressed': True, 'keyval': 65361, 'keycode': 113}>) wid=1
send_key_action(1, 
    <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Left', 'pressed': True, 'keyval': 65361, 'keycode': 113}>)
parse_key_event(<gtk.gdk.Event at 0x33635d0: GDK_KEY_PRESS keyval=Left>, True)=
    <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Left', 'pressed': True, 'keyval': 65361, 'keycode': 113}>
handle_key_action(ClientWindow(1), 
    <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Left', 'pressed': True, 'keyval': 65361, 'keycode': 113}>) wid=1
send_key_action(1, 
    <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Left', 'pressed': True, 'keyval': 65361, 'keycode': 113}>)

etc..

So we stop getting the repeat key event for Up as soon as we get the Left key press.

• server side:

handle keycode pressing 111: key Up
fake_key(111, True)
scheduling key repeat timer with delay 660 for Up / 111
get_keycode(113, Left, ('mod2',)) native keymap, using unmodified keycode: 113
handle_key(1,True,Left,65361,113,('mod2',)) keyboard_sync=True
is_modifier(113) not found
handle keycode pressing 113: key Left
fake_key(113, True)
scheduling key repeat timer with delay 660 for Left / 113
key repeat timeout for Up / '111' - clearing it, now=1409831009.26, scheduled at 1409831008.6 with delay=660
handle_key(1,False,Up,65362,111,('mod2',)) keyboard_sync=True
is_modifier(111) not found
handle keycode unpressing 111: key Up

And so the server is expecting the repeat event for all the pressed keys, doesn't receive it and so it unpresses the key...

What makes this much more difficult to fix is that it behaves differently on win32 (haven't tried OSX yet): we're still missing the other key, but we get both a key up and a key down on win32...

[totaam]

2014-09-04 13:58:44: totaam commented

---

This is the minimal fix:

--- src/xpra/server/server_base.py	(revision 7502)
+++ src/xpra/server/server_base.py	(working copy)
@@ -1535,6 +1535,11 @@
             self.fake_key(keycode, False)
         is_mod = self.is_modifier(name, keycode)
         if pressed:
+            #cancel all repeat timers:
+            for timer in self.keys_repeat_timers.values():
+                self.source_remove(timer)
+            self.keys_repeat_timers = {}
+
             if keycode not in self.keys_pressed:
                 press()
                 if not self.keyboard_sync and not is_mod:

But I'm not sure if this is what I'll merge yet.

[totaam]

2014-09-04 14:11:53: totaam changed status from assigned to new

[totaam]

2014-09-04 14:11:53: totaam changed owner from totaam to afarr

[totaam]

2014-09-04 14:11:53: totaam commented

---

Better fix in r7512 + r7513, we may backport this to the 0.14.x branch but since this bug has been present for a very long time, let's not rush this.

@kokoko3k: does that fix things for you?

@afarr: can you confirm that we can now press multiple (non modifier) keys concurrently (xkeycaps is good for testing this), and that it doesn't break anything. In particular, I am worried that if multiple keys are pressed, one may get stuck if we somehow miss the key-release event (not sure how that would happen, but maybe alt-tabbing away or clicking away then releasing the key whilst xpra does not have keyboard focus).

[totaam]

2014-09-04 19:27:13: kokoko3k commented

---

It seems fixed to me, thank you very much for looking into this and for the fast fix!

However often during playing it seems that the keys are sent with a delay of 1..2 seconds, wvwn if the game stays smooth.
I don't know if this issue is related to the fix.

[totaam]

2014-09-05 01:32:59: afarr commented

---

• Testing with osx 0.15.0-r7514 (against a fedora 20 0.15.0-r7514), using xkeycaps, I'm not seeing any keys light up and I'm not seeing any indication that multiple keys are pressing at the same time. The xkeycaps app seems to register the latest key pressed (though there are occasional flickers if I take pressure of that key then re-apply, while still holding down a second key). Testing by holding multiple keys down in an xterm, then clicking to a local app, I find that the keyboard focus remains on the xterm (the latest key continues to register repeatedly)... but the xterm immediately registers the key release and stops entering new instances. (As a note, our osx build system is currently in some disarray...)

• Testing with windows client 0.15.0-r7514 (against same fedora 20), the xkeycaps app does indeed register multiple key presses at the same time (with the pretty yellow highlit keys). Testing by pressing multiple keys in an xterm produces the same result as with osx (the later-most pressed key continues to be input while keys are held), but when I click on a local application keyboard focus shifts to the local application and within a fraction of a second the keystrokes stop registering on the xterm, and begin registering on the local application.

• Testing from the windows session xkeycaps window then clicking to another xpra session window (in this case chrome) - the keyboard focus seems to shift to the chrome window, in that the keystrokes begin registering there, however the yellow highlit keys of the xkeycaps application remain lit in yellow (both of them). Returning to the xkeycaps window again and pressing two new keys, the new keys light while pressed, but the original two keys likewise remain lit (apparently allowing 4 keys to be pressed at the same time). The keys are still lit after writing up all of this.

• With the windows client, focus on the xkeycaps app & pressing two different keys... changing focus to a local application, with with a click or with alt-tab, causes the keys to "un-light".

Would you like -d keyboard logs for both?

[totaam]

2014-09-05 03:52:20: totaam commented

---

Replying to kokoko3k:
[[BR]]

However often during playing it seems that the keys are sent with a delay of 1..2 seconds
[[BR]]
That's a different issue, and one I am not seeing this time.
Do you see the key events on the client with -d keyboard?
If so, they should be forwarded to the server instantly (bar network latency)
[[BR]]

---

Replying to afarr:
[[BR]]

I'm not seeing any keys light up
[[BR]]
OK, taking the ticket back, I'll test more on osx next week.

[[BR]]

but the original two keys likewise remain lit (on windows)
[[BR]]
This one sounded like a bug, but then I tried it without xpra and got the same behaviour.

Overall, it looks OK for backports I think.

[totaam]

2014-09-05 03:52:29: totaam changed status from new to assigned

[totaam]

2014-09-05 03:52:29: totaam changed owner from afarr to totaam

[totaam]

2014-09-05 03:52:29: totaam commented

---

Backport of r7512 + r7513 was in 7527.

[totaam]

2015-01-18 06:20:02: totaam changed status from assigned to closed

[totaam]

2015-01-18 06:20:02: totaam changed resolution from ** to worksforme

[totaam]

2015-01-18 06:20:02: totaam commented

---

It seems to work well enough for win32 and x11, and I don't see an easy way to coerce OSX into not acting stoopid. (not for the first time, see #708 for example)

So I am closing this ticket, feel free to re-open.