Developing on NVIDIA® Jetson™ for AI on the Edge

Jetson – Allow Graphics without HDMI

On a recent project with a rushed development schedule, there was a little issue. The workaround of booting the Jetson into a graphics desktop without a monitor attached is worth sharing.


As is the case with a lot of projects that involve visual processing, the example framework for this project was written using a Graphical User Interface, or GUI. In the rush of development, this framework was used as the structure for building a demonstration application.

In this particular demo (Flying Robot Demo), an image stream is acquired from a camera sensor and each image is examined for the presence of a fiducial marker. The fiducial marker in this case is an April Tag, which looks like a big QR code. If a fiducial marker is recognized, then commands are sent out to the robot to control its position corresponding to the markers meaning. For example, a marker recognized as code 20 might tell the robot to move left 2 meters. A very simplistic concept.

Having a graphics program, in this case one written using the framework Qt, is useful for a person to help in the debugging purposes. In this case the camera stream is placed on the monitor, and any markers recognized are highlighted by placing a colored rectangle over the marker on the screen.

Now the computer doesn’t really care about this visual representation, it’s there purely to help the person writing the program. But here’s the thing: as a developer working with a tight deadline you need all the help you can get. The easiest thing to do in this case was to use the example framework and build on that.

Once the program was ready to be tested on the robot standalone, the demo program was marked as a startup application using the Startup Applications app through the desktop. In this case the permissions were fiddled with so that the program could talk to the USB camera. Everything was tested once more, to make sure everything worked on startup as expected.

Now this being a flying robot and all, you probably have guessed that the robot does not carry an attached HDMI monitor on board. So when the program was to the point that it was working on the bench and ready to be tested standalone, the monitor and external peripherals were detached and everything booted up. What happened next? Nothing. The robot sat there like a big fat pig and ignored any attempt at recognizing markers. Of course the natural inclination was to hook everything back up to make sure everything works. It does. Disconnect, startup. Nothing.

What Happened?

What took a little while to realize was that if there is no monitor attached to the Jetson, then the X11 graphics manager does not load, which in turns means that the desktop manager does not load. If the desktop manager does not load, the startup applications do not load. Then what happens? In this case, nothing. It just sits there silently like a big fat pig dog.

For most robot applications, programs are written as console applications. This allows for easy communication with the robot through SSH from another computer. Unfortunately in this case, the framework for controlling the robot is commingled with the graphics user interface. Given the short amount of development time available, it was unlikely that the program could be rewritten as a console app to meet the deadline.


After Googling like a chicken with its head cut off, the solution that was implemented for the demo was based on attaching a HDMI monitor emulator to the Jetson. Here’s the HDMI display Emulator used:

Headless Display Emulator @ Amazon

This emulator appears to the Jetson to be a HDMI monitor. X11 and the desktop happily load, none the wiser.

As it turns out after going to GTC 2016 and talking to knowledgeable NVIDIA people, there is a software workaround.

Allow X without HDMI at Boot

Edit /etc/X11/xorg.conf

Section "Device"
Option "AllowEmptyInitialConfiguration" "true"

Which will allow X11 to startup without a monitor attached.


So there you have it. If you wander down the wrong path during development, and find yourself in a similar situation of hopeless despair, you too can tell the developer gods “Not Today!” and snatch victory from the jaws of defeat.


13 Responses

  1. Hello, I did not have this problem with my TX1. I have only put it in auto-login with remote desktop activated. Don’t know if it is the reason it worked for me.
    The resolution is small in remote desktop but could be changed by “xrandr -s 1024×768”

    1. Interesting! Maybe the remote desktop activation does something at the lower levels to tell the desktop to load. Thank you for reading, and thank you for sharing.

  2. Where do you get the dongle. I’ve run into the same situation. Made it work but this way is a lot easier. For some reason on the mac it will fire up if you use the alternate X server for the mac and ssh -X.But if I try on Linux its no go although lightdm is running. I’ve made it work in the past on other machines its usually a major pain. The auth and display are the sticking points. Some of the ROS stuff like rqt and the messages for the Zed won’t compile on the MAC so the dongle will be a much easier way.

  3. I understand your requirements were for GUI for configuring the robot. But do you have any thoughts on how to disable VGA system altogether? Basically, i don’t want TX1 to have any desktop. SSH works and thats plenty enough. This will save bit of energy and not to mention precious memory/resources.

  4. I have bought a fit-headless, inserted in the tx1 hdmi mouth, set x11 /etc/X11/xorg.conf and restart, I use the pc machine how to connect to the tx1 desktop? Is the remote ip login?

  5. Hello. I’m using my jetson nano in headless mode and I’m experiencing a flickering problem using nomachine as client on windows 10 and no machine as server on ubuntu. Yesterday I’ve just bought the dummy plug model EZDIY-FAB HDMI and I’ve attached it to the jetson nano HDMI port. And under Ubuntu I went under monitor setting and I have chosen : “HDMI-0,resolution 1920 x 1080,refresh rate 60. In addition,I went under the display configuration panel of NoMachine and I’ve chosen “adapt to the window” ; I have also clicked on “modify display settings” and I have chosen “use a custom resolution to 1920 x 1080” ; quality = better. But the flickering problem is still there. Should I edit the xorg.conf file like you have explained ?

Leave a Reply

Your email address will not be published. Required fields are marked *


Some links here are affiliate links. If you purchase through these links I will receive a small commission at no additional cost to you. As an Amazon Associate, I earn from qualifying purchases.

Books, Ideas & Other Curiosities