fra81

[fra81]

Sorry, I overlooked your exact requirements. At the moment it is possible to accelerate OpenGL apps by means of VirtualGL but not Vulkan, as a “VirtualVulkan” doesn’t exist. The reasons were discussed in this VirtualGL’s project page: https://github.com/VirtualGL/virtualgl/issues/37.

As far as I know, nothing should prevent applications running in a NoMachine virtual desktop from accessing the GPU for CUDA computing. We tried a simple CUDA program and it works, with the help of VirtualGL, since the CUDA program was using OpenGL for the final rendering.

[fra81]

Hi mato,

this behaviour can’t be fixed on NoMachine’s side. NoMachine simulates the press of physical keys by sending the physical key codes. How they are translated to specific symbols depends on the remote system. In short, if you have the §± symbols in the on-screen keyboard (whose layout only depends on the remote system) for that specific key, these are the symbols that it will be possible to input with NoMachine. The fact you can have one layout or the other for that key depends, I think, also on the keyboard hardware you have attached to the Mac, that you actually use for typing on the server, and not just on the input source settings.

[fra81]

Hi,

so your last findings seem to narrow it down to a rendering issue on client side. I still think this could be an issue with the drivers, but, if you send us the client side logs, we can check for possible hints. You can find instructions in https://knowledgebase.nomachine.com/DT11R00181#2 for the client side. Please also tell us what graphics card and drivers you have on the problematic Ubuntu client.

[fra81]

Hi Axel,

in the logs I see that NoMachine creates successfully the virtual X server, but gnome-session fails to start. I’d check the system logs for possible reasons. Feel free to share the logs with us. One thing you could try on the fly is changing the DefaultDesktopCommand key in the /usr/NX/etc/node.cfg file to add the ‘–disable-acceleration-check’ option to the gnome start command, e.g.:

dbus-launch --exit-with-session gnome-session --session=ubuntu --disable-acceleration-check

[fra81]

We would need to see the logs again to investigate this new problem. We would need them from both server (https://knowledgebase.nomachine.com/DT11R00182) and client side (https://knowledgebase.nomachine.com/DT11R00181#2). Thanks!

[fra81]

Hi,

that is already possible. Please check this article on how to enable it:

https://knowledgebase.nomachine.com/AR05P00982

[fra81]

Hi ToastyMarshmallow,

it looks like you have another service listening on port 4000, the same used by the NoMachine server by default, and that’s why the server can’t start up. To check what is the service that is keeping port 4000 busy, you could run:

sudo netstat -l -p | grep 4000

You can then stop that service or change its port. Alternatively, you can change the port the NoMachine server is listening on. You can do that in the Server settings -> Ports panel.

That said, we noted that the problem is not reported clearly in the logs. We’ll have that fixed. Thanks!

[fra81]

Hi,

sorry for the huge delay in gettin back to you. Probably the left Windows key is intercepted by the local window manager, despite the fact you selected, as I assume, the ‘Grab the keyboard input’ option. This option enables the so-called ‘passive grab’ of the keyboard, but it is also possible to enable the ‘active grab’. In order to try this, please quit the NoMachine player application completely (you can do this from the NoMachine icon in the tray) and start it again from the terminal using the following command:

/usr/NX/bin/nxplayer --activegrab

Let us know if this solves your problem.

[fra81]

Hi Vincent,

there is not a native build for M1 yet, but we are working on it and it is in testing phase.

In our labs, however, we can use both hardware and software H.264 decoding on M1 machines with the current packages, and there is no known problem with it, so it would be interesting to take a look at your logs (client and server side). You can find instructions in https://knowledgebase.nomachine.com/AR10K00697 and you can send them to forum@nomachine.com.

[fra81]

Hi,

what you describe is likely a driver issue. Just to exclude a possible culprit, please try to disable hardware encoding on the server (Server preferences -> Performance) and see if the issue persists.

If disabling hardware encoding doesn’t help, it would be nice to take a look at the logs. You can gather them following the instructions in https://knowledgebase.nomachine.com/DT11R00182 and send to forum@nomachine.com.

[fra81]

Hi Stefano,

I checked the logs. Both sides of the connection report the same thing: no data is received from the network, and eventually connection drops. It doesn’t look like a problem in the software, but rather a network issue.

[fra81]

Were you connecting successfully before updating the uuid?

In order to know what’s going on, we would need to see the server side logs. You can find instructions in https://knowledgebase.nomachine.com/DT11R00182. You can send collected logs to forum@nomachine.com, by referencing this thread.

[fra81]

From what you say in point 2, it’s very likely a problem with permissions, so I’m afraid you have to access physically that Mac Pro and grant them. Here you can find some further hint: https://knowledgebase.nomachine.com/AR09S01139. In some cases, after a OS update, it might be necessary to remove (uncheck) the permissions and grant again.

[fra81]

Hi Stefano,

can you send also server side logs? You can follow the instructions in https://knowledgebase.nomachine.com/DT11R00182. If you prefer, you can send them to forum@nomachine.com.

[fra81]

Hi,

since the two machines are clones, I assume that they share the same uuid. You should execute the following in one of them:

sudo /usr/NX/bin/nxserver --shutdown
sudo rm -f /usr/NX/etc/uuid
sudo /usr/NX/bin/nxserver --startup

[Author]

Posts