Forum Replies Created
-
Posts
-
That workaround suggests:
- Giving focus to Windows (i.e., clicking out of NoMachine window to anywhere else on my local machine).
- Giving focus back to NoMachine (i.e., clicking back into NoMachine to resume the remote session).
- Press any key other than right control.
- Typing is then normal again.
I can confirm that following steps 1-3 gave me the desired result in step 4.
However, that’s actually more steps than my current “workaround” of just hitting both CTRL keys at the same time in the NoMachine window. I first have to minimize my NoMachine window, click out, then click back in, then maximize again to be back in my preferred working environment. Four steps instead of one. Furthermore, I was also back to the problem after about 3 more key presses even after following these steps, so there’s no permanence to it whatsoever, only a sort of on-demand “unlock” trigger.
More importantly, by the time my CTRL key is “stuck” in NoMachine, and by the time I realize I need to execute one of these workarounds, my terminals have already been closed, my font has already been resized, my settings have already been changed, my files have already been overwritten, etc. Once the time for unlocking the CTRL key arrives, the damage from having it locked in the first place is already done.
In fact, I think it’s probably more appropriate to refer to these steps as “unlock routines” rather than “workarounds”. They certainly get me out of the bad state so it doesn’t persist indefinitely, but don’t prevent the impacts of getting into the bad state in the first place, or prevent near-immediate recurrence of the bad-state seconds later. Unfortunately, neither unlock routine really gives me any sort of advantage over the actual underlying issue itself.
However, I’m hopeful that by confirming the behavior is the same here as in the linked Trouble Report, it gives your team some additional clues to tracking down a fix.
Yeah, that’s the setting I modified. It’s been set as you suggested for over a week now with multiple reboots since.
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 that came up while searching around for help on this issue. I set some config value to 0 or 1 or something.
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.
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?