Xpra: Ticket #222: Repeated keys when the server is under heavy I/O load

When the Xpra server is swapping or otherwise lagging I/O wise, the key I press gets repeated in spite of me releasing it in time.

It would probably make sense to send client-side timestamps with the keyboard events to prevent that.

FTR my xset reports 500ms/33ms keyboard repetition settings.



Fri, 07 Dec 2012 06:31:22 GMT - Antoine Martin: priority, status, component changed

The only solution for things like this is the --no-keyboard-sync switch, nothing else will do: if we don't have control, we can't unpress the keys.

But from the IRC chat discussion: the problem is that when we try to handle things like "Control+a" only "a" is printed, which means that we aren't pressing the correct control key (the keymap may have a few) to simulate the control modifier when needed. The relatively easy fix is to keep track of recently pressed/unpressed keys and use those ahead of our guesses.


Fri, 07 Dec 2012 06:35:16 GMT - Antoine Martin:

The code that will need work: change_mask


Fri, 07 Dec 2012 18:51:01 GMT - Johannes Schindelin:

Just for your interest: when the keyboard layout was switched again due to a stuck key, I got this on the console: "|ZXCVBNM<>?". To me, it looks suspiciously like all the keys of the bottom row in the keyboard (and if they all are stuck, both Shift keys get pressed, which would switch the keyboard layouts here...). The question for me is now: why are all of the keys of the bottom row "pressed"? ;-)

Anyway, I will continue with the change_mask and --no-keyboard-sync route.


Tue, 08 Jan 2013 14:54:50 GMT - Antoine Martin:

Sounds like all these keys are somehow ending up mapped to the same modifier key that the system is trying to press to match your current client modifier state at the time, which is quite odd. Please see keyboard bugs to provide more details.


Mon, 11 Feb 2013 16:32:49 GMT - Antoine Martin: milestone changed


Wed, 20 Mar 2013 15:29:33 GMT - Antoine Martin: owner, status changed

Can you post the output of xmodmap -pm and xmodmap -pke? (from inside the xpra session)


Fri, 05 Apr 2013 17:24:05 GMT - Johannes Schindelin: attachment set

Output of 'xmodmap -pm'


Fri, 05 Apr 2013 17:24:24 GMT - Johannes Schindelin: attachment set

Output of 'xmodmap -pke'


Fri, 05 Apr 2013 17:25:34 GMT - Johannes Schindelin:

Sorry for the long delay, busy, busy times. I attached both requested logs. One more tidbit you might be interested in knowing: I installed two keymaps, US English and German, and I switch between the two by pressing both left and right Shift keys.

Thanks!


Wed, 17 Apr 2013 16:19:05 GMT - Antoine Martin: milestone changed

TILs:

control     Control_L (0x25),  Control_R (0x69)

and

keycode  37 = Control_L NoSymbol Control_L NoSymbol Control_L Control_L
keycode 105 = Control_R NoSymbol Control_R NoSymbol Control_R Control_R

Looks fine to me and I'm not sure I really understand how to reproduce the bug or what really needs fixing, sorry.


Wed, 24 Apr 2013 21:29:25 GMT - Johannes Schindelin: status changed; resolution set

I managed to finally update my code base to the current one. The problems are gone! Thank you so much, and my apology for not being more available to help fixing the issues.


Sat, 27 Apr 2013 22:35:31 GMT - Johannes Schindelin: status changed; resolution deleted

Actually, it is not fixed, but happens much more rarely.

There is one thing that is special in my setup that is most likely the cause: I had my GNOME desktop configured in such a way that Hitting both Shift keys together would switch keyboard layouts between English (my default) and my native language layout (so I can write mails to my folks back home).

One symptom of the problem was that Xpra would try to hit all the keys in the row containing both Shift keys, switch the layout and then I'd see all of those letters as if I had pressed the keys.

