xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 4 weeks ago

#222 closed defect (needinfo)

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

Reported by: Johannes Schindelin Owned by: Johannes Schindelin
Priority: minor Milestone: future
Component: server Version: trunk
Keywords: Cc:

Description

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.

Attachments (2)

xmodmap-pm.txt (431 bytes) - added by Johannes Schindelin 5 years ago.
Output of 'xmodmap -pm'
xmodmap-pke.txt (15.3 KB) - added by Johannes Schindelin 5 years ago.
Output of 'xmodmap -pke'

Download all attachments as: .zip

Change History (18)

comment:1 Changed 5 years ago by Antoine Martin

Component: coreserver
Priority: majorminor
Status: newaccepted

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.

comment:2 Changed 5 years ago by Antoine Martin

The code that will need work: change_mask

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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.

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

comment:5 Changed 5 years ago by Antoine Martin

Milestone: 0.80.9

comment:6 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to Johannes Schindelin
Status: acceptedassigned

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

Changed 5 years ago by Johannes Schindelin

Attachment: xmodmap-pm.txt added

Output of 'xmodmap -pm'

Changed 5 years ago by Johannes Schindelin

Attachment: xmodmap-pke.txt added

Output of 'xmodmap -pke'

comment:7 Changed 5 years ago by 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!

comment:8 Changed 5 years ago by Antoine Martin

Milestone: 0.90.10

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.

comment:9 Changed 5 years ago by Johannes Schindelin

Resolution: fixed
Status: assignedclosed

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.

comment:10 Changed 5 years ago by Johannes Schindelin

Resolution: fixed
Status: closedreopened

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?

comment:11 Changed 5 years ago by 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?

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

comment:12 Changed 5 years ago by 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?

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

comment:13 Changed 5 years ago by Antoine Martin

Milestone: 0.100.11

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

comment:14 Changed 4 years ago by Antoine Martin

Milestone: 0.110.12

xkb due for 0.12

comment:15 Changed 4 years ago by Antoine Martin

Milestone: 0.12future

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

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

comment:16 Changed 4 weeks ago by Antoine Martin

Resolution: needinfo
Status: reopenedclosed

Not heard back in 4 years!
closing.

Note: See TracTickets for help on using tickets.