Forum Replies Created
-
Posts
-
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.
Hello. Try to change keyboard layout to PL in KDE settings on the remote host.
You could also setup using the command line. Run a terminal on the remote desktop and type the command
setxkbmap pl.OK, I was able to replicate on my own. It looks a different problem, so a new TR is appropriate: The Win key gets stuck when used in shortcuts
Hello, this seems like a known problem:
Some key combinations are not captured on Windows when the grabbing of the keyboard is enabled
Nothing unusual in the keymap.
Host is Win10, remote is Ubuntu 16.04
Please, confirm the setup is like the following:
- Client (local to the user): Windows 10
- Server (remote to the user) Ubuntu
and gather client and server logs: How to gather debug logs for support requests
Then send logs to: forum (at) nomachine (dot) com
Hello.
I have not found anything useful in logs. Would you try the latest NoMachine software update (6.12.3)?