Raspberry Pi and no video signal
Over the past week I've been setting up a second home office. This required another monitor, so I decided to re-use the one I had been using for my home dashboard. However, as I have grown very used to the information displayed by jarvis, I had to find another monitor for that purpose.
Like most geeks I have piles of unused computer parts and accessories (my SO never misses a chance to make fun of my ever-growing pile of cables), and among it I found a 20" monitor - an ancient Dell 2007WFP.
My dashboard runs on a Raspberry Pi 3B. I've used this monitor for the same purpose in the past, but this time I encountered a strange display issue. I connected the monitor using a HDMI-DVI cable and then booted the Raspberry Pi. The monitor turned on and the kernel boot log was printed, as expected.
However, immediately after booting completed, the monitor went to sleep. After
fiddling with a couple of
xset commands to disable blanking, I still couldn't
make the monitor turn on after the X server was started.
Searching the web for "raspberry pi no hdmi signal" yielded many similar
problems, but most of them revolved around having no video signal at all. In my
case I had a video signal until the kernel completed its boot process. The
Raspberry Pi has countless options for configuring video output, so I tried a
bunch of those, including
config_hdmi_boost=6, but none of them helped.
Then I discovered that Raspbian now has two different video drivers,
vc4-fkms-v3d - a legacy driver, and its replacement:
running standard Debian on my Raspberry Pi, but I still have to use the same
non-free firmware as the Raspberry Pi OS. I couldn't find too much details on the
difference between these two drivers, but
fkms stands for "fake KMS".
vc4-fkms-v3d manages more of the video output pipeline internally,
while the new
vc4-kms-v3d driver delegates this work to the kernel.
From what I could gather,
vc4-kms-v3d is the default since Bullseye, so I
tried reverting to the legacy driver by setting
/boot/firmware/config.txt (this is the path on standard Debian, on Raspberry
Pi OS it's located in
/boot). However, changing the driver had no effect. The
monitor still went to sleep immediately after booting.
While searching for more solutions, I found a suggestion to boot with
drm.debug=0x14, by adding it to
/boot/firmware/cmdline.txt. This causes the
kernel to print debug information related to drm - the subsystem responsible for
interfacing with the GPU.
Once I did that, I found the following message in the boot log:
$ dmesg -T | grep drm | grep disconnected [Sat Feb 5 19:13:35 2022] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:32:HDMI-A-1] status updated from unknown to disconnected
So the kernel believes that the monitor is disconnected? Let's double-check.
$ cat /sys/class/drm/card0-HDMI-A-1/status disconnected
Yes, it was indeed showing up as disconnected. But isn't
supposed work around exactly this problem? From the config.txt documentation:
hdmi_force_hotplugto 1 pretends that the HDMI hotplug signal is asserted, so it appears that a HDMI display is attached. In other words, HDMI output mode will be used, even if no HDMI monitor is detected.
This option changed nothing when using either
vc4-fkms-v3d or the
vc4-kms-v3d driver. However, if the new driver delegates more of its
responsibility to the kernel, the kernel itself must surely have a way of
forcing video output?
Some further analysis led me to the excellent Arch wiki:
video=<conn>:<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd] ... D: digital output forced to on (e.g. DVI-I connector)
/boot/firmware/cmdline.txt and rebooting did the
trick! No more loss of video signal.
video=HDMI-A-1:D should be added to
/etc/default/raspi-extra-cmdline instead so that the configuration is
update-initramfs runs, e.g. when the kernel is upgraded.
I have no idea why this workaround is needed though, I suppose it could be a bug in EDID information sent by the monitor, a bug in the kernel or some incompatibility due to using a HDMI-to-DVI adapter.