- This topic has 18 replies, 3 voices, and was last updated 2 weeks, 3 days ago by
.
-
Posts
-
I use the client on Windows and the server on Linux. It’s Fedora 27 – I cannot update the OS at this time.
Now, every couple of minutes my keyboard apparently freezes up, and I need to open a new terminal to continue typing. Meanwhile, windows are closing, and font sizes are changing. By a stroke of luck, I ended up typing “c” into one of the open terminals, and it was treated as CTRL + C. I typed “d” and it closed the terminal. So it seems that the CTRL key is simply getting stuck. This doesn’t seem to happen every time I hit it, but it’s frequently enough to be one of the most frustrating things I’ve ever experienced.
Obviously, this is terrible as I hit the CTRL key multiple times a minute while using linux – whether in the command terminal or just trying to copy/paste. Pressing both CTRL keys twice seems to unstick them, but only until the next time I hit them. I’m in a position where I cannot use the remote server for any practical purpose, and need some immediate help.
If anyone wants log files or versions, you’ll have to walk me through how to collect and upload that.
Can you try to run the ‘xev’ utility in the remote desktop, send the Ctrl key to it through the NoMachine remote session and show us what is reported in the output? I would start with sending any other key first, just to check if everything is set up correctly and the keys are reported in the output. Then you can type just the Ctrl key, to see if it is sent through. Finally, you can try with the problematic Ctrl-<key> combinations and show us the xev output.
We have been unsuccessful at reproducing the issue. Knowing the desktop environment you are connecting to on the Fedora host would be useful, and whether this happens in all applications or specific applications. Copying and pasting to and from an editor, for example, works fine in our tests.
It happens in ALL applications.
The ‘xev’ output looks like this. Nothing interesting happening through this tool. All key combinations are showing press and release events. I didn’t see anything that looked like a release event was skipped. However, when I switched over to another terminal, I was able to get it to happen within 2 presses – and it annoyingly closed my terminal too.
KeyPress event, serial 38, synthetic NO, window 0x5e00001,
root 0x235, subw 0x0, time 422987320, (70,184), root:(931,642),
state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: FalseKeyPress event, serial 38, synthetic NO, window 0x5e00001,
root 0x235, subw 0x0, time 422987385, (70,184), root:(931,642),
state 0x14, keycode 54 (keysym 0x63, c), same_screen YES,
XLookupString gives 1 bytes: (03) “”
XmbLookupString gives 1 bytes: (03) “”
XFilterEvent returns: FalseKeyRelease event, serial 38, synthetic NO, window 0x5e00001,
root 0x235, subw 0x0, time 422987500, (70,184), root:(931,642),
state 0x14, keycode 54 (keysym 0x63, c), same_screen YES,
XLookupString gives 1 bytes: (03) “”
XFilterEvent returns: FalseKeyRelease event, serial 38, synthetic NO, window 0x5e00001,
root 0x235, subw 0x0, time 422987690, (70,184), root:(931,642),
state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: FalseCan I run xev in the background and not use the tester app to log the key presses?
I’ve now uncovered a completely reproducible “recipe” for this. It happens every single time I close out and then reopen my NoMachine session.
1. Open NoMachine session to remote server.
2. Open a terminal. This isn’t strictly required, but makes the issue more obvious.
3. Hit CTRL + C (seemingly any CTRL + Key combo works, but this is the most straightforward).
4. Try to type “123”. Actually, only “1” will be typed and no other characters or keys work. Unable to click into other open windows, etc.
5. Repeat steps 3 and 4 to your heart’s content.6. System only gets unstuck when you hit CTRL + C several times in a row or press both CTRL keys simultaneously.
In my environment, this is working absolutely every time now.
I’ve also ruled out a few other things:
– It’s not my local keyboard that’s the issue. There’s no physical CTRL key issue. I’ve used the virtual keyboard on both the local and remote host and observed the same behavior.
– It’s seemingly related to the NoMachine session. I’ve logged onto that remote server directly – I have physical access to it from time to time – and repeated the process above and am unable to reproduce the issue. As soon as I reconnect via NoMachine (same login session, nothing was logged out at any point), the issue resurfaces. However, it ONLY resurfaces through NoMachine. If I try to do the procedure through the physical machine I’m connecting to, things are fine. In fact, they are fine in the NoMachine session after I do anything in the physical machine. But if I do nothing on the physical machine and hit the CTRL key on via NoMachine right after login, the problem appears.
– This problem is repeatable for every new terminal or terminal tab opened until I hit both CTRL keys, at which point it seemingly doesn’t happen for some time in any of the open terminals.
Unfortunately we can’t reproduce even by following those steps, but we will try on another system. In the meanwhile, are you using Wayland as a display server on that Fedora? Can you try to disable it (switch to Xorg)?
I don’t know what Wayland or Xorg are, but I did modify some setting to disable something related to Wayland that came up while searching around for help on this issue. I set some config value to 0 or 1 or something.
No. I made that change early on in this triage. It made no discernible difference to my experience. Certainly no impact in the area of the CTRL key.
I don’t know what Wayland or Xorg are, but I did modify some setting to disable something related to Wayland
So please check that Wayland has been correctly disabled.
As sudo, edit GDM file with a text editor:
sudo vim /etc/gdm/custom.confFind the
WaylandEnableline and modify it to this:WaylandEnable=falseRemove the pre-prending # to force the login screen to use Xorg
If there is no such line, you can add it in [daemon] section.
Save, and then reboot.
Yeah, that’s the setting I modified. It’s been set as you suggested for over a week now with multiple reboots since.
You must be logged in to reply to this topic. Please login here.