firmware
firmware copied to clipboard
raspberrypi
rpi4 hdmi not working with motorola atrix lapdock
3a+(hdmi works by default) vs 4b(hdmi doesn't work by default)
Docs used: https://www.raspberrypi.org/documentation/configuration/config-txt/video.md Image used: 2019-07-10-raspbian-buster-lite.img from https://www.raspberrypi.org/downloads/raspbian/ Ran: apt update && apt upgrade && apt dist-upgrade
- All reported 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded
Ran: apt install raspberrypi-ui-mods On pi4 I used the hdmi port 0 near the usb-c connector
Both report:
# uname -a
Linux pi 4.19.57-v7l+ #1244 SMP Thu Jul 4 18:48:07 BST 2019 armv7l GNU/Linux
# cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
- 3a+
Works just fine by default
root@pi3aplus:~# grep -vE '^(#|$)' /boot/config.txt
dtparam=audio=on
[pi4]
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
root@pi3aplus:~# /opt/vc/bin/tvservice -m CEA
Group CEA has 5 modes:
mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
root@pi3aplus:~# /opt/vc/bin/tvservice -m DMT
Group DMT has 2 modes:
mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
(prefer) mode 86: 1366x768 @ 60Hz 16:9, clock:72MHz progressive
root@pi3aplus:~# /opt/vc/bin/tvservice -s
state 0xa [HDMI DMT (86) RGB full 16:9], 1366x768 @ 60.00Hz, progressive
root@pi3aplus:~# /opt/vc/bin/tvservice -d edid.dat
Written 256 bytes to edid.dat
root@pi3aplus:~# /opt/vc/bin/edidparser edid.dat
Enabling fuzzy format match...
Parsing edid.dat...
HDMI:EDID version 1.3, 1 extensions, screen size 26x14 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 S/N descriptor tag 0xff
HDMI:EDID found monitor range descriptor tag 0xfd
HDMI:EDID monitor range offsets: V min=0, V max=0, H min=0, H max=0
HDMI:EDID monitor range: vertical is 50-75 Hz, horizontal is 30-85 kHz, max pixel clock is 150 MHz
HDMI:EDID monitor range does not support GTF
HDMI:EDID found monitor name descriptor tag 0xfc
HDMI:EDID monitor name is MotoAttach
HDMI:EDID found preferred DMT detail timing format: 1366x768p @ 60 Hz (86)
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:1
HDMI:EDID found DMT detail timing format: 1366x768p @ 60 Hz (86)
HDMI:EDID found DMT detail timing format: 1366x768p @ 60 Hz (86)
HDMI:EDID failed to find a matching detail format for 0x1080i hfp:88 hs:44 hbp:-116 vfp:2 vs:5 vbp:16 pixel clock:0 MHz
HDMI:EDID calculated refresh rate is 0 Hz
HDMI:EDID guessing the format to be 0x1080i @24 Hz
HDMI:EDID found unknown detail timing format: 0x1080i hfp:88 hs:44 hbp:-116 vfp:2 vs:5 vbp:16 pixel clock:0 MHz
HDMI:EDID found CEA format: code 1, 640x480p @ 60Hz
HDMI:EDID found CEA format: code 3, 720x480p @ 60Hz
HDMI:EDID found CEA format: code 18, 720x576p @ 50Hz
HDMI:EDID found audio format 2 channels PCM, sample rate: 32|44|48|96|192 kHz, sample size: 16|20|24 bits
HDMI:EDID found HDMI VSDB length 5
HDMI:EDID HDMI VSDB has physical address 1.0.0.0
HDMI:EDID HDMI VSDB has no extension fields
HDMI:EDID adding mandatory support for DMT (4) 640x480p @ 60Hz
HDMI:EDID adding mandatory support for CEA (2) 720x480p @ 60Hz
HDMI:EDID adding mandatory support for CEA (17) 720x576p @ 50Hz
HDMI:EDID filtering formats with pixel clock unlimited MHz or h. blanking unlimited
HDMI:EDID best score mode initialised to DMT (4) 640x480p @ 60 Hz with pixel clock 25 MHz (score 0)
HDMI:EDID best score mode is now CEA (1) 640x480p @ 60 Hz with pixel clock 25 MHz (score 43432)
HDMI:EDID best score mode is now CEA (2) 720x480p @ 60 Hz with pixel clock 27 MHz (score 45736)
HDMI:EDID CEA mode (3) 720x480p @ 60 Hz with pixel clock 27 MHz has a score of 45736
HDMI:EDID DMT mode (4) 640x480p @ 60 Hz with pixel clock 25 MHz has a score of 36864
HDMI:EDID CEA mode (17) 720x576p @ 50 Hz with pixel clock 27 MHz has a score of 45736
HDMI:EDID CEA mode (18) 720x576p @ 50 Hz with pixel clock 27 MHz has a score of 45736
HDMI:EDID best score mode is now DMT (86) 1366x768p @ 60 Hz with pixel clock 72 MHz (score 5188835)
HDMI0:EDID preferred mode remained as DMT (86) 1366x768p @ 60 Hz with pixel clock 72 MHz
HDMI:EDID has HDMI support and audio support
/opt/vc/bin/edidparser exited with code 0
- pi4
This, by default, doesn't work. not even the colored square before the boot. So I tend to believe it's not raspbian's fault.
root@pi4b:~# grep -vE '^(#|$)' /boot/config.txt
dtparam=audio=on
[pi4]
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
root@pi4b:~# /opt/vc/bin/tvservice -m CEA
Group CEA has 5 modes:
mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
root@pi4b:~# /opt/vc/bin/tvservice -m DMT
Group DMT has 2 modes:
mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
(prefer) mode 86: 1366x768 @ 60Hz 16:9, clock:72MHz progressive
root@pi4b:~# /opt/vc/bin/tvservice -s
state 0xa [HDMI CUSTOM RGB full 16:9], 1366x768 @ 60.00Hz, progressive
root@pi4b:~# /opt/vc/bin/tvservice -d edid.dat
Written 256 bytes to edid.dat
root@pi4b:~# /opt/vc/bin/edidparser edid.dat
Enabling fuzzy format match...
Parsing edid.dat...
HDMI:EDID version 1.3, 1 extensions, screen size 26x14 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 S/N descriptor tag 0xff
HDMI:EDID found monitor range descriptor tag 0xfd
HDMI:EDID monitor range offsets: V min=0, V max=0, H min=0, H max=0
HDMI:EDID monitor range: vertical is 50-75 Hz, horizontal is 30-85 kHz, max pixel clock is 150 MHz
HDMI:EDID monitor range does not support GTF
HDMI:EDID found monitor name descriptor tag 0xfc
HDMI:EDID monitor name is MotoAttach
HDMI:EDID found preferred DMT detail timing format: 1366x768p @ 60 Hz (86)
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:1
HDMI:EDID found DMT detail timing format: 1366x768p @ 60 Hz (86)
HDMI:EDID found DMT detail timing format: 1366x768p @ 60 Hz (86)
HDMI:EDID failed to find a matching detail format for 0x1080i hfp:88 hs:44 hbp:-116 vfp:2 vs:5 vbp:16 pixel clock:0 MHz
HDMI:EDID calculated refresh rate is 0 Hz
HDMI:EDID guessing the format to be 0x1080i @24 Hz
HDMI:EDID found unknown detail timing format: 0x1080i hfp:88 hs:44 hbp:-116 vfp:2 vs:5 vbp:16 pixel clock:0 MHz
HDMI:EDID found CEA format: code 1, 640x480p @ 60Hz
HDMI:EDID found CEA format: code 3, 720x480p @ 60Hz
HDMI:EDID found CEA format: code 18, 720x576p @ 50Hz
HDMI:EDID found audio format 2 channels PCM, sample rate: 32|44|48|96|192 kHz, sample size: 16|20|24 bits
HDMI:EDID found HDMI VSDB length 5
HDMI:EDID HDMI VSDB has physical address 1.0.0.0
HDMI:EDID HDMI VSDB has no extension fields
HDMI:EDID adding mandatory support for DMT (4) 640x480p @ 60Hz
HDMI:EDID adding mandatory support for CEA (2) 720x480p @ 60Hz
HDMI:EDID adding mandatory support for CEA (17) 720x576p @ 50Hz
HDMI:EDID filtering formats with pixel clock unlimited MHz or h. blanking unlimited
HDMI:EDID best score mode initialised to DMT (4) 640x480p @ 60 Hz with pixel clock 25 MHz (score 0)
HDMI:EDID best score mode is now CEA (1) 640x480p @ 60 Hz with pixel clock 25 MHz (score 43432)
HDMI:EDID best score mode is now CEA (2) 720x480p @ 60 Hz with pixel clock 27 MHz (score 45736)
HDMI:EDID CEA mode (3) 720x480p @ 60 Hz with pixel clock 27 MHz has a score of 45736
HDMI:EDID DMT mode (4) 640x480p @ 60 Hz with pixel clock 25 MHz has a score of 36864
HDMI:EDID CEA mode (17) 720x576p @ 50 Hz with pixel clock 27 MHz has a score of 45736
HDMI:EDID CEA mode (18) 720x576p @ 50 Hz with pixel clock 27 MHz has a score of 45736
HDMI:EDID best score mode is now DMT (86) 1366x768p @ 60 Hz with pixel clock 72 MHz (score 5188835)
HDMI0:EDID preferred mode remained as DMT (86) 1366x768p @ 60 Hz with pixel clock 72 MHz
HDMI:EDID has HDMI support and audio support
/opt/vc/bin/edidparser exited with code 0
So I tried messing with /boot/config.txt
This, works, even if it's 640x480, at least it works.
root@pi4b:~# grep -vE '^(#|$)' /boot/config.txt
hdmi_safe=1
dtparam=audio=on
[pi4]
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
root@pi4b:~# /opt/vc/bin/tvservice -m CEA
Group CEA has 5 modes:
mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
root@pi4b:~# /opt/vc/bin/tvservice -m DMT
Group DMT has 2 modes:
(prefer) mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 86: 1366x768 @ 60Hz 16:9, clock:72MHz progressive
root@pi4b:~# /opt/vc/bin/tvservice -s
state 0xa [HDMI CUSTOM RGB full 4:3], 640x480 @ 60.00Hz, progressive
So I noticed that on pi3aplus the state is set to DMT(86).... I tried forcing that too, doesn't work either
root@pi4b:~# grep -vE '^(#|$)' /boot/config.txt
hdmi_group=2
hdmi_mode=86
dtparam=audio=on
[pi4]
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
root@pi4b:~# /opt/vc/bin/tvservice -m CEA
Group CEA has 5 modes:
mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
root@pi4b:~# /opt/vc/bin/tvservice -m DMT
Group DMT has 2 modes:
mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
(prefer) mode 86: 1366x768 @ 60Hz 16:9, clock:72MHz progressive
root@pi4b:~# /opt/vc/bin/tvservice -s
state 0xa [HDMI CUSTOM RGB full 16:9], 1366x768 @ 60.00Hz, progressive
I also tried with an empty config.txt file too.
Just to confirm, you tested with an empty config.txt (so not even dtoverlay=vc4-fkms-v3d) and it still failed on Pi4?
Another interesting thing I just noticed is that if I plug the monitor a few moments after I power it on... I get this
root@pi4b:~# /opt/vc/bin/tvservice -s
state 0x120001 [TV is off]
And for some reason.. I just tried a reboot .. shows about right but no output :|
state 0xa [HDMI DMT (86) RGB full 16:9], 1366x768 @ 60.00Hz, progressive
1366x768 is a slightly awkward resolution but should be supported because it works on the Pi-Top CEED which is the same resolution. The awkward bit is that part of the display pipeline counts the horizontal timings in multiples of two pixels and one of them is an odd number. It's possible that the PiTop CEED is more tolerant of the output, there might be a configurable workaround but it probably involves cropping the display width by one pixel
It should be supported because it worked just fine on pi3 / pi3a+ I guess too .. Let me know if you want me to try stuff. As long as there's no risk of bricking stuff, I can gladly test. Thanks !
Please dump the raw edid (tvservice -d edid.dat), zip edid.dat, and attach it to this issue.
The display stack has changed significantly with Pi4, and having a valid EDID is the key to it all working.
root@pi4b:~# tvservice -d edid.dat
Written 256 bytes to edid.dat
root@pi4b:~# zip edid edid.dat
adding: edid.dat (deflated 43%)
I used this display to play on my PS3 sometimes and it worked ok, if that helps...
Hi, just soldered the (USB) cable for a Artix Laptop and connected a Pi4 to it for the first time. The HDMI works for me.
Here is the output from edidparser:
Enabling fuzzy format match...
Parsing edid...
HDMI:EDID version 1.3, 1 extensions, screen size 26x14 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 S/N descriptor tag 0xff
HDMI:EDID found monitor range descriptor tag 0xfd
HDMI:EDID monitor range offsets: V min=0, V max=0, H min=0, H max=0
HDMI:EDID monitor range: vertical is 50-75 Hz, horizontal is 30-85 kHz, max pixel clock is 150 MHz
HDMI:EDID monitor range does not support GTF
HDMI:EDID found monitor name descriptor tag 0xfc
HDMI:EDID monitor name is MotoAttach
HDMI:EDID found preferred DMT detail timing format: 1366x768p @ 60 Hz (86)
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:1
HDMI:EDID found DMT detail timing format: 1366x768p @ 60 Hz (86)
HDMI:EDID found DMT detail timing format: 1366x768p @ 60 Hz (86)
HDMI:EDID failed to find a matching detail format for 0x1080i hfp:88 hs:44 hbp:-116 vfp:2 vs:5 vbp:16 pixel clock:0 MHz
HDMI:EDID calculated refresh rate is 0 Hz
HDMI:EDID guessing the format to be 0x1080i @24 Hz
HDMI:EDID found unknown detail timing format: 0x1080i hfp:88 hs:44 hbp:-116 vfp:2 vs:5 vbp:16 pixel clock:0 MHz
HDMI:EDID found CEA format: code 1, 640x480p @ 60Hz
HDMI:EDID found CEA format: code 3, 720x480p @ 60Hz
HDMI:EDID found CEA format: code 18, 720x576p @ 50Hz
HDMI:EDID found audio format 2 channels PCM, sample rate: 32|44|48|96|192 kHz, sample size: 16|20|24 bits
HDMI:EDID found HDMI VSDB length 5
HDMI:EDID HDMI VSDB has physical address 1.0.0.0
HDMI:EDID HDMI VSDB has no extension fields
HDMI:EDID adding mandatory support for DMT (4) 640x480p @ 60Hz
HDMI:EDID adding mandatory support for CEA (2) 720x480p @ 60Hz
HDMI:EDID adding mandatory support for CEA (17) 720x576p @ 50Hz
HDMI:EDID filtering formats with pixel clock unlimited MHz or h. blanking unlimited
HDMI:EDID best score mode initialised to DMT (4) 640x480p @ 60 Hz with pixel clock 25 MHz (score 0)
HDMI:EDID best score mode is now CEA (1) 640x480p @ 60 Hz with pixel clock 25 MHz (score 43432)
HDMI:EDID best score mode is now CEA (2) 720x480p @ 60 Hz with pixel clock 27 MHz (score 45736)
HDMI:EDID CEA mode (3) 720x480p @ 60 Hz with pixel clock 27 MHz has a score of 45736
HDMI:EDID DMT mode (4) 640x480p @ 60 Hz with pixel clock 25 MHz has a score of 36864
HDMI:EDID CEA mode (17) 720x576p @ 50 Hz with pixel clock 27 MHz has a score of 45736
HDMI:EDID CEA mode (18) 720x576p @ 50 Hz with pixel clock 27 MHz has a score of 45736
HDMI:EDID best score mode is now DMT (86) 1366x768p @ 60 Hz with pixel clock 72 MHz (score 5188835)
HDMI0:EDID preferred mode remained as DMT (86) 1366x768p @ 60 Hz with pixel clock 72 MHz
HDMI:EDID has HDMI support and audio support
edidparser exited with code 0
and this is what I put in my /boot/config.txt
hdmi_group=2
hdmi_cvt=1366 768 60
hdmi_mode=87
Hope this might be helpful...
@LennartHennigs THANKS ! Can confirm that works ! Now the questions are:
- why ?
- Is this normal expected behaviour ?
- What's the difference between hdmi_mode 81/86 and this custom mode ?
- any plans on changing this default behaviour ?
vc4-fkms-v3d is the default display driver for the Pi4. With this the kernel driver parses the full EDID from the monitor and selects the mode it views as correct. You can use modetest (from https://gitlab.freedesktop.org/mesa/drm/tree/master/tests/modetest) or xrandr --verbose to view the modes that it has found.
Using your EDID I get the following lists of modes from the EDID:
modes:
name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
1366x768 60 1366 1380 1436 1500 768 769 772 800 72000 flags: phsync, pvsync; type: preferred, driver
1366x768 63 1366 1380 1436 1500 768 769 772 800 75500 flags: phsync, pvsync; type: driver
720x576 50 720 732 796 864 576 581 586 625 27000 flags: nhsync, nvsync; type: driver
720x480 60 720 736 798 858 480 489 495 525 27027 flags: nhsync, nvsync; type: driver
720x480 60 720 736 798 858 480 489 495 525 27000 flags: nhsync, nvsync; type: driver
640x480 60 640 656 752 800 480 490 492 525 25200 flags: nhsync, nvsync; type: driver
640x480 60 640 656 752 800 480 490 492 525 25175 flags: nhsync, nvsync; type: driver
If you force a mode via hdmi_cvt, then the EDID is thrown away and that one mode becomes available. Using the above runes, modetest reports:
modes:
name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
FIXED_MODE 60 1360 1432 1568 1776 768 771 773 798 84750 flags: phsync, pvsync; type: preferred, driver
Note the subtle differences in timings, and somewhere the mode appears to have been dropped from 1366 to 1360 pixels wide (it looks to be because it matches the aspect ratio). The values are slightly different between the modes, and one works whilst the other doesn't. I'd need to check with the HDMI analyser as to whether it is the screen or Pi that is doing funny things. (timg236 has made the comment that the odd values in the timings may cause grief as the pipeline works on two pixels per clock).
The old firmware EDID parser was slightly strange in that it would find the closest standard mode to that advertised by the EDID, it didn't always take the EDID at face value.
Makes sense... Thanks for looking into it. Let me know if there's anything I can help test or need to provide...I'm a little bit friendly with linux so don't be afraid to ask technical stuff if needed. If there's something I can do, I'll at least try... Thanks again for looking into this !
1366x768 is a slightly awkward resolution but should be supported because it works on the Pi-Top CEED which is the same resolution. The awkward bit is that part of the display pipeline counts the horizontal timings in multiples of two pixels and one of them is an odd number. It's possible that the PiTop CEED is more tolerant of the output, there might be a configurable workaround but it probably involves cropping the display width by one pixel
The official docs at https://www.raspberrypi.org/documentation/configuration/config-txt/video.md say DMT mode 86 has "reduced blanking" on the Pi, and doesn't specify a refresh rate (rather than the standard, which is 60Hz), so I'm wondering if some "special sauce" was applied in the VC4 firmware to get this mode working on some screens and somehow work around the problem you mention with the display pipeline. It certainly does seem to work better on some screens with the Pi 3 and earlier - see https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=247149 for another user who has what looks like the same screen, or very similar, which was previously working on a Pi 3B, and some earlier boards as well.
My suggested solution would therefore be that someone at Pi towers needs to see what the Pi 3 and earlier VC4 firmware does, since only RPF/T have access to the source code.
Well. That must smarter people than me find out. This is what I found after some googling and some trial and error :-)
Am 29.07.2019 um 19:56 schrieb Adrian Sandu [email protected]:
@LennartHennigs THANKS ! Can confirm that works ! Now the questions are:
why ? Is this normal expected behaviour ? What's the difference between hdmi_mode 81/86 and this custom mode ? any plans on changing this default behaviour ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@LennartHennigs THANKS ! Can confirm that works ! Now the questions are:
- why ?
- Is this normal expected behaviour ?
- What's the difference between hdmi_mode 81/86 and this custom mode ?
- any plans on changing this default behaviour ?
The issue is that Pi 4 appears to not implement DMT mode 86 correctly. Earlier models of Pi did.
Please remember that the Pi4 has completely replaced the HDMI, HVS, and Pixel valve blocks. Where issues occur we will investigate, but have to set priorities.
With an HDMI analyser it does appear that the Pi4 is producing a horizontal back porch that is 2 pixels longer than expected in 1366x768 mode - 66 pixels instead of 64. This may be related to the tweak from timg236 which has to increase the active pixels by 2 (to 1368). I have a change that makes the HDMI analyser report numbers that match the requested mode, and it still works with the PiTop Ceed that was the original troublesome display.
I'll push it for merge, and it should be in the next rpi-update.
Where issues occur we will investigate, but have to set priorities.
I'm aware of that - apologies if I suggested otherwise. I'm aware I sound a bit pushy at times.
Please remember that the Pi4 has completely replaced the HDMI, HVS, and Pixel valve blocks. Where issues occur we will investigate, but have to set priorities.
With an HDMI analyser it does appear that the Pi4 is producing a horizontal back porch that is 2 pixels longer than expected in 1366x768 mode - 66 pixels instead of 64. This may be related to the tweak from timg236 which has to increase the active pixels by 2 (to 1368). I have a change that makes the HDMI analyser report numbers that match the requested mode, and it still works with the PiTop Ceed that was the original troublesome display.
I'll push it for merge, and it should be in the next rpi-update.
Does the output of the Pi 4 now exactly match the output of previous Pi's for this video mode?
I'll push it for merge, and it should be in the next rpi-update.
Spoken too soon. I was looping the signal through the analyser, and hadn't noticed that it was converting from HDMI to DVI on the way through. Directly connected the PiTop CEED is still unhappy. Investigating further....
It seems I have a substandard Pi which this PiTop CEED doesn't like, but all my other monitors and the analyser are happy. Swapped to a new Pi and all is happy - what a way to waste an afternoon. It is a pre-production board, therefore please don't take this comment as an indication that there is a general fault.
With the Atrix EDID, according to the HDMI analyser the output is identical between the Pi3 and 4, and matches DMT mode 86.
Including the PiTop CEED into this issue was our mistake. It has a custom timing advertised in the EDID, and that is what is awkward. Using it there is a slight difference between the Pi3 & 4 as the detailed timings are calling for an odd number of pixels
"1366x768" 60 70120 1366 1414 1446 1485 768 771 777 787 0x48 0x9
"1366x768" 48 60000 1366 1414 1446 1506 768 771 777 830 0x40 0x9
The Pi4 hardware works on two pixels per clock, so producing an odd number of pixels isn't easy. The analyser reports
70121 60 1368 1416 1448 1484 768 771 777 787
but the PiTop is happy with that.
Whilst I don't have a Atrix lapdock, I trust the analyser enough to call that a solution. I'll now push the changes.
With the Atrix EDID, according to the HDMI analyser the output is identical between the Pi3 and 4, and matches DMT mode 86.
That's what I was getting at - a comparison with a "known good" setup.
Whilst I don't have a Atrix lapdock, I trust the analyser enough to call that a solution. I'll now push the changes.
Agreed - thanks 😁
Let me know when and how to test ! :)
I tried using rpi-update 20140705 ( this seems to be the ver available in the repos ) to update to 87843c15bb3236ec394c7e7fbc74dba5548d1456 ... Still no luck :)
The latest rpi-update release has the changes in it. I believe vcgencmd version should return a49274f4de9406db851802c64ea2e8a13df7e0d3
According to our HDMI analyser the timings now exactly match between the Pi3 and Pi4 when using the EDID you provided. If you're still not getting even the rainbow screen then I'm running out of ideas.
Same, no luck.
Tried with an empty /boot/config.txt and hdmi_group=2 hdmi_mode=87
Aug 1 2019 15:14:50
Copyright (c) 2012 Broadcom
version a49274f4de9406db851802c64ea2e8a13df7e0d3 (clean) (release) (start)
One other info that I don't know if matters, when rebooting I see "Hdmi no signal" for a few seconds and then the screen turns on ( I think the backlight is on )... but nothing on the screen.
I wonder what "hdmi_cvt=1366 768 60" does different :| using that seems ok.
Any developments on bootloader changes regarding HDMI ? ( or even netboot )
What bootloader/HDMI issues are you talking about? HDMI is not generally a bootloader thing. Do you mean the firmware sometimes not working with some monitors? Have you sen this thread https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=248037
did you read the preceding conversation? and this thread https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=247149
I believe these are the same issue. IIRC bootloader processes /boot/config.txt ?
HDMI setup is done by the firmware, not the bootloader (although the bootloader does look at a subset of the config.txt file). Bootloader boots, loads firmware to GPU and runs it, firmware does its thing (quite a lot of thing), then starts up the kernel, passing some display parameters to it.