vc4-kms-v3d driver not working with custom HDMI mode (group 2, mode 87)

[MakerMatrix]

Is this the right place for my bug report?
I think so - the vc4-kms-v3d driver is a kernel overlay AFAIK

Describe the bug
When I have a custom HDMI timing listed in my config.txt, with vc4-kms-v3d enabled, the console screen goes blank and stops outputting a video signal. This appears to occur at the point where the init process launches the service where the gpu driver is detected/enabled. When I put the default config.txt back and enable the full GL driver, video works (on a regular 1080p screen, which is not my display of interest).

To reproduce
Install a basic raspbian lite, fully update it, enable the full GL driver, then enter lines in config.txt like this:

# Force a specific HDMI mode (group2 mode87 will force the custom timing)
hdmi_pixel_freq_limit=300000000
hdmi_timings=2560 0 123 10 50 1600 0 12 4 4 0 0 0 50 0 222000000 5  # 222MHz is what the EDID reports <- this works
hdmi_group=2
hdmi_mode=87

Expected behaviour
Working console video (this config does not use X11) with the ultimate aim of getting SDL2 working with hardware acceleration and no X11.

Actual behaviour
The screen blanks, and my monitor reports there is no video signal present. The system finishes booting (I can ssh to it, shortly after) but there is no working video at all. These related lines are in dmesg output:

[   12.603011] input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input21
[   12.616367] vc4_hdmi 3f902000.hdmi: Could not register sound card: -517
[   12.722898] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   12.727545] Registered IR keymap rc-cec
[   12.727823] rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
[   12.728092] input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input22
[   12.960382] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[   12.960770] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[   12.961104] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
[   12.961426] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[   12.961722] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[   12.962021] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[   12.962262] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
[   12.971230] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[   13.031995] vc4-drm soc:gpu: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-22)

System
The system, when booted to a fully working state with fkms -> https://pastebin.com/4u9DV7L1

