We’re trying to deploy a product on the Pi 4 that needs to work with either HDMI or Composite output, depending on what’s connected at boot. It turns out on the pi4 this isn’t possible without using conditional config (see https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=257078 for details). On previous Pi models this auto-switching was the default behaviour.
In our image, we’ve modified (part of) config.txt to read like this:
enable_tvout=1 sdtv_mode=2 [EDID=*] enable_tvout=0
and this works fine - the pi will disable composite if an HDMI display is present at boot. Note if enable_tvout=1 then the pi4 ignores whatever is connected to HDMI, hence the need for this hack.
The problem is the supervisor code that manages config.txt doesn’t understand conditional sections and when it does the sync to config variables, it rewrites the file without the conditional config, and we lose HDMI support again.
I’ve had a look through the code in https://github.com/balena-io/balena-supervisor/blob/e5a1561bff19741534abd1f2d1b7ec59b1d29f44/src/config/backends/config-txt.ts to see if there’s any support for conditional blocks or even to totally disable the overwriting of config.txt, and come up short. The only possibility I can think of is to intentionally corrupt an array-syntax config variable to cause the whole thing to throw an exception.
Does anyone have any other ideas? I don’t see any pathway to stop the supervisor destroying the config without it gaining some new significant smarts… and all the alternatives to dynamically rewrite config vars from the application are going to be really ugly. In particular, the tvservice command can’t enable composite on the pi4 if it wasn’t enabled at boot, so that won’t work either…
Thanks for any help on offer…