Controlling The Boot Screen on Linux Embedded App

controlling the boot screen on Linux embedded app

The solution usually goes along the lines of:

1. Optionally, put a static image on the screen from the boot loader code (e.g. uboot, syslinux, redboot).

2. Using the Linux kernel command line "quiet" directive to suppress normal kernel load output (and speed up boot time while you're at it).

3. As one of the very first programs started from init, draw your splash animation throughout the boot init sequence until it is finished.

For example, Android phones usually put some static image in the boot loader and then run the surfaceflinger program from the startup init scripts to draw the animated Android logo until the boot is finished.

How two APP in embedded Linux communicate with each other normally

There are many options, though using a pipe or socket is common. What you're looking for is Interprocess Communication.

QT has an interprocess communication abstraction that you can probably use to do this:
https://doc.qt.io/qt-5/ipc.html

Embedded linux application start script works better from command line

Is that the only shell script you are using? or do you have a systemd service file that executes that single shell script?

Using sleep is ineffective here. You should separate them into separate shell scripts and then use systemd to ensure that the shell scripts are run in order.

For example, we want to mount the directory first, because if this fails then nothing following will be successful. So we create a systemd mount service:

# home-root-linux.mount
[Unit] 
Description=Mount /home/root/linux
Before=gpiodev.service

[Mount]
What=/dev/mmcblk0p5 
Where=/home/root/linux 
Options=defaults

[Install] 
WantedBy=multi-user.target

Then we can create another systemd service which depends on the mount above before executing the three parts of the shell script which were previously separated by sleep to ensure that they were run in order.

# gpiodev.service
[Unit]
Description=Handle gpiodev kernel module
After=home-root-linux.mount
Before=mysqlsafe.service

[Service]
Type=oneshot
ExecStartPre=/home/root/linux/mem_driver/memdev_load
ExecStart=/sbin/insmod gpiodev.ko; /bin/mknod /dev/gpiodev c 249 0
WorkingDirectory=/home/root/linux/gpio_driver
RemainAfterExit=yes
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Second part of the systemd service (following the sleep). We have a separate shellscript which is placed in /sbin/ in this example as it contains a while loop so it would be best to separate this:

# mysqlsafe.service
[Unit]
Description=MySQL safe
After=gpiodev.service
Before=npmoutput.service

[Service]
Type=oneshot
ExecStart=/sbin/mysqlsafe.sh
WorkingDirectory=/home/root/src/control
RemainAfterExit=yes
StandardOutput=journal

[Install]
WantedBy=multi-user.target

Second part of the shell script which is executed in the systemd service above (separated to a separate file due to the complexity):

# /sbin/mysqlsafe.sh
#!/bin/sh
mysqld_safe &
up=0
while [ $up -ne 2 ] 
do
    up=$(pgrep mysql | wc -l);
    echo $up
done

Third part of the systemd service (the third section of the original shell script which was separated by sleep):

# mpmoutput.service
[Unit]
Description=npm and output to log
After=mysqlsafe.service

[Service]
Type=oneshot
ExecStartPre=/usr/bin/npm &
ExecStart=/home/root/src/control > /home/root/linux/output.log
WorkingDirectory=/home/root/studio_web/myapp
RemainAfterExit=yes
StandardOutput=journal

[Install]
WantedBy=multi-user.target

The idea behind this approach is that systemd recognises the importance of each service and the reliance upon the following service i.e. if one service fails the following services in queue will not execute. You can then check this using systemctl and see logging in journalctl.

Just a quick copy, paste and edit. Could contain errors as it was not tested or checked.

More reading can be found here regarding systemd service files: https://www.freedesktop.org/software/systemd/man/systemd.service.html

QT application Autostart --- in linux

1) You can simply create a script to start your application and add it to /etc/init.d folder, for example: /etc/init.d/S30myapp, which includes:

#!/bin/sh
/etc/my_qt_app -qws &

Of course, do not forget to chmod +x them.

2-3) The most simple solution is to use Qt Windowing System (QWS). Check here for more technical details.

4) Taken from tags from superuser:

Desktop-environments: Software that provides a graphical user
interface, with elements like icons, windows, toolbars, as well as
additional features. Popular examples include Gnome and KDE.

A window manager takes care of the placement and appearance of windows
in a GUI-driven operating system. Sometimes, the term also refers to
plugins that extend this basic functionality.

I don't know your requirements, but usually only windows manger is used in embedded devices. But as I mentioned before, Qt has its own windows manager - QWS. Another widespread option is X Server.

5) In case you use QWS (or any other windows manager), you can start your initial application and maximize it to full screen, so it will be the only application visible. However, check this discussion for multiple concurrent applications using QWS.

Start QT Application on bootup on an Embedded Linux Device (Beaglebone Black)

Try the following

[Unit]
After=getty@.service or getty.target

[Install]
WantedBy=multi-user.target

Also consider removing the following from the service file

After=systemd-user-sessions.service
Alias=display-manager.service

Embedded Linux with Standalone application

In the nutshell - X System is extremely flexible.

When you system starts up, it does the following steps:

1. Loads and runs the Kernel (and related initrd, if any, but it's irrelevant)
2. Starts init (process 1)
3. Starts system services, networking, etc.
4. Starts X server
5. Starts Window Manager (the application responsible for resizing windows etc)
6. Starts your application.

What you need to do, is to first disable GUI login and session (easiest to disable X) - you'll be able to log in through the console terminal (You can always access it with Ctrl-Alt-F1)

Then, launch something along the lines of

X &
DISPLAY=:0 ./yourapp.exe

If your app can handle making itself fullscreen, that would be it.
Add this to your startup scripts and you're there.

---

More explanation

The purpose of the Window Manager.. is to manage windows. It's that simple :)

Basically, there are 3 components of your typical X session.

• X Server - the piece of software that provides an abstraction layer around the hardware (GPU drivers, Keyboard, Mouse, Touchscreen, etc). It has a concept of windows - areas where X Clients can draw into.
• X Clients - Everything else. Your software, if it draws something, is likely one. So is the web browser, etc. The connect to the X Server, and draw.
• Window Manager - A special type of an X Client, this piece of software provides the ability to control the windows on your screen. It often draws window decorations (minimize, maximize buttons), sometimes draws a taskbar, etc.

You are free to mix and match them entirely as you please. Simpler, minimalisting window managers, such as my ratpoison which I prefer for many prototype embedded systems only have the notion of fullscreen windows, and can switch between fullscreen apps (think Windows 8 Metro). Others draw window decorations, and allow overlapping and cascading windows.

Since developing a Window Manager is a simple and modular task, there are literally hundreds to chose from. You also can choose not to use one at all, at which point your windows have to self-manage (you'll not be able to move them around by default). Many applications respect the -geometry 1920x1080+0+0 parameter, telling them to open a window in 1920x1080 resolution at the 0,0 corner - effectively fullscreen.

---

Related Topics