graywolf

[graywolf]

In the remote Windows OS, Ctrl and Alt key are left in the down state when you hit Ctrl+Alt+M. They should be automatically released in such kind of situation, so we created a Trouble Report for that (check the box to get notifications):

https://www.nomachine.com/TR10Q09439

Should it happen again, disconnect/reconnect is not the only workaround. Hitting Ctrl and Alt once would properly restore the state of those keys.

[graywolf]

[VGL] ERROR: Could not open display :0.

That is, the DISPLAY :0 is not accepting localhost connections. That is required for VirtualGL to offload the 3D operations to the display :0 (actually using the video card).

Follow this article to check the VirtualGL setup:

https://www.nomachine.com/AR05P00982

Have you got any warning message when you run sudo /etc/NX/nxserver --virtualgl-install ?

[graywolf]

Please, also collect the .nx directory in the user’s home on server side. You can do it also from the command line:

tar -cvp --exclude 'cache*' --exclude 'images' --exclude 'temp' $HOME/.nx | gzip -c >nxdir.tar.gz

[graywolf]

Try to open a terminal window and run the command

sudo -l

what do you get?

By the way, you can shutdown NoMachine server also using this command:

sudo /etc/NX/nxserver --shutdown

[graywolf]

You’re welcome. I’ll open a Trouble Report to track this issue.

[graywolf]

Is this your setup?

Windows 10 –(via RDP)–> Windows workstation 1 –(via NoMachine)–> Windows workstation 2

We tried to reproduce and no hiccup was noticed in mouse movement.

Did you check “Show the remote cursor” in NoMachine settings, perhaps?

[graywolf]

Please send $HOME/.nx folder to forum (at) nomachine (dot) com

Could we send to you a debugging library to be placed in your NoMachine installation?

[graywolf]

Did you notice any peak in CPU usage reported by Task Manager?
Would you try to uncheck “Use acceleration for display processing” in the NoMachine service settings, then restart the service?
Did you try to run the NoMachine client on a different machine?

[graywolf]

Try to launch a shell as the local admin and run the command
sudo -l
what do you get?

[graywolf]

I think I’m able to reproduce on a similar setup. Going to open a Trouble Report.

Meanwhile, would you try this workaround:

1. Edit DisplayServerExtraOptions in /usr/NX/etc/node.cfg in this way:
   DisplayServerExtraOptions "-wlmode compositor"
2. Restart NoMachine: /etc/NX/nxserver --restart
3. Try to connect to view the desktop. If it fails, edit PAM configuration as described here.

[graywolf]

jjgalvez, would you provide: your Linux OS distribution, the kernel version, the video card model?

Have you got access to the machine on the server side? What do you see if you try to wake up the screen providing some keyboard/mouse input?

[graywolf]

Would you change /usr/NX/etc/node.cfg in order not to delete old session files

SessionLogClean 0

retry the two cases and send us the new set of NoMachine log files?

[graywolf]

Thanks to let us know. May I we ask you to try a NoMachine package with debug turned on? I’d like to gather more information about this problem.

[graywolf]

Thank you for the feedback. Suggestions to improve the user experience are always welcome.

NoMachine does not change the X.org keyboard layout: we prefer not to make such a change automatically, without the user’s control. By the way, any remote user as well as any user physically sitting next to the server host can change the layout as they find more comfortable, using the configuration tools provided by the OS.

The mentioned “virtual keyboard” is just a facility that allows NoMachine to inject input events generated by users into the remote desktop they intend to use. So “virtual keyboard” and the physical keyboard attached to the server host are treated separately and can get different settings.

I’m assuming you didn’t experience the same problem in the other product because you used the “virtual desktop”. You can try this kind of session in the NoMachine Workstation product and you’ll find they work as expected.

In brief, the problem is due to X.org ignoring locale settings for the “virtual keyboard”. We could think about workaround in the NoMachine software that fixed up such issue automatically, without user’s intervention.

[graywolf]

I assume you are connecting to the physical display (you may have installed the free version). NoMachine changes nothing on the keyboard, it simply treats raw keyboard events on the client and on the server those raw events are translated in a meaningful symbol on the basis of the current keyboard layout of your system.

To reproduce keyboard events NoMachine uses the virtual keyboard provided by x.org. It’s possible that this virtual keyboard is set to the default US layout and not the French one.

To check this and change it, there is another thread with the same problem:

NoMachine keyboard switch

[Author]

Posts