fra81

[fra81]

Hi,

for a start, let’s confirm the session closes due to a problem with the driver. To do that, please edit the $HOME/.nx/config/player.cfg and change the ‘Enable hardware accelerated decoding’ key to:

<option key=”Enable hardware accelerated decoding” value=”true” />

[fra81]

I checked the logs and they look clean. This is very strange. Is it possible that there is more than one X session running on that server machine? What is the output of the ‘ps -ef | grep X’ command run on the server? Do you have physical (local) access to that machine? Is everything normal if you use it locally?

[fra81]

Hi,

the current behaviour is intentional. It is assumed that, as long as the remote connection is active, the remote user is watching it. Also, a black screen in the remote desktop may lead the remote user to believe there is a problem with the connection. However, we understand that this may not be the expected behaviour for some users, so we are going to add an option to choose a different behaviour. Therefore I opened the following Feature Request:

https://knowledgebase.nomachine.com/FR02T04241

[fra81]

Hi,

would you take the session statistics from the menu panel (https://knowledgebase.nomachine.com/DT10R00167#9) and show us?

[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

[Author]

Posts