#59 stuck keys in vcxsrv 1.19.5.2

[Stephen Wall]

Ever since upgrading to 1.19.5.2, I have been having an problem that looks a lot like lost key up events, primarily during text selection while editing files. vcxsrv is running on a Windows 10 Enterprise machine, and the application is vim 8.0.1159 in xterm 330, running on FreeBSD 11.0. The FreeBSD machine has not changed since before I updated vcxsrv, so can't be the issue.

Once this happens, none of my X windows will accept input. I've found that clicking the X11 icon in the system tray will restore normal operation.

I haven't updated vcxsrv in a while, so this could potentially have appeared in an earlier version that I did not install.

[woongbin]

Just wanted to pile on that this happened to me as well.
The client is running on Linux, and the server running on Windows 10 enterprise. It gets stuck when I press shift+up specificially.

[Robert Youngberg]

I am using Enterprise Windows 10, Putty, and VcXsrv 1.19.6.2 and spend a lot of time in gvim. When I highlight and move (j or k), the up key event dosn't always register and it continues to highlight to the top or bottom of the file or until I have to right click on VcXsrv task icon. I did not see this issue when using Windows 7.

[Akira - Cleber Akira Nakandakare]

I just wanted to report that the same happens to me. Thank you for the information about clicking the tray icon to restore normal operation. Until now, I was closing VcXsrv :-(

VcXsrv X Server version "1.19.6.4".
Window 10 Pro, version 1709 , build 16229.431

[Magnus Stenkvist]

I experienced the same problem using emacs from WSL with the following setup:
VcXsrv X Server version "1.20.1.1"
Windows 10 Enterprise, version 1803 build 17134.285

Found out that the problem seems to go away if I uncheck the "Clipboard may use PRIMARY selection" option (right-clicking VcXsrv icon in the taskbar).
Hope it helps for you as well.

[Neo]

works for me, thanks

[Kirill 'kkm' Katsnelson]

Ugh, joining the good company guys. Just posted a question at the Help board.

@tepp76, thanks for the primary selection observation, will try.

My solution is select the tray icon menu then "Reload system.XWinrc": this stops the runaway keys immediately.

My version is 1.20.6.0, installed with installer (not self-compiled) on an x64 W10 machine.

[aardvarkkrill]

I'm having the same problem using WSL in Windows10(ugh) - shift+arrow keys go haywire in my text editory (pycharm)
I can stop it each time by selecting "close window" for the editor (and answering No!)

Windows10 + WSL + Ubuntu-20.04 + VcXsrv[64.1.20.8.1]
Microsoft Windows [Version 10.0.18363.900]

UPDATE: the primary selection fix worked. :-) but :-(

[Heikki Kultala]

I'm experiencing the same problem, if I keep a button pressed to activate the repeat mode of a button, the repeat mode does not stop when I stop holding the button.

And the reason why I switched from Xming to vcxsrv was to get X clipboard integration working with windows cut and paste, so disabling it is not really an option for me.

But I think this bug is caused by vcsrv not either listening for keyboard events from the user, or not sending these keyboard events to the client program when there is constant stream of X selection update data coming from the client. The X selection updates should be deprioritized so that other events are always handled first.

[AwokeKnowing]

for me it happens when I hold SHIFT + arrow and let it repeat, eg to select a word. will then repeat forever

[buraba]

At the end, I found the reason.
To disable primary selection is not useful for me at all. And I spent a long to found, the IME I used is culprit.
For me, I used the IME which named sougou, and after uninstalling it, this problem has been solved. You can just try to uninstall the IME you are using now. It may help you.

Good Luck

[VisualJoyce]

Same problem here! I changed the IME with shift+ctrl to default IME, then it works. But this is very strange.