Display resolution not properly identifying in Ubuntu 21.04

Some bot incorrectly changed this to a docs bug. Changing back to generic "Ubuntu".

Ok.Thanks

Try appending config with your group, mode and cvt values, plus:
hdmi_force_hotplug=1

I was having a similar issue connecting my RPI3 to an older Dell monitor through a HDMI to VGA adapter and this did the trick for me.

Yup I tried that but no hope,I tried all the possible combinations.For other distro's this usually works fine.Even with the older version of Ubuntu this worked, but after that update to Ubuntu 21.04 this isn't working anymore.
I tried changing hdmi_mode=39/86/87,hdmi_group=2 and hdmi_cvt=1366 768 60 3 0 0 1 as well as 1360 768 60 3 0 0 1.

This is what listed in my monitors.xml file:

<monitors version="2">
  <configuration>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <scale>1</scale>
      <primary>yes</primary>
      <monitor>
        <monitorspec>
          <connector>HDMI-1</connector>
          <vendor>AGO</vendor>
          <product>0x0001</product>
          <serial>0x434e3031</serial>
        </monitorspec>
        <mode>
          <width>1360</width>
          <height>768</height>
          <rate>60.015655517578125</rate>
        </mode>
      </monitor>
    </logicalmonitor>
  </configuration>
</monitors>

I think Ubuntu is identifying wrong settings for my monitors,when I start the pi it sets the resolution to 1920x1080(16:9),which is not supported by my monitors,The maximum resolution is 1366x768(16:9),Is there any way to change that?

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

Marking invalid as the cause was the change in KMS overlay, but the original situation already required manual configuration (in other words, the hardware was already failing to negotiate the resolution correctly, very likely due to an HDMI-VGA adapter)