HDMI Output Control

Autonomous Machines Jetson & Embedded Systems Jetson TX1
1

First off, I am working out of my element with the TX1 and embedded systems in general, so might be missing the obvious. Before I start off down the wrong track, I am hoping someone can point out an easy way of doing this.

My main goal is to have a blank output on the HDMI, but still be able to send video streams to it. I don’t even want the boot sequence to show up on there. The HDMI will be used to drive some external display systems that I really don’t want cluttered up.

I have done something similar on the Raspberry Pi before. The official touchscreen automatically takes over as the primary display, leaving the HDMI output blank, even during bootup. OMXplayer can still send videos, or other streams to the HDMI display.

My current best guess solution is to setup the serial console as the display path for the main boot text, and replace the unity desktop with something simpler. This seems a little convoluted though, and prone to breaking something. Is there another, more obvious way to do it?

In a perfect world, the normal unity desktop would still be available, but only accessible over VLC etc. I would be fine with just ssh and/or serial control access though. The main thing is to limit the output over the HDMI to only what I want, and nothing more.

Can someone also point me at how to control the HDMI resolution settings? I am not sure I can rely on a clean handshake and want to be able to force it on the TX1 end. Most of the solutions I can find don’t work on embedded systems.

Thanks in advance.

2

The questions seem somewhat general, so my first set of information here will be unlikely to tell you what you want…instead it is geared more towards finding out more about what you really want to do.

In general, a Jetson under L4T is no different than any Ubuntu system. If you used L4T R24.2, then this corresponds to Ubuntu 16.04 LTS. If you used an older L4T, then a Jetson would use Ubuntu 14.04 LTS. Most documentation specific to Ubuntu version applies to the Jetson.

Some kernel arguments have an effect on boot behavior, including arguments controlling which runlevel the system boots to. Those arguments are part of the “APPEND” key/value pair to a boot entry in “/boot/extlinux/extlinux.conf” (this APPEND key/value pair is one very long line, don’t let line wrap fool you…keep it as one long line to avoid breaking it).

Should you want the video to stop at text mode instead of graphical mode, some systems allow using kernel parameter “text” to do this. In newer systems, you would add “systemd.unit=multi-user.target” to stop at text mode. To avoid echo of lots of startup messages to console, you would typically add the argument “quiet” to the kernel arguments.

When using graphical mode people often do not realize that X11 is separate from the window manager and login manager. X11 supports a single graphics program, and has no login/user knowledge other than who it runs as. A stock Linux system will run a login manager (e.g., kdm, gdm, xdm) as the argument to X; upon picking a user to login as, X restarts as that user, and instead of naming the login manager as its argument, names a window manager (e.g., unity, KDE, or some GTK desktop window manager). You can replace the argument run by X at start to be your program, and X will run just your program without any window manager or login manager (be sure to set it up to run as your user if you don’t want it to run as root). You could set up the login manager to remain as is, but to only offer some custom program once logged in…you’d avoid the window manager. None of this is specific to a Jetson, the information is the same on any Ubuntu system, and often among different Linux distributions as well (different distributions tend to differ in defaults for X, and not in general setup).

The part which does differ in Jetson is that the driver which X uses is specific to the Jetson hardware. You could not use a different version of Xorg with that driver unless the new version supports the same ABI version.

If you don’t want a monitor attached, but still want the GPU to work, you may want to install a virtual X server matching the Xorg ABI (virtual desktop software does this). GPU software works through the nVidia driver which implies you need the X server to load the driver…else you go back to software rendering and would lose CUDA.

X can have multiple monitors, and each can be configured to be active or inactive. You need a monitor to have proper EDID response if you will use automatic configuration. Without EDID you can still fill in the xorg.conf file by hand, but this is a non-trivial task to convert raw detailed specifications of the monitor into modelines if someone has not already provided this. The topic is not any different under a Jetson with L4T than it is for any other X11 information for any other Linux distributions.

3

Ok, my apologies if I overestimated my knowledge level, but most/all of that went so far over my head I have no real clue where to start researching to be able to even understand most of it properly.

Best I can parse it, is that there is no easy way to change things, so I will have to resort to a bodge and hack to make it do what I need. It’s a shame, because I know a lot of it is easy on things like the raspberry pi, but also different enough to prove to me the guides for standard ubuntu won’t be useful to me. I don’t know enough about the differences to translate the critical parts.

I have ran across “/boot/extlinux/extlinux.conf” but lack the knowledge needed to understand it, and most of the info I can find is aimed too high above my level to process.

If it helps advice though, my goal has 3 main steps.

  1. Divert the boot text somewhere it doesn't end up on the hdmi display
  2. Leave the HDMI display blank, but functional
  3. Pipe video from GStreamer etc to the HDMI display
4

You’ll be happy to find extlinux.conf is fairly simple to use. What it comes down to is that on any embedded system the boot loader loads a configuration which has a number of setup items in it. This is extlinux.conf (if it were grub it’d be equivalent to grub.cfg; if using fastboot it’d be equivalent to a hidden partition with binary data).

Shortly after the top of extlinux.conf (the preamble) there are a set of KEY/VALUE pairs. The set is the boot entry. Specifically, FDT tells u-boot where to find the “.dtb” firmware device tree…this sets up some registers prior to handing off to the kernel (used because in some cases kernel drivers need this set up prior to the driver itself loading). The INITRD is the ordinary initial ramdisk, nothing more than a temporary file system with some critical files. LABEL and MENU LABEL just provide a unique name for the boot loader to call that entry (LABEL), and what that entry looks like if you see it in serial console (MENU LABEL).

If you are writing drivers and setting up a custom hardware environment, you might be interested in the file pointed at by the FDT entry. Most people won’t care.

A lot of people are interested in the APPEND KEY/VALUE pair. This is the command line which is appended to the kernel on boot. This gives all kinds of interesting settings for things like drivers, video modes, security…you name it, if the kernel can do it, then probably an APPEND value can be passed to the kernel here to get the kernel to do it.

A big example would be the entries related to serial console, or the entry naming the root partition as mmcblk0p1. You could add an entry here to tell the system to stop at text mode and not boot all the way to graphical mode. If you have a driver you want to allocate a custom amount of extra memory to, you could probably do that with the APPEND entry.

The APPEND entry would probably ideal to divert boot text. Notice that APPEND is a very long single line, and even if line wrap makes it look like multiple lines, it isn’t. Just append a space to separate anything you want to add at the end of the line. Sometimes adding “quiet” here causes console to not see all those log messages. If this were a desktop system, then the same thing would be done in the grub config.

When graphical mode is unmodified, normally what happens when reaching graphical mode is the the X server is run to support a single graphics program. That graphics program could be your GStreamer app. Normally though the X server is told to run a login manager which can prompt for a login name. Once a login name is accepted, X runs the window manager instead. Sometimes if automated login is set up, then X will go directly to the window manager without the login manager prompting for a password. Your goal would be to look at the X server configuration and tell it to never run the login manager and to never run the window manager. Instead, you would replace this with your GStreamer app.

NOTE: X configuration is in “/etc/X11”.