Hello @VMB,
The Torizon OS team has investigated this issue and the reason this only happens on the Verdin iMX8MP (and Verdin iMX8MM actually), is because on those SOMs the DRM stack is initialized very early, during the initramfs stage.
This means for any custom EDID binary to be loaded it must be available in the initramfs.
Therefore, the way to allow the custom edid firmware to be loaded would be to add it to initramfs:
This can be done with a custom Torizon OS build, using Yocto.
The following .bbapend file will include the EDID binary into the initramfs.
You also probably want the binary in the actual root filesystem as well. This is because if the display turns on after the system has already booted it will look for the EDID binary in the root filesystem not the initramfs.
# meta-toradex-torizon/recipes-core/initramfs-framework/initramfs-framework_1.0.bbappend
SRC_URI += "<edid firmware>.bin"
PACKAGES += "initramfs-module-edid"
SUMMARY:initramfs-module-edid = "initramfs EDID"
RDEPENDS:initramfs-module-edid = "${PN}-base"
FILES:initramfs-module-edid = "\
/usr/lib/firmware/ed-edid.bin \
"
do_install:append() {
install -d ${D}/${libdir}/firmware
install -m 0664 ${WORKDIR}/<edid firmware>.bin ${D}/${libdir}/firmware/<edid firmware>.bin
}
An alternative would be to manually load the firmware using DRM’s userspace interface.
sudo bash -c "cat <edid fw>.bin > /sys/kernel/debug/dri/0/HDMI-A-1/edid_override"
Doing this will require both the display and application/container(s) to be restarted for the new resolution to take effect.
This solution could be paired with a custom service on Torizon OS that runs before the Docker engine.
Would one of these solutions be suitable for your project?
Best Regards,
Bruno