firmware
firmware copied to clipboard
raspberrypi
HDMI:1 resolution setting changing HDMI:0
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
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).
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:~ $
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:~ $
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?
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:~ $
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.
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
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
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.
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....
@6by9 I think the original issue has been fixed, so we can close this? @fcollingwood Have you tested with the latest release?
I believe so, although you do still have that pending firmware commit which was in this area.
Hi. I'm having a great deal of trouble getting a Waveshare 7" LCD(C) to work on Pi4
I'm currently running (uname -a)
Linux raspberrypi 5.4.83-v7l+ #1379 SMP Mon Dec 14 13:11:54 GMT 2020 armv7l GNU/Linux
I was wondering if the fixes you mentioned are in this release?
According to the WaveShare site, it should work with Pi4 with these config settings:
max_usb_current=1 hdmi_group=2 hdmi_mode=87 hdmi_cvt 1024 600 60 6 0 0 0 hdmi_drive=1
But I just get a blank screen near the end of the boot, though I can see some flickering. Without these params, I get a picture, but of course it's all over the place.
Could you advise, please?
Thanks!
Hi. I'm having a great deal of trouble getting a Waveshare 7" LCD(C) to work on Pi4
I'm currently running (uname -a)
Linux raspberrypi 5.4.83-v7l+ #1379 SMP Mon Dec 14 13:11:54 GMT 2020 armv7l GNU/Linux
I was wondering if the fixes you mentioned are in this release?
According to the WaveShare site, it should work with Pi4 with these config settings:
max_usb_current=1 hdmi_group=2 hdmi_mode=87 hdmi_cvt 1024 600 60 6 0 0 0 hdmi_drive=1
But I just get a blank screen near the end of the boot, though I can see some flickering. Without these params, I get a picture, but of course it's all over the place.
Could you advise, please?
Thanks!
It turns out that I had to comment out the line dtoverlay=vc4-fkms-V3D
This is noted in Waveshare's documentation but only for rotating displays.
Should this be necessary?
Did this ever get fixed? I'm having trouble outputting 2 different resolutions on the fkms drivers with the following config.txt. On a Raspberry Pi CM4.
uncomment if hdmi display is not detected and composite is being output
hdmi_force_hotplug:0=1 hdmi_ignore_edid:1=0xa5000080
uncomment to force a specific HDMI mode (here we are forcing 800x480!)
hdmi_group:0=2 hdmi_mode:0=87 #hdmi_cvt:0=800 480 60 6 0 0 0 hdmi_timings:0=800 0 24 72 96 480 1 3 2 15 0 0 0 59 0 29500000 3
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
uncomment to force a HDMI mode rather than DVI. This can make audio work in
DMT (computer monitor) modes
hdmi_drive=1