Additional context
The display in question is a hi-res RGB MIPI LCD with an HDMI->MIPI converter sitting between the PI and the LCD. However, when I hook it to a 1080P display, the same thing happens at the same spot. Everything works fine with legacy or fkms (other than the fact that I can't seem to get SDL2 working without having the extra X11 layer in between my app and the video driver).

[popcornmix]

The hdmi_*entries in config.txt are handled by the firmware and do not generally affect the kms driver.
You need to configure display timings using standard linux mechanisms. e.g. with xrandr.

[6by9]

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/cmdline.txt to tell DRM to load that instead of trying to read it from the display.

[MakerMatrix]

The HDMI->MIPI adapter board does have an EDID. I used /opt/vc/bin/tvservice -d, followed by the companion edidparser to craft the modeline I was passing to the firmware in config.txt.

So, I have commented all the hdmi* stuff out of config.txt, added disablefw_kms_setup=1, enabled the kms driver and it sort of works. But it looks like the timings are all off. The left half of the screen is showing what should be on the right half and there is 3.x-fold symmetry on the vertical axis where I'm seeing ~1/3rd of the vertical screen resolution output 3.x times. This is what raspi-config looks like:

Major step in the right direction though! This is the edidparser output:

Enabling fuzzy format match...
Parsing foo...
HDMI:EDID version 1.3, 1 extensions, screen size 12x7 cm
HDMI:EDID features - videodef 0x80 !standby !suspend !active off; colour encoding:RGB444|YCbCr422; sRGB is not default colourspace; preferred format is native; does not support GTF
HDMI:EDID found monitor name descriptor tag 0xfc
HDMI:EDID monitor name is ZHDISP08901
HDMI:EDID ignored unknown descriptor tag 0x10
HDMI:EDID ignored unknown descriptor tag 0x10
HDMI:EDID does not yet know monitor vertical range, setting to default 24 to 120Hz
HDMI:EDID failed to find a matching detail format for 2560x1600p hfp:123 hs:10 hbp:50 vfp:12 vs:4 vbp:4 pixel clock:222 MHz
HDMI:EDID calculated refresh rate is 50 Hz
HDMI:EDID guessing the format to be 2560x1600p @50 Hz
HDMI:EDID found unknown detail timing format: 2560x1600p hfp:123 hs:10 hbp:50 vfp:12 vs:4 vbp:4 pixel clock:222 MHz
HDMI:EDID established timing I/II bytes are 00 00 00
HDMI:EDID standard timings block x 8: 0x0101 0101 0101 0101 0101 0101 0101 0101
HDMI:EDID parsing v3 CEA extension 0
HDMI:EDID monitor support - underscan IT formats:no, basic audio:yes, yuv444:yes, yuv422:yes, #native DTD:4
HDMI:EDID failed to find a matching detail format for 2560x1600p hfp:123 hs:10 hbp:50 vfp:12 vs:4 vbp:4 pixel clock:222 MHz
HDMI:EDID calculated refresh rate is 50 Hz
HDMI:EDID guessing the format to be 2560x1600p @50 Hz
HDMI:EDID found unknown detail timing format: 2560x1600p hfp:123 hs:10 hbp:50 vfp:12 vs:4 vbp:4 pixel clock:222 MHz
HDMI:EDID failed to find a matching detail format for 2560x1600p hfp:123 hs:10 hbp:50 vfp:12 vs:4 vbp:4 pixel clock:222 MHz
HDMI:EDID calculated refresh rate is 50 Hz
HDMI:EDID guessing the format to be 2560x1600p @50 Hz
HDMI:EDID found unknown detail timing format: 2560x1600p hfp:123 hs:10 hbp:50 vfp:12 vs:4 vbp:4 pixel clock:222 MHz
HDMI:EDID failed to find a matching detail format for 2560x1600p hfp:123 hs:10 hbp:50 vfp:12 vs:4 vbp:4 pixel clock:222 MHz
HDMI:EDID calculated refresh rate is 50 Hz
HDMI:EDID guessing the format to be 2560x1600p @50 Hz
HDMI:EDID found unknown detail timing format: 2560x1600p hfp:123 hs:10 hbp:50 vfp:12 vs:4 vbp:4 pixel clock:222 MHz
HDMI:EDID failed to find a matching detail format for 2560x1600p hfp:123 hs:10 hbp:50 vfp:12 vs:4 vbp:4 pixel clock:222 MHz
HDMI:EDID calculated refresh rate is 50 Hz
HDMI:EDID guessing the format to be 2560x1600p @50 Hz
HDMI:EDID found unknown detail timing format: 2560x1600p hfp:123 hs:10 hbp:50 vfp:12 vs:4 vbp:4 pixel clock:222 MHz
HDMI:EDID failed to find a matching detail format for 2560x1600p hfp:123 hs:10 hbp:50 vfp:12 vs:4 vbp:4 pixel clock:222 MHz
HDMI:EDID calculated refresh rate is 50 Hz
HDMI:EDID guessing the format to be 2560x1600p @50 Hz
HDMI:EDID found unknown detail timing format: 2560x1600p hfp:123 hs:10 hbp:50 vfp:12 vs:4 vbp:4 pixel clock:222 MHz
HDMI:EDID does not understand CEA format code 0
HDMI:EDID does not understand CEA format code 0
HDMI:EDID does not understand CEA format code 0
HDMI:EDID does not understand CEA format code 0
HDMI:EDID does not understand CEA format code 0
HDMI:EDID does not understand CEA format code 0
HDMI:EDID does not understand CEA format code 0
HDMI:EDID found audio format 2 channels PCM, sample rate: 32|44|48|88|96|176|192 kHz, sample size: 16|20|24 bits
HDMI:EDID found HDMI VSDB length 6
HDMI:EDID HDMI VSDB has physical address 3.0.0.0
HDMI:EDID HDMI VSDB supports AI:yes, dual link DVI:no
HDMI:EDID HDMI VSDB deep colour support - 48-bit:no 36-bit:no 30-bit:no DC_yuv444:no
HDMI:EDID HDMI VSDB has no latency information
HDMI:EDID adding mandatory support for DMT (4) 640x480p @ 60Hz
HDMI:EDID adding mandatory support for CEA (1) 640x480p @ 60Hz
HDMI:EDID filtering formats with pixel clock unlimited MHz or h. blanking unlimited
HDMI:EDID no known preferred format has been set
HDMI:EDID filtering preferred group has been changed from Invalid to CEA
HDMI:EDID best score mode initialised to CEA (1) 640x480p @ 60 Hz with pixel clock 12 MHz (score 25)
HDMI:EDID best score mode is now CEA (1) 640x480p @ 60 Hz with pixel clock 25 MHz (score 61864)
HDMI:EDID DMT mode (4) 640x480p @ 60 Hz with pixel clock 25 MHz has a score of 18432
HDMI0:EDID preferred mode is updated to CEA (1) 640x480p @ 60 Hz with pixel clock 25200000 Hz
HDMI:EDID has HDMI support and audio support
/opt/vc/bin/edidparser exited with code 0

[6by9]

Please post the raw EDID for analysis.

edid-decode should be used in preference to edid-parser.

(Minor typo corrected in my earlier post - disable_fw_kms_setup=1 as I'd missed an underscore. It should mean that there is no entry starting video=HDMI-1... in /proc/cmdline)

[MakerMatrix]

I repaired disable_fw_kms_setup and verified that indeed there is no longer a video=HDMI* entry in /proc/cmdline. The screen is now blank again, after the kms driver loads. Changing the HDMI cable over to an LG 1080P screen results in "no signal". dmesg says:

pi@shrimp:~ $ dmesg | grep vc4
[   10.011657] fb0: switching to vc4drmfb from simple
[   10.017115] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   10.022947] rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
[   10.023223] input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input5
[   10.106689] vc4_hdmi 3f902000.hdmi: Could not register sound card: -517
[   10.385062] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   10.392436] rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
[   10.392718] input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input13
[   10.402211] vc4_hdmi 3f902000.hdmi: Could not register sound card: -517
[   10.523289] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   10.525500] rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
[   10.525825] input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input21
[   10.532012] vc4_hdmi 3f902000.hdmi: Could not register sound card: -517
[   10.856045] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
[   10.863206] rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
[   10.863518] input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input22
[   10.872939] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[   10.873294] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
[   10.873677] vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
[   10.874031] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4])
[   10.874647] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4])
[   10.875013] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4])
[   10.875267] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
[   10.926578] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
[   10.976380] vc4-drm soc:gpu: [drm] Cannot find any crtc or sizes
[   20.979661] vc4-drm soc:gpu: [drm] Cannot find any crtc or sizes

