enable_tvout (Pi 4B only)

[meeki007]

from https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

enable_tvout (Pi 4B only)
On the Raspberry Pi 4, composite output is disabled by default, due to the way the internal clocks are interrelated and allocated. Because composite video requires a very specific clock, setting that clock to the required speed on the Pi 4 means that other clocks connected to it are detrimentally affected, which slightly slows down the entire system. Since composite video is a less commonly used function, we decided to disable it by default to prevent this system slowdown.

To enable composite output, use the enable_tvout=1 option. As described above, this will detrimentally affect performance to a small degree.

On older Pi models, the composite behaviour remains the same.

Status: Ready

Reference: from https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

[MichaIng]

@meeki007
Many thanks for this. Yeah makes sense to have this in the config file by default to allow users configuring it for first boot already.

Do you have a composite cable there to run some tests?
There is this other setting (undocumented) hdmi_ignore_composite=1 that allowed in combination hdmi_ignore_hotplug=1 to completely disable the video pipeline which we use currently for headless mode to save most hardware and system load.
I am wondering if this setting is simply ignored on RPi4 while enable_tvout=1 is ignored on other RPi models or if both have the same effect (respecting defaults) on all models, so e.g. on RPi3 hdmi_ignore_hotplug=1 == enable_tvout=0 or if both handle SDTV on a different layer...

So finally currently the settings "look" doubled and I would simply switch both in every case when enabling/disabling SDTV. It doesn't harm and we aim to keen SDcards swapable between multiple RPi models.

[meeki007]

@MichaIng

Do you have a composite cable there to run some tests?

Cable I have but a Pi 3 on me ...no

This can wait a few weeks until i get back to Detroit to do proper testing

[MichaIng]

@meeki007
Btw. any non-RPi4 should behave the same.
Not that important as well. Is more that I am interested how these multiple settings work beside each other. In the end we anyway set both settings together.
I even found a composite cable here, but no fitting monitor 😄.

I think I will ask the RPi kernel devs about this. There are also some enhancements possible IMO. Currently headless more practically disables the framebuffer, but the related device tree component is still loaded, producing error messages on early boot.
On my machine I created a dtoverlay that disables the framebuffer component completely and by this getting rid of boot errors messages:

/dts-v1/;
/plugin/;

/ {
        compatible = "brcm,bcm2835";

        fragment@0 {
                target-path = "/soc/mailbox@7e00b840";
                __overlay__ {
                        status = "disabled";
                };
        };

        fragment@1 {
                target-path = "/soc/fb";
                __overlay__ {
                        status = "disabled";
                };
        };
};

The first part additionally disables the whole VHCI component, which removes the remaining error messages that are known on RPi when using 16M GPU memory share/using the cut-down start file (/boot/start_cd.elf). Also it prevents loading of all the camera related modules (which are loaded automatically for no reason since v4.19). Although I found blacklisting two of them has the same effect: https://github.com/MichaIng/DietPi/blob/dev/dietpi/func/dietpi-set_hardware#L141