fra81

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 718 total)
  • Author
    Posts
  • in reply to: Getting VirtualGL working #52159
    fra81
    Moderator

    Manually setting the LD_PRELOAD variable to “/opt/NX/lib/libnxegl.so” does not ‘fix’ the virtual session.

    Note that LD_PRELOAD is set to a different value in the physical desktop and for a different purpose. In virtual desktops, the value you are supposed to see is:

    LD_PRELOAD=/opt/NX/scripts/vgl/libdlfaker.so:/opt/NX/scripts/vgl/libvglfaker.so

    You can try to set it manually and check again.

    The question is still why LD_PRELOAD is not set, even if in the logs we see that it’s being added to the environment of the desktop process. At the moment I don’t have further ideas, we will check again in our labs with KDE Plasma.

    fra81
    Moderator

    Hi Rhymer,

    do you mean that the monitor attached to the server is turned on and you can see what is actually happening on the server screen, while the grey screen is being shown in the player window?

    To investigate further, we would need to see the logs from the server. Please follow the instructions in https://kb.nomachine.com/DT07S00243. You can send them to forum[at]nomachine[dot]com.

    in reply to: AMD GPU – White screen (Ubuntu 22.04) #52033
    fra81
    Moderator

    Hi,

    it would be important to see logs from the user’s home ($HOME/.nx), that are missing in the archive. You can try with the automatic procedure (see https://kb.nomachine.com/DT07S00243). You can send them to forum[at]nomachine[dot]com by referencing this topic.

    in reply to: Getting VirtualGL working #52031
    fra81
    Moderator

    Hi.

    It’s strange that the LD_PRELOAD variable is not set in the environment, despite we see it being set in the logs. It seems like something else is clearing the environment afterwards, maybe something in the user’s profile.

    However, you may check if VirtualGL is functional by trying to run your app through the vglrun command:

    /opt/NX/scripts/vgl/vglrun <opengl app>

    (assuming NoMachine is installed in ‘opt’ dir, as we see in the logs)

    The, you may try to run the whole desktop via the vglrun command by adding it to the DefaultDesktopCommand key in the node.cfg file, e.g.:

    DefaultDesktopCommand "/usr/bin/dbus-launch --exit-with-session /opt/NX/scripts/vgl/vglrun gnome-session"

    in reply to: Artifacts with NoMachine #52029
    fra81
    Moderator

    Hello,

    I assume you have already tried to disable hardware encoding. Have you also tried to disable hardware decoding in the session menu on the client?

    In order to narrow things down, can you try to add this line in the /usr/NX/etc/node.cfg file on the server:

    DisplayServerExtraOptions “-refinement 0”

    Finally, please send both server and client side logs for further investigation. See https://kb.nomachine.com/DT07S00243 for instructions. You can send them to forum[at]nomachine[dot]com.

     

    in reply to: Unable to get high image quality #52028
    fra81
    Moderator

    Hi mickeyil,

    you mention X11 vector graphics, so do you confirm you have got one of the products in the NoMachine Terminal Server family and you are running a virtual desktop?

    In that case, you may want to use a lossless compression method (like png) for image encoding. See more about the ProxyExtraOptions key:

    https://kb.nomachine.com/AR06Q01034

    in reply to: NoMachine 24.04.1 LTS stops working after a few hours #51532
    fra81
    Moderator

    Hi forux,

    logs show something strange, like if the monitors info initialization was incomplete. Could you show us the output of the following dbus call?

    You should install the d-feet package (‘sudo apt install d-feet’), open the d-feet program, navigate to the Session Bus section, double-click on the GetCurrentState method of the /org/gnome/Mutter/DisplayConfig interface (see the attached screenshot), and click on Execute. What is the output?

    Please also send the logs in this directory: $HOME/.nx/nxegl/.

    • This reply was modified 1 month, 2 weeks ago by fra81.
    fra81
    Moderator

    So far we could only reproduce this problem in our labs when running the ‘ping’ command with KDE Plasma running on X11 (not Wayland), that is when the kwin_x11 window manager is in use. Is everyone here using Plasma on X11?

    in reply to: Numlock OFF upon connection #51197
    fra81
    Moderator

    Hi,

    you’re right, macOS works as if the NumLock key was always ON, so the initial state of the NumLock key in the NoMachine session should be ON instead of OFF. This will be changed in a future release. Is this an acceptable solution for you?

    I would like NoMachine to just leave the NumLock status as it is

    This alternative solution would require deeper design changes and needs further evaluation.

    in reply to: Colours shifted #51132
    fra81
    Moderator

    Hi,

    can you tell us about:

    – Fedora version
    – Plasma version
    – Graphics card and drivers

    in reply to: Is VirtualGL working correctly? #50282
    fra81
    Moderator

    So now we know that VirtualGL works when used through vglrun, the only problem is with the environment, the reason of which is still unclear. Do you confirm that no system script overwrites, unsets, or affects in any way the LD_PRELOAD variable?

    LD_PRELOAD=/usr/NX/lib/libnxegl.so

    Please note that the libnxegl library has a different purpose (it’s used for capturing the screen from the physical display when Wayland is in use), it should only be set in the physical desktop and it’s not useful in virtual desktops. In virtual desktops, when VirtualGL is enabled, LD_PRELOAD should look like this:

    LD_PRELOAD=/usr/NX/scripts/vgl/libdlfaker.so:/usr/NX/scripts/vgl/libvglfaker.so

    env XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop /usr/NX/scripts/vgl/vglrun -d /dev/dri/card0 /usr/bin/dbus-launch –sh-syntax –exit-with-session /usr/bin/startplasma-x11

    This is definitely possible and, maybe, it could help with working around the environment problem. Note that you will have to disable VirtualGL in the server configuration (/usr/NX/bin/nxserver --virtualgl no) after putting the vglrun command in the DefaultDesktopCommand key.

    However, I would recommend a slightly different default desktop command from the one you posted:

    env XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop /usr/bin/dbus-launch –sh-syntax –exit-with-session /usr/NX/scripts/vgl/vglrun -d /dev/dri/card0 /usr/bin/startplasma-x11

    in reply to: Is VirtualGL working correctly? #50260
    fra81
    Moderator

    Hi @boospy

    [VGL] ERROR: Could not open display :0.

    Did you get that in the physical desktop or in the NoMachine virtual desktop? Can you run ‘env | grep DISPLAY’ in the physical desktop? If you find out that the display number is, e.g., :1 instead of :0, you can adjust the vglrun command in this way:

    /usr/NX/scripts/vgl/vglrun -d :1 glxinfo | grep -i “renderer\|vendor”

    Or, even better, you can instruct VirtualGL to use the GPU directly without passing for the X server. This is a new feature of VirtualGL. So, if the path to your video device is e.g. /dev/dri/card0, you can use this command for vglrun:

    /usr/NX/scripts/vgl/vglrun -d /dev/dri/card0 glxinfo | grep -i “renderer\|vendor”

    Using the -d option is equivalent to setting the VGL_DISPLAY variable in the environment (e.g. VGL_DISPLAY=:0 or VGL_DISPLAY=/dev/dri/card0).

    What’s the output of the vglrun command after these adjustments?

    The variable is displayed/read out correctly when I log in on the physical screen. Unfortunately not via the virtual Nomachine session.

    This is indeed strange, I suspect that something in your user profile is unsetting the LD_PRELOAD variable (I see that it is correctly set by the server at the moment it launches the desktop environment in the virtual desktop). Could you check if this is the case in your user profile files (.profile, .bashrc, .bash_profile, /etc/profile, /etc/profile.d/*, etc)? Or are you aware of anything that might be interfering?

    fra81
    Moderator

    Hi Chaoimin,

    I don’t have an explanation why restarting SDDM helps and restarting the NoMachine server doesn’t, since the nature of the problem is not clear yet, and we’re still unable to reproduce it on our labs. This could also indicate an issue in KDE Plasma rather than NoMachine.

    Can you please try to press a key on the physical keyboard of the laptop you use as a server when you reproduce the issue, and check if input events through the NoMachine session start working from that moment on?

    Did you restart the NoMachine server (/usr/NX/bin/nxserver --restart) after adding the DisplayServerExtraOptions “-eventdelay 0” option in the node.cfg file? Would you try again if you didn’t?

    Is there any screen lock app running on the server when the issue is being reproduced?

    in reply to: Libnxegl.so causes crashes of unrelated applications? #50134
    fra81
    Moderator

    Hi,

    is that the home dir of the same user who owns the desktop?

    What is the desktop environment (Gnome, KDE…) in use and version?

    Does ‘/usr/NX/bin/nxserver –eglcapture no’ help to solve the crashes? I forgot to say that you need to logout and login again, or reboot the host, to make this change effective.

    fra81
    Moderator

    @psantucc,

    while the test package is being prepared, can you tell about the GPU model and drivers version?

    It could also be useful to know about the GL/EGL version. To do that, you can run these commands in a terminal on the server:

    glxinfo | grep "OpenGL version"
    eglinfo | grep "EGL version"

    Before that, you may need to install ‘mesa-utils’ package providing the glxinfo command.

    Please also try to add this line into the /usr/NX/etc/node.cfg file on the server:

    WaylandModes drm,egl,compositor

    Then restart the NoMachine server. This will make an alternative capture method (“drm”) be used before the default one (“egl”). Does this workaround help?

Viewing 15 posts - 1 through 15 (of 718 total)