after initially struggeling to get the combination of xrdp and gnome to work on the Jetson Nano (I eventually gave up and switched to the Mate desktop. BTW that problems seems to be also swras_dri related), I am now trying to solve the next problem, again it seems to be related to the swrast driver / libgl environent on the Nano.
If I try to run glxinfo in a Mate terminal window while being in a xrdp session, I am getting the following error message(s):
$ glxinfo
name of display: :10.0
MESA-LOADER: failed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast
X Error of failed request: GLXBadContext
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 6 (X_GLXIsDirect)
Serial number of failed request: 53
Current serial number in output stream: 52
I already googled around, I even installed the latest MESA libraries and tools. Played around with LD_LIBRARY_PATH settings etc.
I also double checked the links to the key libraries. The swrast_dri.so file seems to be also in the correct location:
/usr/lib/aarch64-linux-gnu/dri/swrast_dri.so
I even created an additional link into /usr/lib/dri, but no change.
That problem doesnât show if I connect my Nano to a real monitor.
Is the error always same as âfailed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri)â even after you create link or include the path?
Unfortunately I cannot try to reproduce it again at the moment, since I started with a fresh JetPack 4.3 image last night in order to rule out any potential side effects of installing any other packages.
I will try to install xrdp again later today just to see if there is any difference.
As mentioned above, I came across that problem while initially trying to make xrdp work in combination with gnome.
Each time I tried to connect to my headless Nano using Microsoft Remote Desktop 10 (on MacOS) I briefly (<= 1 sec) saw a black window with the Nvidia logo which eventually disappeared. While repeating that connect test, I run a tail -f /var/log/syslog. In the syslog file I noticed the following entries:
Jan 30 10:47:27 demo-nvidia at-spi-bus-launcher[7186]: dbus-daemon[7191]: Activating service name=âorg.a11y.atspi.Registryâ requested by â:1.0â (uid=1000 pid=7184 comm=â/usr/lib/gnome-session/gnome-session-check-accelerâ)
Jan 30 10:47:27 demo-nvidia at-spi-bus-launcher[7186]: dbus-daemon[7191]: Successfully activated service âorg.a11y.atspi.Registryâ
Jan 30 10:47:27 demo-nvidia at-spi-bus-launcher[7186]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
Jan 30 10:47:28 demo-nvidia gnome-session[7005]: MESA-LOADER: failed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri)
Jan 30 10:47:28 demo-nvidia gnome-session[7005]: libGL error: failed to load driver: swrast
Jan 30 10:47:28 demo-nvidia gnome-session[7005]: gnome-session-binary[7005]: WARNING: software acceleration check failed: Child process exited with code 1
Jan 30 10:47:28 demo-nvidia gnome-session-binary[7005]: WARNING: software acceleration check failed: Child process exited with code 1
Jan 30 10:47:28 demo-nvidia gnome-session[7005]: gnome-session-binary[7005]: CRITICAL: We failed, but the fail whale is dead. SorryâŠ
The MESA-LOADER error seems to point into the same direction like the problem which I mentioned in my first post.
Quick update: I just did the following steps on my fresh JetPack 4.3 install:
I added the following key to the file â/usr/share/glib-2.0/schemas/org.gnome.Vino.gschema.xmlâ
Enable remote access to the desktop
If true, allows remote access to the desktop via the RFB
protocol. Users on remote machines may then connect to the
desktop using a VNC viewer.
true
I run âsudo glib-compile-schemas /usr/share/glib-2.0/schemasâ
I then installed xrdp via âsudo apt install xrdpâ
âsudo rebootâ
I am now trying to connect again to my Nano via MS Remote Desktop 10 and I am getting the same error as yesterday (see my post #3).
I have the same problem of AlexKoeMuc.
Iâm trying to connect to my Jetson TX via Microsoft Remote Desktop (Windows 10)
and xrdp, but and I am getting the same error (see syslog messages below) and seeing a black window with the Nvidia logo which disappears.
Feb 1 16:59:22 jetsontx2 gnome-session[7900]: MESA-LOADER: failed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri)
Feb 1 16:59:22 jetsontx2 gnome-session[7900]: libGL error: failed to load driver: swrast
Feb 1 16:59:22 jetsontx2 gnome-session[7900]: gnome-session-binary[7900]: WARNING: software acceleration check failed: Child process exited with code 1
Feb 1 16:59:22 jetsontx2 gnome-session[7900]: gnome-session-binary[7900]: CRITICAL: We failed, but the fail whale is dead. SorryâŠ
In a previous setup of the Jetson (about three weeks ago always with JetPAck4.3) I was able to connect but now in the same situation (fresh new setup and the same setting of xrdp) it isnât more possible.
Iâm not sure if actual xrdp version is the same of the first succesful setup.
I havenât tried a software fake screen yet, but I do have a dummy HDMI plug plugged in now. That dummy plug helps with my VNC setup, but doesnât seem to help with the XRDP session.
As soon as I will have a few minutes I will try a dummy software monitor/screen as well.
I started again with a fresh JetPack 4.3 image on my Jetson TX2.
Immediately after I installed xrdp WITHOUT updating the operating system and I can connect
now to my headless Jetson TX2 using Microsoft Remote Desktop on Windows 10.
I have tried with an attached monitor but also without it and the XRDP session works well.
Now I will try to update the operating system to see what happens.
Iâm having the same issue - itâs really easy to reconstruct:
rivermax@rivermax-jetson-platform:~$ glxinfo | grep âOpenGL versionâ MESA-LOADER: failed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast
OpenGL version string: 1.4 (4.5.0 - Build 25.20.100.6472)
I believe that the issue starts once you upgrade libgl1-mesa-dev - 19.2.8-0ubuntu0~18.04.1
on a different setup Iâm using version 19.0.8-0ubuntu0~18.04.3 and there is no issue there.
We are using the Jetson Xavier - this project is using Mellanox NIC + Rivermax SW to stream in/out very high BW (xGbps) of uncompressed VIDEO content.
We are using the GPU on the Jetson for Color Space Conversion - when running the code on the Jetson using HDMI there is no failure.
The failure is only when using SSH X11.
we are installing a long list of libraries - but I know the exact point which is stopped working since we have an image just before this point. updating the mesa-dev is causing the issue.
I can provide this Jetson image if you would like to debug it.
Also feel free to contact me directly nirni@mellanox.com
The library released by mesa may be not compatible with tegra graphic.
The failure is only when using SSH X11.
Why ssh? Arenât we talking about xrdp?
Based on our experience on vnc, you should add a screen section as below in xorg.conf.
----------------------------------------------------------------------
Setting the Desktop Resolution
----------------------------------------------------------------------
The desktop resolution is typically determined by the capabilities of the
display that is attached to Jetson. If no display is attached, a default
resolution of 640x480 is selected. To use a different resolution, edit
/etc/X11/xorg.conf and append the following lines:
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Tegra0"
SubSection "Display"
Depth 24
Virtual 1280 800 # Modify the resolution by editing these values
EndSubSection
EndSection
Thank you for the suggestion - Iâm not sure itâs related to the issue in hand.
Iâm connected to the Jetson using SSH - I donât need to display anything.
Iâm getting an error just by running this: rivermax@rivermax-jetson-platform:~$ glxinfo | grep âOpenGL versionâ
I will be happy to have a online session to demonstrate the issue.
Thus, when running glxinfo, you need to do something as âexport DISPLAY=:0â
According to the previous comment, I saw glxinfo would return âname of display: :10.0â. This sounds a remote display number and does not related to any nvidia display. That could be the reason that when you have no display connected, it is dead.
Do you mean error happens even when monitor is connected?
I investigated further and the problem occurs to me only when I update
the following libraries (the Installed version is the original one)
Why do you need to update these drm libararies? Could you share what is your current purpose?
Actually, the drm running on tegra is libdrm_nvdc.so. Please make sure libdrm.so links to this file or your might hit error.
Do you mean error happens even when monitor is connected?
Yes, the error also occurs when a monitor is connected via HDMI, obviously only remote accessing the Jetson Nano via xRDP protocol. Local access (not headless) has no problems whatsoever.
Please make sure libdrm.so links to this file or your might hit error.
I have verified that after updating the libraries (and so when the problem happens again) the file libdrm.so correctly links.
From now on I will update the system if I need it without ever updating the following libraries using the command:
apt mark hold libdrm-amdgpu1 libdrm-common libdrm-dev libdrm-etnaviv1 libdrm-freedreno1 libdrm-nouveau2 libdrm-radeon1 libdrm-tegra0 libdrm2
Regarding the use of the Jetson boards (we have to use several of them) I should use a java application (jdk 8u112 based) that uses the jfx library but I didnât find any useful information except that probably I have to use openjdk and openjfx. Could you give me some links about a complete working package?
@sorlando - Thank you for posting - putting these application on hold is also working for me (at least to avoid the mesa loader issue). Iâm pretty sure itâs related to the libdrm2 application but donât have anytime to tests.