Forum Replies Created
-
Posts
-
Hello johngalt17.
Those logs are insufficient to determine the nature of the problem. Please run the interface to change settings on your server, select “Player settings”, “Security”: in that pane check the box “Don’t delete log files on exit”.
Then reproduce the problem, collect the complete log on the server by command
sudo /etc/NX/nxserver --debug --collect.Hello. Would you try to setup keyboard with the “mac” variant? Run a terminl window and issue the command
setxkbmap -layout se -variant mac.Hello, we inspected logs you sent but we didn’t find any error. Be sure log files are not cleaned up: on server side, run NoMachine Player settings, go to “Player settings”, “Folders”, “Security” then check box “Don’t delete log files on exit”.
Hello. The keyboard layout of the client is irrelevant. You need to take care of the keyboard layout on the remote server host. NoMachine forwards keyboard events as “raw keys” (physical key codes, the symbol impressed on the keys don’t matter), so the remote server layout is the one that really matters. NoMachine does not provide any tool for changing keyboard layout as you can use the remote host system settings to change it accordingly to your needs.
Win+Space is caught by Windows so it is not passed through the client and does not get to the remote session. I’d suggest to bind a different hotkey to the switch layout action in the remote desktop. Otherwise, turn on NoMachine client setting “Grab the keyboard input”.
While I’m connected NoMachine completely ignores that I change the input language on my PC and this change doesn’t make any difference on the remote PC.
Hello. It is exactly the expected behavior. Client and remote session can get different keyboard layouts. In order to change the keyboard layout in a remote Xfce (or Gnome, or KDE) session, define multiple layout in the Xfce System Settings: then you’ll be able to switch layouts by just clicking on the Keyboard layout applet in the Xfce panel or using the Xfce hotkey bonded to action “switch layout”.
I think you are running two Gnome sessions for the same user (likely you have user logged at the physical console). Gnome gets confused about the session to be unlocked so it’d be wiser running a single Gnome session per user.
Hello, you can use two monitors on the client side, but that won’t add any new virtual screen to the remote server host. If you have just one monitor at the server host, you will see only that in the client window, no matter how many screens the client window is stretched onto.
NoMachine is designed to work with headless servers and works well with the majority of set-ups.
There are some cases where screen sharing of the physical display of headless servers poses problems (mainly on Linux) and these are problems that we share with many other remote desktop solutions out there as searching the internet will show.
On Linux in particular, these are the most common results of headless screen sharing:
1. It works out-of-the box
2. It works fine, but may be stuck to a fixed screen resolution
3. It works but there may be performance issues and badly rendered objects
4. It does not work at all: nothing displayed
5. X does not start because “no screens is found”In the last case (5), NoMachine is able to automatically detect this situation and runs its own virtual display. Problem solved.
For cases 2-4, we cannot say when and why it will happen in advance because it can depend on one or a combination of the following:
1. The GPU model
2. The software driver
3. The operating system
4. The programs using the GPU for renderingIt is reasonable to think that GPUs are designed to go into a kind of low performance mode when they have no output to display.
Based on what we know, people handle such problems in a few different ways:
1. Setup Xorg for working in headless mode:
1.a. AllowEmptyInitialConfiguration (NVIDIA proprietary driver only)
1.b. Xorg dummy driver
1.c Create fake EDID and use it in Xorg.conf (Extended Display Identification Data are stored in the monitor and read out by the GPU when monitor is connected)
2. Use a virtual framebuffer X (like NoMachine virtual display)
3. Use a fake display plug.Regarding point 3, it generally works because with the plug attached, the GPU performs as if there were a real screen attached to it. Hence this is what we suggest and the topics in this forum are testament to that. A viable alternative is to install NoMachine Workstation for Linux and neither of the steps 1-3 above will be necessary.
Yes, multiple virtual sessions can share the GPU through a single Xorg server.
About current state of VirtualGL, I’d suggest to keep an eye on VirtualGL users mailing list.
I would try this:
- On Windows client: switch away from Neo2 to plain German or US
- On Debian server: ensure Neo2 layout with command (run in the remote session):
setxkbmap -layout de -variant neo.
Hello.
VirtualGL needs a a running 3D X server in order to share the GPU with applications running in virtual desktops.
I knew development is ongoing on VirtualGL to make it work on NVIDIA cards directly and remove the need for a running X server.
I’m considering creating a Feature Request to get NoMachine client handle volume keys.
Here it is: Grab the volume keys
NoMachine does not try to change keyboard layout. Such problem occurs because display server didn’t initialize the virtual keyboard device (it does not depend on NoMachine). Setting layout in KDE should be enough to fix the problem permanently.