One of the most useful things I did with RetroBridge was rebuild it on a completely fresh microSD card.

The original development appliance had evolved over time, so I wanted to know which assumptions were real project requirements and which were simply artifacts of the original system.

That clean build exposed an important difference in Debian 13 Trixie.

On the earlier setup, the RetroBridge frontend could be launched into the desktop using the normal LightDM-era X11 assumptions and the user's .Xauthority file.

On the clean Trixie build with the MHS35-style touchscreen driver, that was no longer true.

The display driver created a dedicated service:

spi-display.service

That service starts the graphical environment itself:

startx → Xorg :0 → LXDE

and the X session is owned by root rather than the normal RetroBridge user.

That meant my old launch method failed because the expected user-owned X authorization file was no longer the right authorization path.

I first proved the frontend itself still worked by locating the temporary X authorization file created for the active Xorg process and launching RetroBridge manually into display :0.

Once that worked, I replaced the manual workaround with a proper startup wrapper.

The final wrapper:

• runs inside the already active LXDE session
• grants the normal RetroBridge user access to the X display
• launches the Python frontend as that normal user
• respects the RetroBridge maintenance-mode file

The validated startup chain became:

Power on → SPI framebuffer → spi-display.service → Xorg :0 → LXDE → RetroBridge

After adding that wrapper to the LXDE autostart path, the fresh Trixie card booted directly into the RetroBridge Time Machine interface.

This was a good example of why rebuilding from scratch matters. The RetroBridge code itself was fine — the surrounding graphical-session model had changed underneath it.