how to unblank display screen( VGA) which is running a custom app

dear all,

I’m working on Tx1 platform with driver package Tegra210_Linux_R24.1.0_aarch64.tbz2.

Now, I have difficult to make our own app display all the time on the VGA screen because of screen becoming blanking after several minutes (about ten minutes).

Following is the way to startup our gui app.

Firstly, I disable ubuntu desktop.

  sudo chmod -x /usr/sbin/lightdm

Then ,I add our binary in /etc/rc.local for autostart. I add a few lines below.

 #!/bin/sh -e

 Xorg &
 export DISPLAY=:0.0
 /home/ubuntu/binary &

Finally, I restart the system. The binary (openGl app ) runs successfully (tx1 boot directly to run the app without ubuntu desktop ).

Everything seems well running. But several minutes (about 10 minutes) the display becomes blank （black screen ）. The phenomenon is similiar with PC got into power saving mode.

After that, I browser the web and get several ways to solve it, but all failed. Following below.

1. One is that the system have blankinterval time which defined in kernel vt.c. So I just modify the value , but the display has no change.

2. Someone says it is associate with console (tty1-6).
   setterm -blank 0

3. Xorg conf
   xset s off

All three ways I tried failed to make it .

Any answers is appreciated . Thanks in advance[b][b][/b][/b]

I don’t know the solution, but it seems likely you have run into a power saving setting thinking there is no activity, so blank. You may not want to remove power saving or screen saving or blanking entirely…you might add your use-case to see how you want it to behave.

There is an rc (init) script for “ondemand” which might be a workaround, though it is unlikely to be a real solution. Try:

sudo update-rc.d -f ondemand remove

Thanks , linuxdev.

I try the commands right now , but it shows warning.

sudo update-rc.d -f ondemand remove

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_PAPER = "zh_CN.UTF-8",
	LC_ADDRESS = "zh_CN.UTF-8",
	LC_MONETARY = "zh_CN.UTF-8",
	LC_NUMERIC = "zh_CN.UTF-8",
	LC_TELEPHONE = "zh_CN.UTF-8",
	LC_IDENTIFICATION = "zh_CN.UTF-8",
	LC_MEASUREMENT = "zh_CN.UTF-8",
	LC_TIME = "zh_CN.UTF-8",
	LC_NAME = "zh_CN.UTF-8",
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").

Also, I check all my rc.d directory in /etc/ . All the ondemand init script name is K01ondemand , it just shows the service doesn’t work on my current system.

I also check with below command.

systemctl status ondemand

it shows “Active: inactive (dead)”

So, I think this ondemand service doesn’t run on my Tx1 (custom board with Tx1 soc module) (sample rootfs version R24.2.1) default.

Is there another way to make it ?

I’m thinking now the on-demand was from a TK1, so you are probably correct and the service may not even be relevant despite existing on other platforms. The locale messages are probably unrelated and not an issue.

It does still seem that what you are experiencing is blanking from “non-use” time…a power saving feature which can be disabled from the desktop GUI setup, but I’m not sure which files may be affected by this. If you are running an interactive GUI it shouldn’t be too difficult to just log in and look for power saving and screen saver type settings and disable them. Is it correct that you are interested in the blanking not occurring at all? Versus wanting blanking to occur, but then unblanking to function? Is this a case of wanting “always on” behavior?

Yes, for our custom board ,we don’t use mouse or keyboard.

In other words, we don’t run a initeractive Gui.( just communication with rs232 or rs422 in ttyTHS2 )

I just want the blanking not to occur at all. That’s what we need.

Is there any suggestions ?
Thanks

I’m struggling a bit to find the right file. Normally I’d be able to say to log in as that particular user, then go to “All Settings → Brightness & Lock”, then set screen off and lock to “never”. Since you have no video this needs to be set by file edit or command line (preferably file edit). Plus the X server may need its own settings.

What I did was add package “fatrace” and try to trace file modifications. Sadly, it seems that even with kernel CONFIG_FANOTIFY and CONFIG_FANOTIFY_ACCESS_PERMISSIONS there is no ability to run fatrace. Regardless, one of the things I hate about any operating system is when only a GUI is provided as an interface and the details of how it works are hidden. A GUI only supports end users, it does a lot to hinder developers and manufacturers if that information is not there (shame on Ubuntu, or at least Unity!).

Question for NVIDIA: Does someone here know if, despite enabling CONFIG_FANOTIFY, there is an architectural limitation stopping arm64 system call “fanotify” from functioning? I would think that with the option enabled and compiling this would not be an issue unless there is a kernel problem with this architecture, or if the architecture itself causes failure.

So I ended up just manually looking around and comparing. Looks like lock and screen saver defaults are from “/usr/share/applications/unity-screen-panel.desktop”. Only this is probably just for setting up the application icon and such and not the actual config. What it does is offer that the command line to start the GUI for these settings is from that user running:

unity-control-center screen

From there strace and ltrace can be used. After billions of lines of output under strace (ltrace faults…I doubt there are enough electrons in the universe to display that many lines…or perhaps my monitor ran out of ink), there are a number of file stats to “/home/ubuntu/…”. Mostly “~/.config/” and “~/.local/” would be involved, so limiting to that, and using “ls -ltr” to see what was modified when. Even with this I could not find what file is used…I am thinking modifications would not be written to file until exit of the session.

So I exited the session. I couldn’t zero in on any particular file. Perhaps one of the sqlite format files was involved, but this would imply it can’t be hand edited.

So here is my workaround suggestion…
Create a session somehow for that user, and then on command line, run:

unity-control-center screen

I am thinking that if the user login name matches your user (you might want to run this under each user name you use), that it won’t matter where the GUI is displayed to, and that changes to the GUI app being displayed on a remote host will still apply to that user. Example:

ssh -Y ubuntu@tegra-ubuntu
unity-control-center screen
# Disable screen lock, power down, so on...
# Reboot and see if when you run this again the settings match what you changed previously...
# See if this stops the screen off you were being plagued by.

Thank you very much , linuxdev. Your suggestions broaden my mind a lot. I’ll have a try of your suggestions.

I also have tried using xset tools to solve it for these days, though it’s not fully a succeess.

You know the Gui app must be started by x-window, so I search something like “the way unblanking x-window or …”

I am told to use xset which can shut down dpms (display power manage signal).

In that case, I connect the board with host by remote ssh login, and use below command line after screen blank.

xset -dpms

then my screen is waked up again , but the gui app is dead.

After that I just make it autostart with the gui app , but the errors “can’t open display :0.0” are always showed.

I am also trying it too. It may be a available direction.

A “DISPLAY” environment variable is a bit misleading in name. Every system with a monitor attached has a buffer which the monitor views. Every GPU that does work has a buffer it works on. Historically, the buffer the GPU works on would be the same buffer the monitor views. As soon as you talk about no local monitor on the system with the GPU this breaks. It’s a bit long (on purpose), but perhaps a better name than “DISPLAY” would have been “STANDARD_VIDEO_BUFFER_WHICH_FOLLOWS_STANDARDS_MONITORS_CAN_UNDERSTAND_AND_MIGHT_ACTUALLY_USE”.

Case 1: You do a remote display to a PC you are sitting at while you are logged in to a Jetson and running commands, e.g., “ssh name@wherever”. The command is not GUI dependent. The command will run entirely on the Jetson, and any stdin/stdout/stderr will essentially redirect through ssh to the PC’s terminal. No GPU involved. Running a command which tries to use the GUI results in an error due to no DISPLAY found.

Case 2: Once more you do a remote display to a PC while logged in to the Jetson and running commands. This time you log in via “ssh -Y name@wherever” instead of just with “ssh name@whereever”. The ssh option “-Y” (and some others not illustrated) forwards X11 to your PC’s DISPLAY. Commands which produce only text still redirect stdin/stdout/stderr to your PC’s terminal. Running a command which requires a GUI now works. Not only is stdin/stdout/stderr redirected, so are X events. A command such as “firefox” or “xterm” causes that application to display on the PC, yet run from the Jetson. GPU on the PC is doing the rendering. The rendering is a result of X events being forwarded in the same manner as stdin/stdout/stderr events.

Note that when the GPU is used via the X interface (and the NVIDIA driver must match the X server ABI) that all rendering and GPU starts because X interpreted an event and sent the proper command to the GPU. No event, no GPU.