edid-decode (thanks, I also include the raw edid.dat inside the attached zip) says:
edid.zip

pi@shrimp:~ $ edid-decode foo
EDID version: 1.3
Manufacturer: ZHD Model 1807 Serial Number 0
Made in week 8 of 2018
Digital display
Maximum image size: 12 cm x 7 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Display x,y Chromaticity:
  Red:   0.6250, 0.3398
  Green: 0.2802, 0.5947
  Blue:  0.1552, 0.0703
  White: 0.2832, 0.2978
Established timings supported:
Standard timings supported:
Detailed mode: Clock 222.190 MHz, 640 mm x 400 mm
               2560 2683 2693 2743 hborder 0
               1600 1612 1616 1620 vborder 0
               +hsync +vsync
               VertFreq: 50 Hz, HorFreq: 81002 Hz
Monitor name: ZHDISP08901
Dummy block
Dummy block
Has 1 extension blocks
Checksum: 0xd5 (valid)

CTA extension block
Extension version: 3
19 bytes of CTA data
  Video data block
  Audio data block
    Linear PCM, max channels 2
      Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
      Supported sample sizes (bits): 24 20 16
  Vendor-specific data block, OUI 000c03 (HDMI)
    Source physical address 3.0.0.0
    Supports_AI
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
4 native detailed modes
Detailed mode: Clock 222.180 MHz, 1080 mm x 1920 mm
               2560 2683 2693 2743 hborder 0
               1600 1612 1616 1620 vborder 0
               -hsync -vsync
               VertFreq: 49 Hz, HorFreq: 80998 Hz
Detailed mode: Clock 222.180 MHz, 1080 mm x 1920 mm
               2560 2683 2693 2743 hborder 0
               1600 1612 1616 1620 vborder 0
               -hsync -vsync
               VertFreq: 49 Hz, HorFreq: 80998 Hz
Detailed mode: Clock 222.180 MHz, 1080 mm x 1920 mm
               2560 2683 2693 2743 hborder 0
               1600 1612 1616 1620 vborder 0
               -hsync -vsync
               VertFreq: 49 Hz, HorFreq: 80998 Hz
Detailed mode: Clock 222.180 MHz, 1080 mm x 1920 mm
               2560 2683 2693 2743 hborder 0
               1600 1612 1616 1620 vborder 0
               -hsync -vsync
               VertFreq: 49 Hz, HorFreq: 80998 Hz
