Comment 7 for bug 1933758

Revision history for this message
Dave Jones (waveform) wrote :

Ubuntu switched to using the "full" KMS graphics stack in Hirsute (21.04). However, this means that the traditional means of forcing an HDMI mode (hdmi_group, and hdmi_mode in config.txt) no longer work.

There's a couple of ways forward here, but first I should point out that I don't think this is a bug: your display isn't accurately communicating with either the graphics firmware, or the linux kernel: you were already having to force a video mode (and some timings) via config.txt settings because your display (or, more likely, your HDMI-VGA adapter) is probably advertising that it supports 1080p when it doesn't (or the adapter may support 1080p, but the attached monitor doesn't, yet the adapter still advertises that resolution in EDID anyway).

As the graphics stack has changed with 21.04, the method of forcing display settings on it (at a lower level than the Gnome GUI) has also changed. I understand that's frustrating, but that is unfortunately the price of opening up the graphics stack.

With that said, here's a couple of ways you could tackle this:

Switch back to Fake KMS
=======================

The first is to switch back to the legacy "fake" KMS (aka fkms) implementation. You can edit config.txt and change the following line:

  dtoverlay=vc4-kms-v3d

To:

  dtoverlay=vc4-fkms-v3d

This will use the legacy "fake" KMS implementation which should enable the hdmi_group, hdmi_mode, and other hdmi_* settings in config.txt to operate as they did before. However, be aware there will be other side effects from using fkms, e.g. choppy sound output and "tearing" during video playback, and that this won't be a supported configuration in future.

Stick with Full KMS
===================

Alternatively, you can stick with the "full" KMS implementation and try to find another mechanism of telling the kernel how to drive your monitor. The following bug may be useful in finding some solutions:

https://github.com/raspberrypi/linux/issues/4516

In particular I'd suggest trying 6by9's comments (https://github.com/raspberrypi/linux/issues/4516#issuecomment-895106299):

> Ideally your display would have a valid EDID that will be read and fully processed by
> vc4-kms-v3d. Sometimes it needs disable_fw_kms_setup=1 in config.txt to stop the firmware
> trying to influence it.
>
> If it doesn't have any EDID, then you could create one, put it in /lib/firmware, and add
> drm.edid_filename=foo.edid to /boot/firmware/cmdline.txt [*] to tell DRM to load that
> instead of trying to read it from the display.

[*] edited to point to Ubuntu's mount-point for the boot partition