Feature Request: Some means to configure DRM/KMS displays or perhaps all add-on dtoverlays.

[Gadgetoid]

It seems up until Bookworm, blind luck and a lesser reliance on accelerated graphics have kept a misconfigured DPI display from booting the system to a black-screen-of-death (yes, even over HDMI).

As of Bookworm, at least at time of writing, there's no regression if a DRM/KMS display fails to probe due to misconfiguration. The most common form of this - for DPI displays anyway - is leaving some interface or another enabled- such as i2c or SPI.

Since display configuration can be quite fragile, yet also something a beginner might expect to be straight forward, I'd like to make a petition to include a "Displays" section in raspi-config that would:

1. List supported displays which have a corresponding DRM/KMS dtoverlay
2. Allow the user to choose one to enable
3. Disable any conflicting interfaces (it may not be trivial to figure out what this means and how it might be accomplished)

Since doing this for displays would effectively lay the groundwork for all dtoverlay-based drivers, perhaps it's not unreasonable for this to be a "Device Tree" or "Add-on Config" section that lists all available dtoverlays by category and allows the user to enable/disable them. A little bring-up legwork to catalog what dtoverlays use what pins (I'm not sure this could be easily scripted, but a parse of the .dts files would be a good starting point, as would the Pinout.xyz "database") would be necessary, but I don't think it's too onerous.

A big potential roadblock for this would be dtoverlays that effectively require extra args- such as gpio-key, but I'd be tempted to omit those, and a vast majority of the more advanced overlays in favour of a concise list of supported products. Obviously I have some bias here!

The goal here is to take a common user config task and remove the need to monkey about in /boot/config.txt.

At the very least some CLI-only interface for enabling/disabling a supported dtoverlay would be nice. I could then, perhaps, do all of the above as a separate Python utility. I think there's a good case to be made for making it part of raspi-config, but there would be some ongoing maintenance burden and churn to support new overlays.

[XECDesign]

This feels like a bit too much for raspi-config to be doing. There are some dt overlay-related scripts here, so maybe there could be a separate dtconfig tool that lives there?

@pelwell does the firmware do any checks to make sure overlays are compatible when loading them?

[pelwell]

There is some basic checking at the architecture level - is it Pi 4-only, essentially, or loading Pi 4-specific versions of common overlays - but that's all

[Gadgetoid]

I think graceful failure was never an especially good fallback since it's difficult for an average user to understand and diagnose what they did wrong. Getting the config right in the first place would be really helpful.

@XECDesign I think I have to agree, even talking through the scope of the problem was complicated, actually handling it will probably be more so.

Right now for Pimoroni products I try to gloss over as much config as possible with our one-line-installers, but I don't catch all cases and such a solution obviously only applies to Pimoroni products. I like to try and keep things as straight-forward as possible for beginners, but I probably shouldn't contrive yet another Not-Invented-Here solution.

[XECDesign]

Yeah, my thinking is that the tool would need to parse config.txt's filters, figure out what overlays would be applied, decompile them, figure out what pins are being used by each overlay and detect clashes. Seems simple, but probably isn't.

Closing this, since I don't think this will land in raspi-config. But if you do end up with something you use at pimoroni, maybe it could be added to that utils repo and the raspi-utils apt package. Then raspi-config could have an option to call that tool.