pirogue-screen-st7789-240x240: prepare for hardware+software auto-detection

[CyrilBrulebois]

Debian packages shipping systemd units tend to have the unit enabled by default (see dh_installsystemd).

Depending on what we decide regarding pirogue-base vs. pirogue-base-pc, we might scrap the latter, focus on the former, and have pirogue-base pull this package on PC architectures as well (amd64 and possibly i386).

It seems to me this package's postinst should determine which hardware+software platform it's running on, and do something along those lines:

• If on Debian/arm64 on a supported Pi (3 or 4, as determined by looking at the DT), deploy SPI DTBO, raspi-firmware config (and apply it), and enable the systemd unit.
• If on Raspberry OS/arm64 on a supported Pi (3 or 4, as determined by looking at the DT), deploy the required lines in config.txt, and enable the systemd unit.
• In all other cases, disable the systemd unit.

I'm happy to write a PoC for this.

I'm not sure whether we need to clean everything up in the postrm script. It would be cleaner, but does it change anything practically?

[CyrilBrulebois]

In the Debian case, the DTBO could be named <package>.dtbo so that it's clear where it comes from. We would probably ship it somewhere below /usr and have it copied and enabled in config.txt via postinst.

For this package, we could stick to pirogue-screen.dtbo since the virtual package is going to prevent other pirogue-screen-* from being co-installed.

[CyrilBrulebois]

Since /etc/os-release is unchanged in Raspberry OS (no comment…), detecting raspi-firmware as an installed package is likely to be a very reliable way to tell Debian from Raspberry OS.

[CyrilBrulebois]

In the Debian case, it seems there's no way to ensure /dev/spidev* entries are created by the kernel because compatible = "spidev" is wrong and rejected (according to Linux upstream). The Raspberry OS kernel has a revert of that rejection code, so is unaffected when a SPI overlay is enabled.

Provided the systemd unit is started as root, we might want to have some ExecStartPre that would do the required echo dance to create what python3-spidev expects for the SPI-based device:

echo spidev > /sys/bus/spi/devices/spi0.0/driver_override
echo spi0.0 > /sys/bus/spi/drivers/spidev/bind

Or just have the “main” screen program deal with it when starting up.

[U039b]

• [ ] ship and install the DTBO ffi on Debian
• [ ] enable dtoverlay=spi0 in /boot/firmware/config.txt
• [ ] ensure /dev/spidev* entries
• [ ] switch to libgpiod and spidev, get rid of Adafruit's libs
• [ ] lower the screen refresh rate to the acceptable minimum
• [ ] test on Debian 12
• [ ] test on RaspberryPi OS

[CyrilBrulebois]

The detection is now implemented in a new pirogue-hardware-detection package that creates flag files depending on the detected hardware and software situation:

• /var/lib/pirogue/hardware/is_raspberrypi_hw when running on a supported Pi (3 or 4);
• /var/lib/pirogue/hardware/is_raspberrypi_os on arm64 when raspi-firmware isn't spotted;
• /var/lib/pirogue/hardware/is_debian_os assumed otherwise.

[CyrilBrulebois]

We still need to investigate whether we can write a DTS for the DTBO that doesn't require modifying the base DTS. Since that's the first time I touched SPI things, I decided to play safe initially and mimic what's done on the vendor side, but it's probably OK to just reference the whole 7-11 pins without splitting them into two different groups; the CS (chip select) distinction is probably not relevant either. But we should test that before merging either version of the DTS/DTBO.

[CyrilBrulebois]

Confirmed OK by @U039b, at least on Debian 12. If there are issues on Raspberry OS, please file a separate issue with details.