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:
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.
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…
As you guessed, the supervisor does not support setting conditional configs or disabling overwriting the config.txt file
My colleague suggested that a workaround could be that you have a service that detects the output and change the BALENA_HOST_CONFIG_enable_tvout through the API.
I thought about something like this, but as far as I can tell it would be a one-way thing - detect no HDMI on boot, set enable_tvout=1, then it’s done and could never go back. If HDMI came back on another boot it wouldn’t be detected, because when enable_tvout=1 there’s no hotplug events on HDMI and probing with eg. tvservice -s or tvservice -ldoesn’t see anything attached to HDMI. This is quite unlike the previous Pi generations where it was possible to switch between composite and HDMI at runtime using the tvservice command. I do wonder if a future update to the Pi firmware might repair this, though it appears composite output support is a much lower priority on the Pi 4, and enabling it has to change the system clocks. I wonder if that causes a problem for the HDMI clock that forces them to disable the HDMI port…
Hi @neilnz, that makes sense. Unfortunately that’s the best option we have at this time, but we’ve taken your feedback and created a GitHub issue to track other users’ need for conditional configurations, which you can keep an eye on here: https://github.com/balena-io/balena-supervisor/issues/1573
Yep sounds fair. As a stopgap would you consider a config setting that locks config.txt from being updated by the supervisor? Manually managing this on our devices is going to be difficult because we won’t know which ones are meant to be which setting ahead of time.
Well, the biggest issue in that scenario that I can see, is that we would be reverting functionality that is fully intended to exist. The Supervisor is designed from the onset to be able to perform those changes, so, I am not sure that adding functionality to actively prevent it form happening is is the right path forward. The second piece of the puzzle here is that the Supervisor exists across all device types, but only Raspberry Pi’s include the config.txt, so there is added complexity there as well. I think the hangup is really the behavior of the Pi4…could the Pi3 suffice for your project since it seems to be able to do the automatic switching in a superior way?
The pi4 was picked because of dual HDMI (another requirement…) so while the project runs fine on the pi3, the pi4 was purchased in bulk and it’s what we have.
I recognise the config mechanism exists across device types. In the supervisor, the config.txt handling is its own class, and there’s pi-isms in there already. I understand the issues with the supervisor not being allowed to write config, as it in some instances is ensuring a minimum set, and OS upgrades sometimes need to twiddle the config too. I’m stuck in a rather difficult place here as I need to get this working, and I’d rather not have to run a forked supervisor to do it, though I do understand the openbalena route is increasingly there to cater to us that are off the beaten path.
The latest version of the supervisor actually crashes the entire supervisor when it meets a conditional config section in the existing config.txt (can’t handle the “[” leading a line) which is a bit unfortunate.
Another issue is that colon isn’t allowed in a device config variable by Balena API, making it impossible to set any config for the second HDMI port (eg. hdmi_mode:1=31) so it’s no longer possible to reach all the possible pi4 config options already. That one seems easy to fix though.
For now I’m forging on with running a separate Balena application for composite out devices and keeping the fleet config separate as a solution, but I’d like to reunify the fleet at some point when it’s possible to.
Hey @neilnz, I updated the existing github issue regarding conditional config fields, and created a new one for colons in device config variables here: