In the documentation for the samples, e.g. in 08_video_dec_drm, we are told:
Ensure the Ubuntu desktop is disabled:
$ sudo systemctl stop lightdm.service
Whenever I do this, my TX2 just goes to a black screen with some messages and becomes unusable until I reset it. Why?
EDIT: I forgot to add, see this (video issues relative to lightdm.service are a subset of this topic):
https://elinux.org/Jetson_TX2/r28_Display_debug
FYI, I am referencing R28.1.
Sometimes things don’t behave as expected when newer systemd style init is mixed with old script style init…I don’t know of any distribution/flavor of Linux which has gone purely systemd, but it is the method of the future. YMMV. Keep that in mind…
Normally init starts various services in a particular order since some services depend on others. Part of this is to make available multiple text-mode sessions as you approach multi-user.target (Jetsons’ version of Ubuntu doesn’t follow this exactly the same as desktop Ubuntu). At this point keyboard bindings for “ALT-F1” through “ALT-F6” (maybe F7?) trigger a different non-GUI shell login prompt. Basically this is the getty daemon. As graphical.target starts getty on ALT-F1 (for Ubuntu) is replaced by X (which indirectly means a login manager and a desktop manager…lightdm is part of that).
If it behaves correctly, then “systemctl stop lightdm.service” will stop the GUI on ALT-F1. At that point most systems would revert to running text-mode on ALT-F1 as if it is multi-user.target instead of graphical.target. This is where things can go wrong.
Video configuration for for text mode (multi-user.target) versus graphical mode is done by different software (depending on if it is GUI or text). Each may try to operate at different settings, e.g., the GUI might be set to run 1920x1080, while some independent setting might make the text mode console run at 800x600. Having one work does not imply the other should work (well…philosophically they should work…but in terms of expecting one part of the software to work the same way that completely different software works would be technically incorrect). Running “systemctl stop lightdm.service” implies you are switching which software is configuring video…it isn’t telling a single piece of software to change, it’s telling a different software to replace another.
So although it doesn’t eliminate your question perhaps the problem should be restated as to figuring out why this particular monitor behaves correctly under GUI, but not under text mode. One possibility is that the console modes are not compatible with the driver. Another possibility is that the monitor is compatible, but the software designed to switch modes when going from graphical to text mode is not correctly forwarding the information to other software. It may be a bit of a mix of both.
One thing I see on one of my systems is that if I am logged in to a local console and run “sudo systemctl stop lightdm.service” it correctly switches to console mode on ALT-F1 through ALT-F6. On the other hand, if I am already in graphical.target and power saving mode is running (a period of inactivity), and not on a text mode local console, I can do a remote login over ssh and run the same “sudo systemctl stop lightdm.service” and the driver tries to run at a scan rate out of range of my monitor. The monitor is black because the driver incorrectly switched to a mode which isn’t valid…one would think that starting at a console and starting at a GUI and then going to console would result in the software always going to that same valid mode as if I had started already in console mode. It doesn’t in some cases (such as when power saving mode has been running).
So here are two things to perhaps look closely at. When you stop lightdm.service, do you see your monitor claiming (even if briefly) the mode is out of range? If you are on a local command line and power saving mode has not begun, do you have success (versus if you wait for the monitor to power down first through inactivity)? It’s a bit difficult to test if you have to wait for timeouts.
I’m not pressing any ALT-F# keys. As soon as I type the command into the console, this screen comes up and it freezes here until I reset it.
Apollys,
This is normal after you disable lightdm. Without X11, it will use console mode.
Can you still ssh to device?
Or try both CTRL-ALT-F2 and ALT-F2…see if you can get to a login that way. getty should spawn a text-based login prompt when it sees the right key binding.