Often, this would happen when I select text word-wise: holding down the left Shift key and the right Ctrl key, and then navigating with the cursor keys. It might be the combination between this Dell keyboard and this iMac that triggers the problem.

My attempt at a work-around for the moment was to change the double-Shift-key toggle to the right-Shift-right-Ctrl to switch between layouts.

Alas, even typing this, the problem was triggered again.

Another symptom is that the layout is changed, when I switch back, the Backspace key no longer works, but switching back and forth another time makes it work again...

Unfortunately, both -pm and -pke show exactly the same output no matter whether everything's fine or whether the other keyboard layout is active or the backspace key does not work.

Any more ideas?


Sat, 27 Apr 2013 22:42:35 GMT - Johannes Schindelin:

The latest server output regarding the keyboard is:

2013-04-27 17:23:46,685 setting keymap: rules=evdev, model=pc105, layout=us,de
(II) XKB: reuse xkmfile /tmp/server-643E16515A8F7462FED0E20760EF1385C100CD73.xkm
2013-04-27 17:23:46,716 setting keymap options: terminate:ctrl_alt_bksp,grp:shifts_toggle,grp:rctrl_rshift_toggle
(II) XKB: generating xkmfile /tmp/server-D614D069B43234EBB070F717AF8938E055F5E9B2.xkm
2013-04-27 17:23:46,870 setting full keymap definition from client via xkbcomp
2013-04-27 17:23:46,920 keymapping removed invalid keycode entry 108 pointing to more than one modifier (set(['mod1', 'mod5'])): set([('Alt_R', 0), ('Meta_R', 1), ('ISO_Level3_Shift', 2)])
2013-04-27 17:23:49,284 setting keymap: rules=evdev, model=pc105, layout=us,de
(II) XKB: reuse xkmfile /tmp/server-D614D069B43234EBB070F717AF8938E055F5E9B2.xkm
2013-04-27 17:23:49,324 setting keymap options: terminate:ctrl_alt_bksp,grp:rctrl_rshift_toggle
(II) XKB: generating xkmfile /tmp/server-2025E848B1FFBED545B5CDF32811046363D2122F.xkm
2013-04-27 17:23:49,393 setting full keymap definition from client via xkbcomp
2013-04-27 17:23:49,462 keymapping removed invalid keycode entry 108 pointing to more than one modifier (set(['mod1', 'mod5'])): set([('Alt_R', 0), ('Meta_R', 1), ('ISO_Level3_Shift', 2)])

Might that be the problem?


Sat, 27 Apr 2013 22:50:24 GMT - Johannes Schindelin:

Okay, I think I have a key combination to trigger the problem reliably: When I hold down the left Shift key, the right Shift key, then cursor left and right, wait half a second, and then hit the cursor up key in the gnome-terminal, I get the output:

^[[1;6D^[[1;6C^A^G^H
^K^L:"^^

and the Search dialog pops up.

If I do the same in a gnome-terminal outside Xpra, I get "DCCCCCCCC" and no Search dialog... So maybe a previous Xpra session screwed up my X?


Tue, 13 Aug 2013 05:17:40 GMT - Antoine Martin: milestone changed

v0.10 is going to be released today, please try it and post the output of

xpra info

Which will include a lot more useful debugging information.

(re-scheduling for v0.11 - sorry..)


Thu, 17 Oct 2013 07:47:07 GMT - Antoine Martin: milestone changed

xkb due for 0.12


Mon, 20 Jan 2014 11:16:44 GMT - Antoine Martin: milestone changed

Lack of demand for keyboard, re-scheduling. Xkb is tracked in #371.


Mon, 22 Jan 2018 05:55:00 GMT - Antoine Martin: status changed; resolution set

Not heard back in 4 years! closing.


Thu, 05 Mar 2020 12:03:12 GMT - Antoine Martin: milestone changed


Sat, 23 Jan 2021 04:48:50 GMT - migration script:

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