HDMI:1 resolution setting changing HDMI:0

[JamesH65]

Reference this issue reported on the forum.

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=247800

Appears that setting resolution on HDMI:1 is affecting HDMI:0

[6by9]

hdmi_cvt and hdmi_timings both set up the custom mode in either the DMT or CEA table. Note that you have both

hdmi_mode:0=87
hdmi_group:0=2

hdmi_mode:1=87
hdmi_group:1=2

in config.txt.

hdmi_cvt:0 will come along and set up mode 87.
hdmi_cvt:1 will come along and overwrite it.
The displays then both get powered up trying to use group 2 mode 87 and will get the same set of timings from hdmi_cvt:1.

I did start looking at silently remapping hdmi1 to use mode 88 instead of 87, but didn't complete it.

A quick hack for now would be to use hdmi_group=1 and hdmi_mode=107 for one of the displays (it's changed from hdmi_mode=65 as 4k adds more CEA modes).

[fcollingwood]

6by9, I tried the hack, unfortunately I'm still getting an incorrect resolution on HDMI 0.

Relevant portion of /boot/config.txt is:

[HDMI:0]
# settings for exposure screen on HDMI 0
hdmi_force_hotplug=1
hdmi_cvt 1024 600 60 3 0 0 0
hdmi_mode=107
hdmi_group=1


[HDMI:1]
# Settings for 7" touchscreen on HDMI 1
hdmi_force_hotplug=1
hdmi_cvt 800 480 60 6 0 0 0
hdmi_mode=87
hdmi_group=2

This is the result:

pi@raspberrypi:~ $ tvservice -s -v 2
state 0xa [HDMI CEA (17) RGB lim 4:3], 720x576 @ 50.00Hz, progressive
pi@raspberrypi:~ $ tvservice -s -v 7
state 0xa [HDMI DMT (87) RGB full 15:9], 800x480 @ 59.00Hz, progressive
pi@raspberrypi:~ $ fbset -fb /dev/fb0 -s

mode "656x512"
    geometry 656 512 656 512 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,8/24
endmode

pi@raspberrypi:~ $ fbset -fb /dev/fb1 -s

mode "800x480"
    geometry 800 480 800 480 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,8/24
endmode

pi@raspberrypi:~ $ 

[fcollingwood]

Even stranger. I swapped the group settings (And disabled overscan), as per:

[HDMI:0]
# settings for exposure screen on HDMI 0
hdmi_force_hotplug=1
hdmi_cvt=1024 600 60 3 0 0 0
hdmi_mode=87
hdmi_group=2


[HDMI:1]
# Settings for 7" touchscreen on HDMI 1
hdmi_force_hotplug=1
hdmi_cvt=800 480 60 6 0 0 0
hdmi_mode=107
hdmi_group=1

and now I am getting:

pi@raspberrypi:~ $ tvservice -s -v 2
state 0xa [HDMI DMT (87) RGB full 15:9], 800x480 @ 59.00Hz, progressive
pi@raspberrypi:~ $ tvservice -s -v 7
state 0xa [HDMI CEA (17) RGB lim 4:3], 720x576 @ 50.00Hz, progressive
pi@raspberrypi:~ $ fbset -fb /dev/fb0 -s

mode "800x480"
    geometry 800 480 800 480 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,8/24
endmode

pi@raspberrypi:~ $ fbset -fb /dev/fb1 -s

mode "720x576"
    geometry 720 576 720 576 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,8/24
endmode

pi@raspberrypi:~ $ 

[6by9]

Why hdmi_mode=107 becomes mode 17 is the odd thing - that's a very odd one for the string parser to do.

I'm suspecting that the hdmi_cvt line gets executed immediately, therefore the hdmi_group needs to be before it.

I'll see if the code for pushing the timings for the two displays into independent modes can be easily made to work. That's the better solution than having to use different modes for the two displays. @JamesH65 Do you want to pick that up instead?

[fcollingwood]

I changed the order to:

[HDMI:0]
# settings for exposure screen on HDMI 0
hdmi_force_hotplug=1
hdmi_mode=87
hdmi_group=2
hdmi_cvt=1024 600 60 3 0 0 0


[HDMI:1]
# Settings for 7" touchscreen on HDMI 1
hdmi_force_hotplug=1
hdmi_mode=107
hdmi_group=1
hdmi_cvt=800 480 60 6 0 0 0

Unfortunately it doesn't seem to have made any difference:

pi@raspberrypi:~ $ tvservice -s -v 2
state 0xa [HDMI DMT (87) RGB full 15:9], 800x480 @ 59.00Hz, progressive
pi@raspberrypi:~ $ tvservice -s -v 7
state 0xa [HDMI CEA (17) RGB lim 4:3], 720x576 @ 50.00Hz, progressive
pi@raspberrypi:~ $ fbset -fb /dev/fb0 -s

mode "800x480"
    geometry 800 480 800 480 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,8/24
endmode

pi@raspberrypi:~ $ fbset -fb /dev/fb1 -s

mode "720x576"
    geometry 720 576 720 576 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,8/24
endmode

pi@raspberrypi:~ $ 

[6by9]

Very odd quirk found. hdmi_cvt will only ever update the entry in the DMT table, irrespective of hdmi_group.
hdmi_timings will follow hdmi_group and update the right table.

Having done

hdmi_force_hotplug:0=1
hdmi_group:0=1
hdmi_mode:0=107
hdmi_timings:0=800 0 40 48 88 480 0 13 3 32 0 0 0 60 0 32000000 6

hdmi_force_hotplug:1=1
hdmi_group:1=2
hdmi_mode:1=87
hdmi_timings:1=1280 0 110 40 220 720 0 5 5 20  0 0 0 60 0 74250000 6

I get the expected resolutions.

pi@raspberrypi:~ $ tvservice -s -v 2
state 0xa [HDMI CEA (107) RGB lim 15:9], 800x480 @ 60.00Hz, progressive
pi@raspberrypi:~ $ tvservice -s -v 7
state 0xa [HDMI DMT (87) RGB full 15:9], 1280x720 @ 60.00Hz, progressive
pi@raspberrypi:~ $ fbset -fb /dev/fb0 -s

mode "736x416"
    geometry 736 416 736 416 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,8/24
endmode

pi@raspberrypi:~ $ fbset -fb /dev/fb1 -s

mode "1280x720"
    geometry 1280 720 1280 720 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,8/24
endmode

(I still have overscan enabled, hence the slightly under 800x480 display).

See https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679 for details of creating full timings. The command cvt will give you the overall timings, but you need to do some simple subtraction to get it into the right format for the hdmi_timings line. See https://elixir.bootlin.com/linux/v5.2.6/source/include/drm/drm_modes.h#L198 for the details.

Meanwhile I'll look at fixing up hdmi_cvt for either mode, and independent custom modes.

[fcollingwood]

Hi 6by9

I can't make head or tail of how I would convert:

pi@raspberrypi:~ $ cvt -v 800 480 60
Warning: Aspect Ratio is not CVT standard.
# 800x480 59.48 Hz (CVT) hsync: 29.74 kHz; pclk: 29.50 MHz
Modeline "800x480_60.00"   29.50  800 824 896 992  480 483 493 500 -hsync +vsync
pi@raspberrypi:~ $

to

hdmi_timings=800 ? ? ? ? 480 ? ? ? ? ? ? ? ? ? ? ?

I've filled in the only bits I can figure out. I can't even find an explanation of the data that cvt spits out.

I can't see any calculations being done in the second link you gave me, and I don't see much correlation between what is required for hdmi_timings and the code in the second link; For example, I see no mention of any 'porch' in the code.

Please could you give some guidance - I don't want you to do it for me, then I learn nothing, but please assume I know nothing about the subject (Because I don't), and explain accordingly

