Jetson Nano 4Gb no HDMI output

Yes I am always using ssh to access the jetson nano, in fact now, I am using remote desktop but it’s laggy. I don’t know what you mean by " specifying a DISPLAY environment variable" but I am not using that.
You recommend I stop the desktop remote connection then write the commande lines ?

Some background might be useful…

When Linux boots it first gets to a text-only command line state, which is actually a getty program (or variant) running. When the GUI (X) runs, it replaces the getty. Many people don’t realize this, but there are many text consoles, usually keys F1 through F6 switches between them if you are only in text mode (in the GUI it would be ALT-F1 through ALT-F6 most of the time). The fact is that by default X only takes over one getty. However, you can run multiple independent X sessions by setting it up on another console.

The method the software uses to define which X server you are connected to is via the DISPLAY environment variable, which is normally inherited (or set up) at the start of the X login. When you use ssh, or when you use xinit, this may not work correctly. The method with systemctl to control will set it up correctly for that local machine, but something like ssh might not have any DISPLAY set up, or it might inherit from the wrong DISPLAY environment variable.

If you use “ssh -X” or “ssh -Y” to talk to a remove computer, then DISPLAY is being automatically set up to point to the X server you are running on the host PC. Using just ssh without -X or -Y implies there is no DISPLAY variable set up. Using the wrong DISPLAY tries to associate the server with the wrong monitor; using no DISPLAY fails entirely because it has no “context” to define where to display.

If you are on any X login on Linux, e.g., on your host PC, on a command line check this out:

There are variations on this, but typically the first GUI would echo “:0”. The second would typically be “:1”. If you look at logs in “/var/log”, you might be interested in this output:
ls -ltr /var/log/Xorg.*.log

The number in the name of the log, e.g., Xorg.0.log, is the value of the DISPLAY. If you have two X servers running, then you might see both Xorg.0.log and Xorg.10.log. The numbering is not necessarily sequential, but by tradition local displays would use 0 through 9; the remote display to another computer will (by tradition) usually start as 10 (with “DISPLAY” being “:10” or a minor variant).

Your xinit script might (probably) not be setting up correctly when accessed over ssh. Sometimes it doesn’t set up correctly even on the local system unless it has been tweaked to deal with multiple servers.

If there is already a server running via the systemd (“init”) service, it might be from “export DISPLAY=:0” of the first console before starting the X server (which would overwrite the getty and replace it, or else run on top of it).

Remember that when I said to look at the Xorg.*.log files I did not just say to use ls, but instead to use “ls -ltr”? What that does is to list the files in reverse chronological order. That means that the last log listed is the one which is modified most recently. The timestamps are in order this way. If you were to run “ls -ltr /var/log/Xorg.*.log” prior to trying to run an X server, and compare it to just after trying to run the X server, then you should find that the last listed log is the most recently modified, and that the number in the log name corresponds to the DISPLAY. If that log is Xorg.1.log, then the server that tried to start used a DISPLAY of “:1”. This log file would be one to post here. If none of them were modified, then something more serious went wrong. If setup over ssh is wrong, then you might be something totally unexpected as it forwards to the X server on the host PC and does not even run on the Jetson. A VPN would likely show :10, a local server would likely show :0 or :1, and a remote server might only show up on the remote host PC.

If you are on command line, and if the monitor is attached to the Jetson, and if you are not using ssh with either -X or -Y, then this might alter the result of xinit:

export DISPLAY=':2'

Mostly I incremented that number because there might be a local server associated with the display and :0 might collide with that. Try the above with the export of ':2' and see if anything changes. For experiments like this always first check the timestamps in “ls -ltr /var/log/Xorg.*.log”, and then compare after the startup attempt. Then post the most recent log from that attempt.

I am using ssh through visual studio this time.
After running the command : xinit I always get the same output:

_XSERVTransSocketUNIXCreateListener: …SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
Fatal server error:
(EE) Cannot establish any listening sockets - Make sure an X server isn’t already running(EE)
Please consult the The X.Org Foundation support
for help.
(EE) Please also check the log file at “/var/log/Xorg.0.log” for additional information.
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

After that I ran : echo $DISPLAY and the output was just blank (nothing showing)

Running this command : ls -ltr /var/log/Xorg.*.log I get this :
-rw-r–r-- 1 root root 9159 nov. 1 17:24 /var/log/Xorg.0.log

But after running export DISPLAY=‘:2’ , I echo $DISPLAY and get : “:2” this time around but nothing showing on the monitor screen.
I try to run xinit another time but same result (error as before)

Here is the most recent log :
xorg_0_log.txt (11.2 KB)

When I move to remote desktop, echo $DISPLAY outputs :10.0
as you mentioned earlier

The timestamp on that log is this:
nov. 1 17:24

Unless your Jetson had the date of Nov. 1 set when you tried to start X via xinit this log is not a result of that command. Here is at least one problem: Your Visual Studio is not first exporting the DISPLAY environment variable. Or, if it is exported, there is another issue. Probably it is both the DISPLAY not being set and some sort of permission error.

Is it correct that you want the monitor which is connected to the Nano’s HDMI to be what starts? It is better if you start X as a service with the “sudo systemctl isolate”. If you just want X to start and be owned by a particular user, then you can use xinit, but this is antiquated and you might need to add more arguments, e.g., setting up for a different DISPLAY.

100% of all of your initial testing when using xinit should be from trying this at a local terminal. You might need to edit ~/.xinitrc. You might need to specify geometry. You might need to tell it which desktop manager to use. The service from “sudo systemctl isolate” does not have that weakness, it is already set up. A good reason to try xinit is if you want to manually run a second X server while the first is running. As is, it won’t matter if it is a Jetson or a desktop PC you try this with, it wouldn’t work if the environment is not set up due to your remote setup.

Can you log in locally to the Jetson on command line for testing? Once you get xinit working there, you can examine the environment and use that to help with starting it over ssh and visual studio. Or…you could send the command sudo systemctl isolate from visual studio over ssh and see if that works.

What do you mean by “log in locally to the Jetson on command line for testing” ?

All I can do is either access the jetson via ssh or remote desktop.
I think you mean to access it via remote desktop then run the “sudo systemctl isolate” command right ?

Note that when I use remote desktop and run the “xinit” command I get an error, and that also applies to when I access the jetson by ssh (visual studio). So the “xinit” command never worked for me, I always get that error I posted earlier.

If the Jetson is physically available, then you can also log in via serial console. Here is a fundamental question: How do you see the graphical display if you are not sitting next to it? There is an enormous difference between remote display to a host PC versus bringing up the GUI on the Jetson itself as commanded by a remote system. If you run “sudo systemctl isolate”, then this is for the GUI on the HDMI connector of the Jetson, and is not a remote desktop. That command is not used in a GUI, it is used to start and create a GUI on a system which is not currently running a GUI. That command is independent of whether it is started locally on command line or remotely via another computer (the Jetson would neither know about nor care about the remote computer sending the systemctl command).

xinit has more options, but for remote use, if you want to remote display, then this is not what you think it is. Incidentally, X can remote display to another host PC if that PC runs Linux and if that PC already has an X server running and if that X server has all compatible requirements. However, this is not a remote desktop, it is something else. Knowing exactly what you are doing in terms of expecting display locally or remotely matters a lot.

When I run sudo systemctl isolate, I get this :
client_loop: send disconnect: Connection reset
And the ssh connection terminates, but nothing showing up on the monitor.

Note that when I boot the jetson while plugging the hdmi cable, it shows the “nvidia” logo and the lines that always appear on the start of the card but after that, the “nvidia” logo appears one last time and then the screen goes blank !

Is this through visual studio? Do you have the ability to connect via command line ssh from another Linux computer? It sounds like your ssh is configured to forward the X server to a Windows machine, and Windows does not have that capability (Linux emulation could make this possible, but then it isn’t Windows anymore). In the case of ssh with any kind of forwarding it is going to try to start the X session on the PC originating the ssh, even if it is Windows (which won’t work), or else forwarding the session to a running remote X server (which would have to be running on Windows, and Windows does not run an X server except via an emulation).

It is rather important to know:

  • The monitor is physically attached to the Jetson’s HDMI.
  • If the command starts via ssh, then the ssh must not be using any forwarding options.
  • If the command is via systemctl, and if the login is over serial console, then one would not set the DISPLAY environment variable (“echo $DISPLAY” would return empty for this to work).
  • You cannot remote display X graphical programs over a serial console.
  • Forwarding X graphical programs over ssh could work, but that requires the computer originating the ssh connection to already have a compatible X server…this will never start a GUI through the Jetson’s local HDMI connector.

