Repeated keys when the server is under heavy I/O load

[totaam]

Issue migrated from trac ticket # 222

component: server | priority: minor | resolution: needinfo

2012-12-07 06:27:48: dscho created the issue

---

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.

[totaam]

2012-12-07 06:31:22: antoine changed priority from major to minor

[totaam]

2012-12-07 06:31:22: antoine changed status from new to accepted

[totaam]

2012-12-07 06:31:22: antoine changed component from core to server

[totaam]

2012-12-07 06:31:22: antoine commented

---

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.

[totaam]

2012-12-07 06:35:16: antoine commented

---

The code that will need work: change_mask

[totaam]

2012-12-07 18:51:01: dscho commented

---

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.

[totaam]

2013-01-08 14:54:50: antoine commented

---

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 [/wiki/Keyboard#ReportingBugs keyboard bugs] to provide more details.

[totaam]

2013-03-20 15:29:33: antoine changed status from accepted to assigned

[totaam]

2013-03-20 15:29:33: antoine changed owner from antoine to dscho

[totaam]

2013-03-20 15:29:33: antoine commented

---

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

[totaam]

2013-04-05 18:24:05: dscho uploaded file xmodmap-pm.txt (0.4 KiB)

Output of 'xmodmap -pm'

[totaam]

2013-04-05 18:24:25: dscho uploaded file xmodmap-pke.txt (15.3 KiB)

Output of 'xmodmap -pke'

[totaam]

2013-04-05 18:25:35: dscho commented

---

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!

[totaam]

2013-04-17 17:19:06: totaam commented

---

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.

[totaam]

2013-04-24 22:29:25: dscho changed status from assigned to closed

[totaam]

2013-04-24 22:29:25: dscho changed resolution from ** to fixed

[totaam]

2013-04-24 22:29:25: dscho commented

---

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.

[totaam]

2013-04-27 23:35:31: dscho changed status from closed to reopened

[totaam]

2013-04-27 23:35:31: dscho changed resolution from fixed to **

[totaam]

2013-04-27 23:35:31: dscho commented

---

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?

[totaam]

2013-04-27 23:42:35: dscho commented

---

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?

[totaam]

2013-04-27 23:50:24: dscho commented

---

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?

[totaam]

2013-08-13 06:17:41: totaam commented

---

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

[totaam]

2013-10-17 08:47:08: totaam commented

---

xkb due for 0.12

[totaam]

2014-01-20 11:16:44: totaam commented

---

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

[totaam]

2018-01-22 05:55:00: antoine changed status from reopened to closed

[totaam]

2018-01-22 05:55:00: antoine set resolution to needinfo

[totaam]

2018-01-22 05:55:00: antoine commented

---

Not heard back in 4 years!
closing.