Detailed mode: Clock 222.180 MHz, 1080 mm x 1920 mm
               2560 2683 2693 2743 hborder 0
               1600 1612 1616 1620 vborder 0
               -hsync -vsync
               VertFreq: 49 Hz, HorFreq: 80998 Hz
Checksum: 0x9b (valid)

[6by9]

    DTD 1:  2560x1600   50.002 Hz   8:5    81.003 kHz 222.190 MHz (640 mm x 400 mm)
                 Hfront  123 Hsync  10 Hback  50 Hpol P
                 Vfront   12 Vsync   4 Vback   4 Vpol P

Horizontal front porch of 123 is going to be rejected as a mode as the Pi4 hardware can only support even values in horizontal timings (https://www.raspberrypi.org/documentation/computers/config_txt.html#raspberry-pi-4-hdmi-pipeline)

Advertising the same detailed timings 6 times in the EDID seems a little odd, but not invalid. It offers no other modes, which explains the

[   10.976380] vc4-drm soc:gpu: [drm] Cannot find any crtc or sizes
[   20.979661] vc4-drm soc:gpu: [drm] Cannot find any crtc or sizes

as DRM ends up with no valid modes for the display.
Without disable_fw_kms_setup=1 the firmware would have stuck a video=HDMI-1: line in based on the standard mode that it believed should be used, and DRM then uses the standard CVT algorithm to generate the timings using that.

Seeing as this is running through an HDMI to DSI bridge, the porch timings are unlikely to be that critical. A quick hack to the EDID such as the attached (decreases the front porch to 122) may make it happy, or going the other way to 124.
linux_4516_2.zip
See above for details of putting it in /lib/firmware and altering cmdline.txt.

[MakerMatrix]

I'm learning a lot. Still not quite there.

pi@shrimp:~ $ dmesg | grep edid
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1  vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  console=ttyS0,115200 console=tty1 root=PARTUUID=86178334-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait  drm.edid_firmware=HDMI-A-1:edid/6by9-2560x1600_50-edid.dat
[   10.769520] [drm] Got external EDID base block and 1 extension from "edid/6by9-2560x1600_50-edid.dat" for connector "HDMI-A-1"
[   10.770714] [drm] Got external EDID base block and 1 extension from "edid/6by9-2560x1600_50-edid.dat" for connector "HDMI-A-1"
[   20.956193] [drm] Got external EDID base block and 1 extension from "edid/6by9-2560x1600_50-edid.dat" for connector "HDMI-A-1"

And verifying (this is a different blob and a different boot from the one above):

pi@shrimp:~ $ diff -s /lib/firmware/edid/edid.dat /sys/devices/platform/soc/soc\:gpu/drm/card0/card0-HDMI-A-1/edid
Files /lib/firmware/edid/edid.dat and /sys/devices/platform/soc/soc:gpu/drm/card0/card0-HDMI-A-1/edid are identical

So loading the edid blob seems to have worked. However still a blank screen when the driver loads, and:

pi@shrimp:~ $ dmesg | grep vc4 | tail -2
[   10.771716] vc4-drm soc:gpu: [drm] Cannot find any crtc or sizes
[   20.957209] vc4-drm soc:gpu: [drm] Cannot find any crtc or sizes

I also tried the edid.dat right off the HDMI->DSI board (I'm on 3B+, thinking maybe the even-pixel-clock-values issue doesn't apply) and had the exact same result.

Are you using Deltacast E-EDID to build/edit edid files or is there something better? Once this gets sorted I plan to write it up in a blog post for posterity (already drafting it).

Edit: I have switched to my LG ultrawide (2560x1080) screen, attempting to get the 3B+ to drive the panel at its native resolution. It seems to suffer a similar issue in that I cannot get the highest-resolution detailed timing to work. Am I hitting the max pixel clock for Pi 3B and so those modes get tossed out? I was overriding that with hdmi_pixel_freq_limit when using the firmware mode.

[MakerMatrix]

Okay, there may have actually been two broken things. I switched the 3B+ out for a 4B and now the LG ultrawide works at 2560x1080. So, the pixel clock limit was probably responsible for that mode not working on that screen.

Then, loading your EDID into Deltacast, I saw that H.Blank was an odd number (183). Changed it to 184 and BOOM!

pi@pi4-msla:~ $ fbset -i -v
Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
(C) Copyright 1995-1999 by Geert Uytterhoeven

Opening frame buffer device `/dev/fb0'
Using current video mode from `/dev/fb0'

mode "2560x1600"
    geometry 2560 1600 2560 1600 16
    timings 0 0 0 0 0 0 0
    accel true
    rgba 5/11,6/5,5/0,0/0
endmode

Getting further frame buffer information
Frame buffer device information:
    Name        : vc4drmfb
    Address     : 0
    Size        : 8192000
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 5120
    Accelerator : No

Thank you very much.

I would still be curious to know if there is a kernel way to override the max pixel clock on the Pi 3 series, or if I need to give up on that under KMS. I searched for kernel command line parameters that might behave like hdmi_pixel_freq_limit but did not find anything. I tried setting it in config.txt but I suspect that this is overridden by disable_fw_kms_setup=1

[6by9]

I was editing the EDID by hand. Use xxd -g 0 edid.bin edid.txt to convert to a text file, edit (in this case convert 123 to hex 7b, find that, and replace), and then xxd -r -g 0 edid.txt edid_new.bin to convert back to hex.
Run through edid-decode and it tells you the checksums fail and what they should be. They are bytes 128 & 256, so the end of line 8 and 16 respectively. Fix those up. Run through xxd -r ... again, and you should be good to go.

If you add drm.debug=0x14 to /boot/cmdline.txt then DRM logs all the mode selection and validation information to the kernel log.

The max pixel clock for vc4-kms-v3d is dictated by the driver, and there's no override provided. https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/gpu/drm/vc4/vc4_hdmi.c#L2444 dictates 162MHz for Pi0-3. 222MHz is quite a long way above the spec for Pi3.
Pi0-3 do not have the limitation of even timings as they only run at 1 pixel per clock cycle.

[MakerMatrix]

Oooh, the debug option will be handy. I have more screens like this in my future.

That's a real shame about the pixel clock. The firmware options around that are/were very handy. I will suggest that 222MHz is not too crazy. In my experience to get that to work reliably you just have to tell the CPU to never run below 800MHz (arm_freq_min). Or maybe one of the GPU clock options would work - I just discovered those when wading through docs for this issue. So, 222MHz does not really require overclocking, just trimming some of the power saving features. Similarly, to get 4K/30 to work on Pi3, you need ~1GHz IIRC, so right near the limit but doable under many circumstances. These are very handy things and of course, you know that now I'm going to naively ask because I have no idea what kind of effort I'm suggesting - can such a feature get added to the driver? :-D

Thank you again, this has been extremely enlightening and helpful. I will finish my post on the weekend and report back here to ask for your feedback, if you have time.

[lesar]

Me too have the same problem.
I use

disable_overscan=1
dtoverlay=vc4-kms-v3d
hdmi_drive:0=1
hdmi_group:0=2
hdmi_mode:0=82
hdmi_drive:1=1
hdmi_group:1=2
hdmi_mode:1=82

and only fkms work

[6by9]

Me too have the same problem.

No you don't - you're trying to force an alternate mode, not using group 2 / mode 87 to specify custom timings via hdmi_timings or hdmi_cvt.

#4516 (comment) and #4516 (comment) both still apply - vc4-kms-v3d does not use the hdmi_* entries from config.txt.

Group 2 (DMT) mode 82 appears to be a standard 1080p60 mode. Why the need to force it?
vc4-kms-v3d largely relies on valid EDIDs.

[lesar]

Thanks @6by9
is some time I run Ubuntu on PI and, at initial time, if I do not use group and mode I get only a black screen.
I try to remove this settings and all work well but work only on fkms.
If I use kms, monitor are not recognized and I get only one screen working.
this is my config now:

disable_overscan=1
boot_delay=2
dtparam=audio=on
dtoverlay=vc4-fkms-v3d
#dtoverlay=vc4-kms-v3d #this not work

if I use vc4-kms-v3d in usercfg.txt and do:
$ sudo xrandr --output HDMI-1 --auto --left-of HDMI-2
I get:

xrandr: Failed to get size of gamma for output default
warning: output HDMI-1 not found; ignoring

and only one screen is working
I'm on Ubuntu 20.04.3 5.4.0-1045-raspi aarch64