Now if the screen goes blank, then it might be because the server works, and X starts, but video configuration is invalid. This should never break an ssh connection, but there are some methods of connecting via ssh which are intended to run for one command only and to not remain connected. There is some mystery in part because you’re not just using ssh from another Linux system.

Note that the NVIDIA logo is normal during boot. Even if the software is correct though, this is all you will see if configuration is not correct and the system is fully booted. Do you have another Linux system to run a serial console from? Or a Linux system to run ssh from? This would make testing a lot easier if we could at least temporarily test with visual studio or Windows.

Unfortunately, I don’t have a linux system, all I have is the windows OS.
And what I can do is to either run ssh from cmd or visual studio or do a remote desktop (windows or real vnc viewer) and access the jetson and have its output on my laptop’s screen.

Can you use PuTTY on either the serial port or via ssh? Something that has a continuous login rather than single command, and something which does not use visual studio (which might change the environment)? In either the ssh case over PuTTY, or in the serial console case, what do you see from “echo $DISPLAY”? I’m hoping nothing shows.

When I connect using putty ssh, running echo $DISPLAY displays nothing. (no monitor, HDMI cable, attached to the card)

Using PuTTY should not have a DISPLAY, so that is correct. From PuTTY, first see what log timestamps are via the “ls -ltr /var/log/Xorg.*.log”. Then see what happens if you have a monitor on the Jetson, and run:
sudo systemctl isolate

After this (I’m assuming it fails, but maybe it will work), see if there is a new log or timestamp. There is a lot going on when running xinit and there is also a lot which can fail from that command, but the system service is more likely to work as long as you have not installed any alternate desktop or X server (the default is a very good indicator and logs are usually good from this).

If there is a new log as a result of the ssh (or serial console) over PuTTY, then attach it to the forum. Note that it is possible to use PuTTY to log a session, so if it is difficult to get the file, you could start logging, run the command (alter this if the log file name differs) “cat /var/log/Xorg.0.log”, and then stop logging, and you will have the log on the host PC.

Running this command

I get :

And when I run this command :

Nothing happens.

When I run “xinit” I get the same error (over serial console this time).

_XSERVTransSocketUNIXCreateListener: …SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
Fatal server error:
(EE) Cannot establish any listening sockets - Make sure an X server isn’t already running(EE)
Please consult the The X.Org Foundation support
for help.
(EE) Please also check the log file at “/var/log/Xorg.0.log” for additional information.
(EE) Server terminated with error (1). Closing log file.
No protocol specified
xinit: giving up
xinit: unable to connect to X server: Resource temporarily unavailable
xinit: server error

Here is the latest log file when typing “cat /var/log/Xorg.0.log

xorg_0_log.txt (11.3 KB)

It is quite odd that nothing shows up with the systemctl command. I am curious, on the monitor which is attached to the Jetson, is there any flickering or any kind of change when you run the command?

For the xinit version over serial console, you might try this instead:

export DISPLAY=:0

# Optionally:
sudo xinit

Well this time, running export DISPLAY=:0 and sudo xinit I got this message:
xinit.txt (1.6 KB)
and a little white window (I think it was a terminal) popped up on the monitor for only few seconds, then it went blank again.

I tried another time but sometimes it would work and most of the time it would just give the same error.

Have you modified any files for X? Or have you added or removed any packages at any time related to Xorg or the desktop display manager? What was fascinating about that log file is the lack of content, like whatever it tried to start simply did not exist.

I ran this command days ago because I was having other problems with the board, I don’t know if this has something to do with the problem sudo apt-get update && sudo apt-get install nvidia-jetpack.
I went to the documentation[] of the board (it is a jetoson nano but the carrier is different than nvidia’s) and found that updating some kind of drivers might interfere with some functionalities like the HDMI output !

That command is ok, it shouldn’t cause issues with the X server. However, I don’t see previous mention of this being from Auvidea. The Auvidea carrier board probably requires device tree changes, and this does indeed cause HDMI failure. What it comes down to is that the module can optionally route different electrical lines to different pins to make it easier for different carrier board manufacturers. Part of what a device tree does is to set up which trace gets which function. It is extremely likely at this point that the wires are just going to the wrong places.

On rare occasion a third party carrier board manufacturer will have the exact same electrical layout as does the developer’s kit, in which case they could just state to use the Jetson default flash software. Otherwise they will either provide a patch to the developer kit’s software from NVIDIA (basically a device tree edit), or else provide a modified version of the dev kit flash software (which mostly differs in device tree). You’ll need to flash with the Auvidea software.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.