Also note that when you forward an event from Jetson to a remote host that the X server on the Jetson never sees an event. You bound all X events to the PC’s X server. The PC will now require all drivers and APIs, e.g., OpenGL and CUDA use the GPU where the X server sees the X events. Complaints of no DISPLAY are complaints that there is no pipe to an application which understands X events…it isn’t a complaint of no monitor. Further below it’ll be illustrated to show input devices and video have separate event channels. Often the two are redirected together, but this isn’t mandatory.

This latter case also illustrates that only a remote system with X and with supporting hardware and libraries required by the running program’s GPU use can do such a remote display. Math, logic, file system access…these would still go to the Jetson…these are all CPU access.

Case 3: Use a virtual desktop. There is a buffer on the Jetson even when no monitor is attached. The X server makes a DISPLAY available which binds events such that the GPU driver now manipulates a buffer with no physically attached monitor. X and the GPU don’t know this, and they don’t care. No matter where or how you log in to the Jetson all NVIDIA driver and X events and system support run from the Jetson.

A side-effect of a virtual desktop X server is that instead of forwarding events, the actual buffer is forwarded (there would be a lot of tricks going on here with compression, and the XInput is a separate module loading into the X server and you could still forward X input events from mouse/keyboard…but GPU will be 100% pure Jetson at that point). One would need a virtual desktop program to talk to the GPU results instead of using ssh to forward graphical events. This includes use of “xset -dpms” and having a place for autostart apps. Run your virtual desktop as the user for all of this and it will “magically” work even without a monitor. You’d be able to see any desktop via a virtual desktop program regardless of whether it runs on Linux, Mac, Windows, or even an iPhone.

I’ll suggest that running into issues of no DISPLAY is the same as saying you need a virtual desktop X server. Some information on one of the many possibilities can be found here:
[url]http://ubuntuhandbook.org/index.php/2016/07/remote-access-ubuntu-16-04/[/url]
[url]https://devtalk.nvidia.com/default/topic/1001017/jetson-tx2/remote-desktoping-into-jetson-tx2-from-windows-10/post/5123184/#5123184[/url]
[url]https://devtalk.nvidia.com/default/topic/995621/jetson-tx1/jetson-tx1-desktop-sharing-resolution-problem-without-real-monitor/post/5159559/#5159559[/url]

CUDA loves a GPU buffer. CUDA loves a virtual desktop buffer. Feed CUDA, keep CUDA happy :P

Hi, linuxdev.

Thank you for your patient answers.

I just understand your suggestion of using command lines “unity-control-center screen” .

So I login Tx1 from remote PC (my host pc ubuntu 14.04) by ssh, like below.

ssh -Y ubuntu@192.168.1.200

I also tried

ssh -Y ubuntu@tegra-ubuntu

， but it failed to login in.

Then I get into the Tx1 system in local terminal(pc) successfully.

After that, I just input below command lines:

unity-control-center screen

but it shows below errors:

ubuntu@tegra-ubuntu:~$ unity-control-center screen 

(process:1466): Gtk-WARNING **: Locale not supported by C library.
	Using the fallback 'C' locale.

(unity-control-center:1466): Clutter-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.

(unity-control-center:1466): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL' failed
Segmentation fault
ubuntu@tegra-ubuntu:~$ unity-control-center screen 

(process:1468): Gtk-WARNING **: Locale not supported by C library.
	Using the fallback 'C' locale.

(unity-control-center:1468): Clutter-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.

(unity-control-center:1468): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL' failed
Segmentation fault

However, When I tried another command lines for test , it succeeds.

gedit .bashrc

I succeessfully open the .bashrc file with gedit in local host.

Is it possible that my local ubuntu 14.04 is short of some necessay configurations ? Or the unity screen can’t be opened originally ?

Is it also concerned with a new session ? I don’t kown how to create a new one.

You should be able to log in via “ssh -Y”. What is the error…does it not find the Jetson? Or does it reach the Jetson, and the Jetson rejects the connection? Part of the goal of this is to offload some of the work on to the PC, yet keep the account being configured as “ubuntu” on the Jetson.

At your local terminal, what do you get from (locale should reflect this):

