- This topic has 18 replies, 3 voices, and was last updated 2 weeks, 3 days ago by
.
-
Posts
-
Sorry for not updating you. We have been trying to reproduce the error using your exact set-up and steps but without much luck. However, there is a TR already open on a similar issue related to Windows client connecting to Gnome, upon using the Right-Ctrl + Shift + V in the session, it toggles the control key press. It might be related to this. Can you check if the workaround can help in your case?
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.
You must be logged in to reply to this topic. Please login here.