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.
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.
The code that will need work: change_mask
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.
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.
Can you post the output of
xmodmap -pm and
xmodmap -pke? (from inside the xpra session)
Output of 'xmodmap -pm'
Output of 'xmodmap -pke'
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.
control Control_L (0x25), Control_R (0x69)
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.
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.
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?
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?
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:
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?
v0.10 is going to be released today, please try it and post the output of
Which will include a lot more useful debugging information.
(re-scheduling for v0.11 - sorry..)
xkb due for 0.12
Lack of demand for keyboard, re-scheduling. Xkb is tracked in #371.
Not heard back in 4 years! closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/222