Set up chromium kiosk autostart on a Linux panel

What you need

• The panel with its Linux image, booted once and reachable over SSH with an admin account, so you are never locked to the screen.
• The browser installed. Some images install it as chromium-browser, others as chromium; type the name in a terminal and see which one comes back.
• The dashboard URL, tested once in the browser on your laptop.
• The controller's I/O configuration tool, when the screen's brightness input is a PWM output driven by the controller. Without a PWM input, skip that layer; the other two still apply.

Bring the dashboard up as a kiosk

1. Test the flags from a terminal inside the desktop session:

   chromium-browser --kiosk --app=http://10.0.4.21:8080/dashboard
   

   The URL is this article's example; use the one your dashboard serves. --app opens the address as a bare app window with no tabs, no address bar and no buttons. --kiosk puts that window across the whole screen with no frame. With both flags set, the dashboard is the only thing on the glass.

2. Save the same command line as a user unit at ~/.config/systemd/user/chromium-kiosk.service, with the binary path your image installs:

   [Unit]
   Description=Kiosk dashboard
   
   [Service]
   ExecStart=/usr/bin/chromium-browser --kiosk --app=http://10.0.4.21:8080/dashboard
   Restart=on-failure
   RestartSec=5
   
   [Install]
   WantedBy=default.target
   

   The browser exits while no session is up yet, Restart=on-failure brings it back every 5 s, and the first launch after the display manager brings the session up is the one that holds. That retry is the ordering, because a user service manager has no display-manager target of its own to wait for.

3. Enable the unit as the kiosk user:

   loginctl enable-linger kiosk
   systemctl --user enable --now chromium-kiosk.service
   

   Lingering starts the user's service manager at boot, so no login is needed. If the image already logs that user in automatically, the session start brings the unit up with it and lingering is optional. If the image does not run user services cleanly, the session's autostart folder runs the same command line after login; on a Wayfire desktop the autostart entry goes in wayfire.ini. Where that entry lives changed with recent desktop releases, and fixing kiosk autostart after a desktop release update lists the places to check. The unit-file fields and the enable steps also appear step by step in a systemd autostart walkthrough.

4. Power cycle once and watch: a few failed launches, then the dashboard, full screen, with nothing else.

Hide the boot text

1. Find cmdline.txt on the boot partition. Current images keep the boot files under /boot/firmware/; older ones keep them at the partition root.

2. Delete one token from the single long line in that file: console=tty1. Keep everything else exactly as it is, and keep the original line in your notes so the edit reverses in one paste.

3. Reboot. From then on the kernel and the system start silently on the screen, because their messages have no console to print to.

The vendor logo or splash that some boards paint before the kernel is a separate layer with its own settings. Show only a splash screen on an embedded Linux kiosk boot covers that layer start to finish.

Keep the panel dark until the dashboard paints

1. In the controller's I/O configuration tool, set the default value of the output that drives the screen's brightness input to 0. The tool applies that default on every boot, so the panel stays dark from power-up and nothing that loads before the dashboard is ever painted.

2. From a terminal, write your working duty to that output once, 70% in the example below, and confirm the panel lights.

3. Make that write the dashboard's first action on load, so the duty comes up with the first paint.

One floor note: a dark panel reads as a dead panel to an operator walking past. Keep the dark window short and label the frame with what the screen does at power-up.

Example: a Node-RED dashboard on a 15.6-inch panel

The numbers below are this example's inputs. Measure your panel once and keep your own.

Power on at 0 s. The kernel runs silently and the panel is dark at 0% duty. The session comes up at 19 s, so the attempts at 2, 7, 12 and 17 s fail and the attempt at 22 s lands. The browser paints at 26 s, that is 22 s plus 4 s to first paint, and the dashboard writes 70% duty at 27 s. The operator sees 27 s of black glass and then the dashboard.

Without the PWM default, the same boot would have shown console text from 2 s to 19 s, 19 - 2 = 17 s of scrolling messages, and a desktop from 19 s to 26 s, 26 - 19 = 7 s of it. With the default at 0, nothing but black appears before first paint. Touch input lands in the app window; there is no frame to drag, no tab to close and no button that leaves.

Trim the dead time

The dark window is boot time plus the retry gap, and both shrink. systemd-analyze blame lists start-up jobs with their times; disable the services the panel does not use, a print service or a long network wait among them. In the example, a session up at 13 s instead of 19 s fails the attempts at 2, 7 and 12 s, lands the attempt at 17 s, paints at 21 s and lights the panel at 22 s, which is 5 s sooner than 27 s. RAM and storage speed move the 4 s paint time the most, because the browser's first paint is the heaviest single step on a small panel.

Check it worked

Pull the power, wait a moment, and power up cold, because that is what the floor does. Then check four things:

• The screen stays black from power-up: no text, no logo, no desktop at any point.
• The dashboard appears once and fills the panel edge to edge at its native 1920 x 1080 with no scrollbars. If it underfills or scrolls, diagnosing kiosk browser sizing in an HMI window walks the size checks.
• Touch works inside the dashboard and nowhere else: nothing closes the window and nothing switches away from it.
• A second cold power-up gives the same result.

When the panel should not be the dashboard

Kiosk mode fits one GUI, one station, touch as the only input. If the same panel is the machine's HMI, leave the HMI its screen and put the operator dashboard somewhere else. If the wall next to the machine needs a status board that plays on its own, shift targets, safety notices and shift summaries, a small Android signage unit does that offline: it plays images and video from a card or stick with no network and no subscription, and the player brings the show up full screen at power-on. That job lives in our offline player; the startup discipline on those units is Android signage app startup for a single-purpose display; and the choice between a live dashboard and a played board gets its own answer in live factory data display: signage or dashboard?.

Recommendation: Run the browser from a systemd user service with --kiosk and --app, delete console=tty1 from the kernel command line, and set the brightness output's default to 0 with the dashboard writing the working duty on load, when the panel serves one dashboard to operators whose only input is touch. Keep the desktop session and skip the kiosk setup when your own team needs other tools on the same panel, and leave the machine's HMI screen alone when the dashboard can live on a second screen.

Questions