echo $LANG

It is possible there is some missing component. The failure after testing for a string that should not be NULL could cause this, and because you have some missing locale this could be from a language support file.

Is your PC and everything involved a default en_US locale? I could see the possibility of non-en_US as running into a glitch.

Also, what is the result of:

df -H -T /

Is there any error in:

sha1sum -c /etc/nv_tegra_release

Ｈｉ，linuxdev.

I have already logged in via “ssh -Y” successfully.

The account is also configured as “ubuntu” on the Jetson. It can be learned from the terminal command lines.

ubuntu@tegra-ubuntu:~$ unity-control-center screen

At my local terminal,

echo $LANG

I got

en_US.UTF-8

At the terminal in local host connected with the Tx1 by “ssh -Y”

ubuntu@tegra-ubuntu:~$ echo $LANG
en_US.UTF-8
ubuntu@tegra-ubuntu:~$ df -H -T /
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/mmcblk0p1 ext4   15G  6.0G  8.0G  43% /
ubuntu@tegra-ubuntu:~$ sha1sum -c /etc/nv_tegra_release 
/usr/lib/xorg/modules/drivers/nvidia_drv.so: OK
/usr/lib/xorg/modules/extensions/libglx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvjpeg.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnet.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtestresults.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvomx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcamerautils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libtegrav4l2.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvparser.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnetstorehdfx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_utils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvddk_vic.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvll.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvapputil.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcolorutil.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvfnetstoredefog.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_video.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvddk_2d_v2.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcameratools.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm_gpu.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcamlog.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus_socketserver.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libglx.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvos.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_contentpipe.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libscf.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtnr.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvavp.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnveglstream_camconsumer.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnveglstreamproducer.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite_image.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmedia.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvosd.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libargus_socketclient.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_parser.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmm_utils.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvexif.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvtvmr.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvomxilclient.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvcam_imageencoder.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvdc.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvwinsys.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvodm_imager.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm_graphics.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvrm.so: OK
/usr/lib/aarch64-linux-gnu/tegra/libnvmmlite.so: OK
/usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l2_nvvidconv.so: OK
/usr/lib/aarch64-linux-gnu/libv4l/plugins/libv4l2_nvvideocodec.so: OK

So it looks like basics are all in place and it should be possible to do this without an app crash.

FYI, I am using R28.1 release. I have run “sudo apt update” and “sudo apt-get upgrade”, followed by fixing any case of a broken libglx.so instance (this would show up under the “sha1sum -c /etc/nv_tegra_release” comamnd).

I removed my monitor and ran “ssh -Y ubuntu@<my_jetson_address>”. I ran this as user ubuntu on command line:

unity-control-center screen

A GUI shows up on my host, and this GUI represents the previous settings…if I have edited screen lock settings before, then the GUI I see now correctly uses those settings. These are presumably the settings you are in need of changing.

On a TX2 (this is a TX1 forum) I get the same error (“Segmentation fault” and crash) you got if I have no monitor attached. Can I verify this is a TX1? I assume it probably is a TX1, and that the problem is some other difference between packages you have and packages I have.

Side Note:
The interesting thing on the TX2 is that the unity-control-center-dbgsym package cannot be installed (required for running in a debugger to see the exact cause of the seg fault)…not even by forcing. For whatever reason this is not allowed because it thinks the package which is already in place is the wrong package…but the package it requests is the package which is in place. Perhaps a stray character exists (such as a space) in some part of the dpkg file such that the package displays a different name than what other packages see it as.

Just FYI, if a package update breaks libglx.so, it will appear something like this in “sha1sum -c /etc/nv_tegra_release”:

/usr/lib/xorg/modules/extensions/libglx.so: FAILED

If this happens, you have a backup at:

/usr/lib/aarch64-linux-gnu/tegra/libglx.so

The way I fix libglx.so if it breaks is:

sudo -s
cd /usr/lib/xorg/modules/extensions/
rm -f libglx.so
ln -sf /usr/lib/aarch64-linux-gnu/tegra/libglx.so .
exit
# Then reboot...

I give this information because I want to make sure your packages are up to date for the packages we might have in common. Run the package updates for your TX1:

sudo apt update
sudo apt-get upgrade
# Verify files are correct...
sha1sum -c /etc/nv_tegra_release

