fra81

[fra81]

Hi kamimoto,

encoders use a subsampled input buffer, so the color “correction” has to happen necessarily at a later time, but this can be probably made happen faster, if network conditions allow for it. We will work on it. Thanks for your feedback!

[fra81]

Hi,

we would need to take a look at the logs. Please check here how to gather them: https://knowledgebase.nomachine.com/DT11R00182. You can send them to forum[at]nomachine[dot]com, by referencing this topic.

[fra81]

Hi,

I assume you want to know about hardware decoding, since software decoding is already supported on any hardware. What is the operating system you are interested in? On Windows hardware decoding should work out of the box on that GPU. On Linux, you know, things are always more complicated. Even if it is supposed to work, it should still be tested on the specific hardware with the specific distribution.

[fra81]

We received the logs, but the .nx directory in the user’s home is missing and it is needed to proceed with the investigation. Did you follow the automatic procedure linked above to gather server side logs or did you gather them manually? In case you prefer to do it manually, please send us the ‘.nx’ directory from the home of the user who is owning the desktop you are connecting to.

[fra81]

Hi,

there is no plan at the present moment. All you say is absolutely correct, AV1 is a very efficient codec and it is becoming the de facto standard for content streaming. The problem, today,  is that no graphics card vendor makes widely available hardware acceleration for this codec. Software implementations have been improved for real-time scenarios, but they’re just not fast enough, yet, to be suitable for use in a software like NoMachine, where latency, and so response time, is so critical. Of course we will observe closely how the situation will evolve, and we will definitely consider to adopt it as soon as it will beneficial for our purposes. Thanks anyway for your suggestions!

[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.

[Author]

Posts