popcornmix
commented
4 years ago Just to confirm, you tested with an empty config.txt (so not even dtoverlay=vc4-fkms-v3d) and it still failed on Pi4?
Open d3xt3r01 opened 4 years ago
popcornmix
commented
4 years ago Just to confirm, you tested with an empty config.txt (so not even dtoverlay=vc4-fkms-v3d) and it still failed on Pi4?
d3xt3r01
commented
4 years ago @popcornmix yes.
d3xt3r01
commented
4 years ago 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
timg236
commented
4 years ago 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
d3xt3r01
commented
4 years ago 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 !
6by9
commented
4 years ago 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.
d3xt3r01
commented
4 years ago 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...
LennartHennigs
commented
4 years ago 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 0and this is what I put in my /boot/config.txt
hdmi_group=2
hdmi_cvt=1366 768 60
hdmi_mode=87Hope this might be helpful...
d3xt3r01
commented
4 years ago @LennartHennigs THANKS ! Can confirm that works ! Now the questions are:
6by9
commented
4 years ago 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: driverIf 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, driverNote 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.
d3xt3r01
commented
4 years ago 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 !
ghost
commented
4 years ago 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.
LennartHennigs
commented
4 years ago 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 notifications@github.com:
@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.
ghost
commented
4 years ago @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.
6by9
commented
4 years ago 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.
ghost
commented
4 years ago 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.
ghost
commented
4 years ago 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?
6by9
commented
4 years ago 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....
6by9
commented
4 years ago 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 0x9The 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 787but 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.
ghost
commented
4 years ago 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 😁
d3xt3r01
commented
4 years ago 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 :)
6by9
commented
4 years ago 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.
d3xt3r01
commented
4 years ago 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.
d3xt3r01
commented
4 years ago I wonder what "hdmi_cvt=1366 768 60" does different :| using that seems ok.
mwrich4
commented
4 years ago Any developments on bootloader changes regarding HDMI ? ( or even netboot )
JamesH65
commented
4 years ago 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
mwrich4
commented
4 years ago 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 ?
JamesH65
commented
4 years ago 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.
mwrich4
commented
4 years ago Thank you for the response. I see that you are 'the' James, you've got a lot on your plate.
( not bootloader, perhaps somewhere here - start*.elf ? )
I've been trying to figure out when to retest my issue with the Atrix and 1366x768 mode. Only the RasPi 4 has this issue with that device. My previous Pis worked well.
JamesH65
commented
4 years ago We are a very small team, everyone has a lot on their plate!
start*.elf is the GPU firmware
You could try the beta firmware in the link posted above - that will read detailed timings correctly, and might help with the odd resolution which according to thread at top of topic is defined in the detailed section.
LennartHennigs
commented
4 years ago Not sure if this is helpful but after the update I was able to select the predefined resolution of 1360x768. The custom one did not work anymore (black screen) after the update. Used ssh and raspi-config to set it.
Am 10.09.2019 um 17:18 schrieb mwrich4 notifications@github.com:
Thank you for the response. I see that you are 'the' James, you've got a lot on your plate.
( not bootloader, perhaps somewhere here - start*.elf ? )
I've been trying to figure out when to retest my issue with the Atrix and 1366x768 mode. Only the RasPi 4 has this issue with that device. My previous Pis worked well.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
mwrich4
commented
4 years ago Ran 'rpi-update' just now on my latest card image. After a cold boot, the Rpi4 with my Atrix seems to be working as it did for previous RasPis. I'll update if I find this is not true. Thanks again for the response JamesH. I expect that eventually as the dust settles these fixes will be part of the regular distribution.
cheers
mwrich4
commented
4 years ago I was so happy to have something work, I forgot this was in my config.txt
[quote]
hdmi_group=2 hdmi_cvt=1366 768 60 hdmi_mode=87 [/quote]
When I commented out the 3 lines like a clean system, the HDMI lapdock screen was not detected. Unplugging the HDMI cable and replugging the cable did not give me a display either. Not even the backlight was triggered.
So, the issue still exists to some extent in the firmware boot. I see the 4 berries but not the rainbow.
cmarty
commented
4 years ago Same issue. Monitor ASUS VT168H. Native res. 1366x768. Old rpi 3 (Jessie) works with def.mode 81. On Rpi 4 (Buster) works only with custom res. hdmi_group=2 hdmi_cvt=1366 768 60 hdmi_mode=87 and tvservice -s reports state 0xa [HDMI DMT (88) RGB full 16:9], 1360x768 @ 60.00Hz, progressive
6by9
commented
4 years ago @cmarty That sounds like a dodgy EDID being advertised by your monitor.
The Pi4 and fkms driver rely on the EDID to be correct as they will adopt exactly the timings advertised. (The firmware used to munge the timings slightly to adopt one of the standard timings).
If you want any form of investigation then you need to post the raw EDID for analysis. (tvservice -d edid.bin to save it. Then use either base64 to encode it as text, or zip and attach the file to this issue).
It would also be interesting to know if this monitor works on any mainline Linux system. The EDID parsing code we're using now is provided by the mainline Linux kernel, therefore I'd expect the same result there too. Enabling the OpenGL driver in raspi-config on the Pi3 would be a reasonable test.
mwrich4
commented
4 years ago My LapDock monitor has worked with each RasPi board version and many linux variants UNTIL RasPi4. I think @cmarty is saying the same thing. In my case, I was referred here by Rasp.org and saw that @OP had apparently the same issue. He has posted EDID data dumps here and I have posted the same on the thread I started at rasp.org (see link above). When I say it worked, I mean with zero extra config changes.
cmarty
commented
4 years ago tested on the latest Rpi Buster image legacy on Rpi3: monitor works ok state 0xa [HDMI DMT (81) RGB full 16:9], 1366x768 @ 60.00Hz, progressive vc4-fkms-v3d on Rpi 3: monitor works ok state 0xa [HDMI CUSTOM RGB full 16:9], 1366x768 @ 60.00Hz, progressive vc4-kms-v3d on Rpi 3: monitor works ok state 0x120009 [HDMI DMT (81) RGB full 16:9], 1366x768 @ 60.00Hz, progressive legacy on Rpi4: monitor NOT working state 0xa [HDMI DMT (81) RGB full 16:9], 1366x768 @ 60.00Hz, progressive vc4-fkms-v3d on Rpi 4: monitor NOT working state 0xa [HDMI CUSTOM RGB full 16:9], 1366x768 @ 60.00Hz, progressive vc4-fkms-v3d on Rpi 4 with CUSTOM Mode (hdmi_cvt=1366 768 60) : monitor works OK state 0xa [HDMI DMT (87) RGB full 16:9], 1360x768 @ 60.00Hz, progressive edid_ASUS_VT168H.zip
alexose
commented
4 years ago Note that most HDMI cables won't work reliably with the Lapdock. This is because it has some eccentricities with how it handles HDMI (see: https://www.element14.com/community/community/raspberry-pi/blog/2012/09/27/raspberry-pi-lapdock-hdmi-cable-work-around ). TL;DR is that most HDMI cables don't actually include all 19 wires, which leads the Lapdock to think your device is disconnected.
My suggestion is to obtain a cable that includes all of the wires. I can personally vouch for the DIY HDMI cables from Adafruit. You'll need the following parts:
https://www.adafruit.com/product/3561 https://www.adafruit.com/product/3559 https://www.adafruit.com/product/3556 (or Mini or Standard depending on your Raspberry Pi model).
These parts are also available via eBay for cheaper, but they ship from China.
Unfortunately the PCB is somewhat wide, so you'll need a very slim micro USB cable to go with it. I used a dremel to shave down my cable so it would fit. You could also probably make your own cable from one of these connectors: https://www.adafruit.com/product/4023 .
(I'm cross-posting this response several places because getting to the bottom of this issue took me several days and at least $60 worth of cables and converters. Hoping that I save someone else the headache!)
LennartHennigs
commented
4 years ago Hi, I just used the latest version to plug with my lapdock and still encountered problems. (No, it's not the cable – this worked with a Pi4 install before).
I used a clean install, did an update & dist-upgrade and a reboot. Afterwards the default mode results in a blank screen (I guess that's 86). If I VNC in the desktop and change the resolution to a lower one, the lapdock display works – but 86 does not.
If I edit the /boot/config.txt and enter the custom values mentioned by @cmarty the display works:
hdmi_group=2
hdmi_cvt=1366 768 60
hdmi_mode=87In a previous buster version the mode 86 did work. Now it does not anymore (again).
zacnelson
commented
4 years ago Confirmed I am seeing the same issue on a Pi 4B with the ASUS VT168H monitor (1366 x 768) - just a blank screen without hacking into custom resolution solutions (which isn't viable for a solution that needs to support various monitors on the fly).
I have 2 of the same monitor, 1 plugged into a 4B and 1 plugged into a 3B+. Attached are the EDID's of both.
pi4b_edid.zip - display is not working
pi3bplus_edid.zip - display is working without custom settings
JamesH65
commented
4 years ago That is THE problem resolution on the Pi4. Its the only resoltuoin in the entire HDMI/DVI standard that uses odd numbers in its timing, and that causes issues on the Pi4 due to using 2 pixels/clock. We are currently waiting for information form the SoC supplier as our mitigations doesn;t work, and we think it shoulld.
Xadas123
commented
4 years ago Hi have the same issue on a Pi 4B with the ASUS VT168H monitor hdmi_group=2 hdmi_cvt=1366 768 60 hdmi_mode=87 does not help Are there any news on the progress to solve that issue ?
JamesH65
commented
4 years ago OK, so the HW simply cannot support that specific resolution, so we are looking in to how to mitigate it, by slightly changing the resolution to 1360 perhaps, and letting the screen do some scaling, or perhaps just forcing to a 1080p mode. Still being investigated for the best approach to take.
vmincev
commented
3 years ago Any update on possible solution?
JamesH65
commented
3 years ago Have you tried the latest software? There have been some changes in this area that may help.
vmincev
commented
3 years ago On Motorola Atrix lapdock, with Ubuntu Desktop 20.10. defaults are not working. Tested defaults on Samsung TV and there is 4k 30Hz output - no glitches, managed to play HD youtube video.
So, I've tried adding to config.txt:
hdmi_group=2
hdmi_cvt=1366 768 60
hdmi_mode=87which produced 1360x768 output, but it is unstable. Monitor keeps blanking randomly. I've also managed to expose HDMI port from lapdock and plug Raspi 4 directly (so cable was eliminated as issue source). I've tried hdmi_safe=1, no help. Tried different hdmi_mode, and modifying hdmi_cvt but without results. Any hints?
6by9
commented
3 years ago We don't directly support Ubuntu. Does it work with Raspberry Pi OS?
If you've added the hdmi_group, hdmi_cvt, hdmi_mode lines to config.txt, what does xrandr report as the available resolutions?
Output from uname -a and vcgencmd version please.
vmincev
commented
3 years ago Hi @6by9 - sorry for misusing this thread, my assumption was that Ubuntu uses same firmware.
To make sure I'm on topic now, just installed the latest Raspberry Pi OS (Release date: December 2nd 2020). Again, had to add following (without it I had no output to lapdock monitor):
hdmi_group=2
hdmi_cvt=1366 768 60
hdmi_mode=87Note: random blinking still happens. Also, I can note some green pixels showing randomly too when display works.
xrandr output:
Screen 0: minimum 320 x 200, current 1360 x 768, maximum 7680 x 7680
HDMI-1 connected primary 1360x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
FIXED_MODE 59.80*+uname -a output:
Linux nano 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
vcgencmd version output:
Nov 30 2020 22:12:08
Copyright (c) 2012 Broadcom
version ab1181cc0cb6df52bfae3b1d3fef0ce7c325166c (clean) (release) (start)
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
Ran: apt install raspberrypi-ui-mods On pi4 I used the hdmi port 0 near the usb-c connector
Both report:
Works just fine by default
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.
So I tried messing with /boot/config.txt
This, works, even if it's 640x480, at least it works.
So I noticed that on pi3aplus the state is set to DMT(86).... I tried forcing that too, doesn't work either
I also tried with an empty config.txt file too.