With all files in place, and with all files updated, does your TX1 still fail “unity-control-center screen” after “ssh -Y” to the Jetson?

EDIT: strace seems to show this screen modifies through “/run/user/1000/dconf/”, but this is a temp file system without a real file. On the other hand, there is an app called “dconf-editor”. I’m thinking one of the values this editor can reach might be the same as using that GUI, though I don’t know which it would be.

YET ANOTHER EDIT: This might be it…dconf-editor is something you should explore. This app has a “search” function, and although lots of things have “lock” in their name (such as “clock”), I see this attribute which is a boolean toggle:

disable-lock-screen
disable-...lots of things..

…these are under desktop->applications->lockdown. With my auto idle set to one hour, I see parameter desktop->applications->session:idle-delay set to 3600…in seconds this is one hour. Try “0”.

Hi ,linuxdev

I’m sorry for my late answer.

Now ,I’m running into a terrible problem.

After I start up the app without ubuntu-desktp just like the way I described at the start of this topic , the app display on the screen is terrible.

The app is based openGL(glut glew gl) and cuda.

The phenomenon is that the display is splited by lines when something cross before the camera back and forth. But it displays all well after the ubuntu desktop starts up and I mannully start it. when I just can’t describe it correctly or by professional term.

And I have worked it for a week. I also find that the phenomenon comes out again after I remove unity with apt-get remove even if I mannully start up it on ubuntu-desktop with terminal.

I also install xfce4 instead of ubuntu-desktop.It’s also the same.

I have tried

sha1sum -c /etc/nv_tegra_release

all works well

/usr/lib/xorg/modules/extensions/libglx.so: OK

/usr/lib/aarch64-linux-gnu/tegra/libglx.so: OK

but the error is always on.

Maybe I have to drop the way and recover all.

Can you install and run dconf-editor? This is from the “YET ANOTHER EDIT:” in my last post. This may offer an alternative way to get to settings instead of “unity-control-center screen”.

Some things to consider if comparing local display to remote display over “ssh -Y”. Local display uses the GPU and CUDA and OpenGL of the local system. If you log in to the Jetson remotely, and do not use the “-Y”, but do set DISPLAY such that running an X application makes it pop up on the Jetson, the Jetson’s hardware and software will be the only thing in use (not the remote PC’s). If instead you use “ssh -Y”, and the application pops up on your PC work station instead of the Jetson, then all OpenGL and CUDA software and hardware is from your desktop PC and bypasses the Jetson. Should the Jetson support something not supported on the PC, then the application will either fail or behave badly due to the mismatch.

So it needs to be clear when giving information about app working/failing and good/bad quality how you are logged in, and where you are displaying to. I’m not positive from the description.

The “chicken and the egg” dilemma we are running in to which is related to this is that I don’t know how to disable the screen lock and power saving features which are tied to the GUI login of that user without actually logging in as that user in that GUI…and you may not have a method of login to that GUI (despite having a login to that account). It is unclear where the files are for a case of file editing, and the fatrace command does not work on a Jetson to discover this.

The alternatives I know of are basically to temporarily set up a monitor on your Jetson, and if you can’t log in locally at that monitor, to log in remotely and display on that monitor. Your situation seems to mean this isn’t possible.

The next alternative is to run a GUI config tool on the Jetson while doing remote display to the PC. This would run configuration files for the ubuntu account on the Jetson, so a GUI which is remotely displayed to PC should do the trick. It seems you are having trouble with “unity-control-center screen”, but perhaps “dconf-editor” can do this (see the end of my prior post).

Note that regardless of which desktop you choose you will have power and screen saver settings associated with the graphical display…it’s just how you edit those settings which changes. Switching from unity to something different may give you a better choice on how to configure, but I wouldn’t bet on the issue being fixed by going through that effort.

Can you tell if the dconf-editor might do the job? And on the bad display quality, can you give more information on how you were logged in, whether DISPLAY environment variable was set, and what the application is?

I’m sorry for my poor English. For some time , I find that I understand the sentence not correctly.

I can log in Tx1 directly and use gnome and unity tools to make screen unblank. It’s ok.

System Settings → Brightness&lock can solve it properly.