[popcornmix]

If you have something like:

hdmi_force_hotplug:0=1
hdmi_group:0=1
hdmi_mode:0=107
hdmi_cvt:0=800 480 60

in config.txt the firmware will use the cvt formula to calculate hdmi_timings values.
You can see those with:

pi@pi3:~ $ vcgencmd hdmi_timings
hdmi_timings=800 0 24 72 96 480 1 3 2 15 0 0 0 59 0 29500000 3

[6by9]

For reference, comparing the output from "cvt 800 480 60"

# 800x480 59.48 Hz (CVT) hsync: 29.74 kHz; pclk: 29.50 MHz
Modeline "800x480_60.00"   29.50  800 824 896 992  480 483 493 500 -hsync +vsync

vs what the firmware wants

hdmi_timings=800 0 24 72 96 480 1 3 2 15 0 0 0 59 0 29500000 3

hdmi_timings=800 (active width)
0 (-hsync)
24 (824-800)
72 (896-824)
96 (996-892)
480 (active height)
1 (+vsync)
3 (483-480)
2 (493-483 see below)
15 (500-493 see below)
0
0
0
59 (fps)
0
29500000 (29.50*1000000)
3 (aspect ratio)

As noted, the vsync period and vback porch values don't match between the two modes.
Supposedly they are both implementing the same formula, so I'm now curious as to which is at fault! Few displays care too much over the exact widths of the sync pulses as long as the overall timing is correct. C'est la vie, and another thing to investigate.

[6by9]

OK, I think James has sorted the issue with hdmi_cvt only working for DMT modes, and I seem to have independent settings for the displays when using hdmi_group=2 hdmi_mode=87 on both displays.
Both those fixes should be released in due course.

Now to have a quick look at the differences with the CVT timings....

[JamesH65]

@6by9 I think the original issue has been fixed, so we can close this? @fcollingwood Have you tested with the latest release?