xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

#668 closed defect (worksforme)

Cant press multiple keys at once?

Reported by: kokoko3k Owned by: Antoine Martin
Priority: critical Milestone: 0.15
Component: client Version: 0.14.x
Keywords: input keyboard multiple keys Cc: kokoko3k@…

Description

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.

Change History (10)

comment:1 Changed 5 years ago by kokoko3k

Cc: kokoko3k@… added
Keywords: input keyboard multiple keys added
Version: trunk0.14.x

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

comment:2 Changed 5 years ago by Antoine Martin

Milestone: 0.15
Owner: changed from Antoine Martin to Antoine Martin
Priority: majorcritical
Status: newassigned

Confirmed.

comment:3 Changed 5 years ago by Antoine Martin

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

comment:4 Changed 5 years ago by Antoine Martin

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.

comment:5 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

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

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 5 years ago by kokoko3k

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.

comment:7 Changed 5 years ago by alas

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

comment:8 Changed 5 years ago by Antoine Martin

Replying to kokoko3k:

However often during playing it seems that the keys are sent with a delay of 1..2 seconds


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)


Replying to afarr:

I'm not seeing any keys light up


OK, taking the ticket back, I'll test more on osx next week.


but the original two keys likewise remain lit (on windows)


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.

comment:9 Changed 5 years ago by Antoine Martin

Owner: changed from alas to Antoine Martin
Status: newassigned

Backport of r7512 + r7513 was in r7527.

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:10 Changed 5 years ago by Antoine Martin

Resolution: worksforme
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.