Then I can use “Startup Applications” this tools to start up our app. All works well.

But for a embedded system, it is sometimes lightly and small.

So I was asked to shrink the system startup time.

I found that startup app directly from rc.local with a shell script is faster than “Startup Applications” (about 5-6 seconds).

So I change runlevel to 3 (default 5) and start it with rc.local (I describe it at the start of this topic). Then the system starts up directly into camera-based app even without a flash of ubuntu desktop. That seems good.

However, many problems popped up after. This topic just the one.

In my case, I no longer log in ubuntu. I just access the system with usb serial (ttyS0) or ssh (remote login) from my host by terminal.

Now I change back to ubuntu-desktop. And install dconf-editor. But I can’t find

desktop->applications->lockdown

desktop->applications->session:idle-delay

In my environment, I got the tree of dconf-editor

desktop--gnome--...
       --ibus--...
       --unity--...

I only can find the words “lock-delay” “idle-activation-enable” in org->gnome->desktop->screensaver.

Is there something wrong with my comprehension.

I feel that these tools have no effect without gnome and unity. That’s my case.

My some incorrect description may led you a wrong direction, sorry.

Yes, a full desktop supporting multiple applications does take longer. What must run in this display? Does it still need to be able to run other applications as well? Is this to be something which is dedicated to display of a single application, and the user should not be able to do general work on this video display? What kind of interactive features must this display support?

Is there another display which is fully interactive with a desktop? Or can you use just a single display and do all other work over ssh or serial console?

At present, there is only one application based on opengl cuda opencv. It just shows camera_captured video on window. It doesn’t need keyboard and mouse. The only way to interact is by serial console (ttyTHS) or gpio sometimes.

There has been a lot of interest in the past at setting up the X server to spawn a single application instead of the window manager. I don’t have time right now to do all needed to see what the exact steps are and test, but here’s the gist of what normally goes on…it may offer clues.

As boot proceeds several terminal programs (getty) are associated with key bindings on the F1 through F6 keys (or customized). When graphical run level is reached, one of the getty instances is replaced by X running the login manager. You would have issues trying to stop consoles from running prior to reaching a stage where X’s login manager runs, but how X starts may not be too bad.

X11’s server can be run by anyone, and only supports a single application. The “startx” script is a very good place to examine this ability. When X is run as a service it runs the login manager, e.g., lightdm. As login is authenticated the X server respawns under that new user’s ID, and runs a single application: The window manager. It is the window manager that adds the ability to deal with multiple programs and desktop features.

There is no reason startx could not be modified to start an X application other than the window manager. If you currently have one X display it would be given the ID of “:0”. If you wanted to start a second GUI display on a different terminal just using “startx” does the job, and the second terminal becoming a GUI would be given ID “:1”. Under startx the identity of the program run takes on the ID of the user who ran startx. This is what the “export DISPLAY=:0” would be doing…associating a particular running X with your console.

You may want to experiment with an edited version of startx which does not spawn a window manager, and instead spawns a hello world type program (or your program) with no window manager. Once you do this you should be able to create something in the init or systemd scripts which turns one of those getty consoles into the custom startup running just your application. A very large part of the time spent getting to graphical mode is to go through all of the login steps and initializing of services only the window manager needs. Startup time for a pure single-program X argument (and your program or a window manager are simply arguments on a command line to X somewhere) should be much faster. It won’t get you to the startup point any faster, but once you reach that point it will likely help a lot.

Yes , what i am I doing is a little similar with your suggestions.

I just make a rootfs with ubuntu-base , and install a minimal lxde with below parameters.

--no-install-recommends xorg lxde lxde-common xserver-xorg-legacy

but there is no display on the screen.

In this way, it doesn’t have any display manager.

When I enter “sudo startx” in command line in my host pc connected with tx1 by usb serial, it has display on the screen ( some error also noted by a dialog before the desktop display ｏｎ the screen). But just inputing “startx” is not effect.

I think there is someting wrong with the permissions of my created user.

After reading your suggestions, I feel it is concerned with getty which is totally new to me.

LXDE is a window manager…it’s just lighter weight than most. You could go without this. Login manager is of course a separate piece of software, but is usually packaged with the window manager.