dtoverlay=vc4-fkms-v3d causes blank screen when enabling 4K (3840x2160) @60hz
#1392
Comments
MartenBE
changed the title
dtoverlay=vc4-fkms-v3d causes blank screendtoverlay=vc4-fkms-v3d causes blank screen when enabling 4K@60hz
|
Your timings of are not the standard timings for 4k60. are the standard ones. You also have a weird timing for 4k30 the normal timing would be Seeing as the mode still comes out as 3840x2160@60 I can't think of an easy way to make it select the alternative timing - most modes are selected by width, height, and refresh rate only. Both of the odd timings come from the detailed timings portion of the EDID, so the monitor is claiming that these modes are supported there. The full decode is |
|
I'm afraid this is a little bit above my understanding. I've found the following in the manual:
Is there anything I can do? Is it possible to spoof the EDID? |
|
Experiencing what I believe to be the same problem with a Lenovo L28u-30 4k monitor. Strangely enough, my raspi-config has never shown the "(7) Advanced Options –> (A9) Pi 4 Video Output" menu item shown here https://blog.codetitans.pl/post/howto-enable-4k60hz-on-raspberry-pi-4/ and elsewhere. True for a fresh OS install as well. |
|
Same problem here with LG 27UK650-W (27", 4K UHD) monitor, that works perfectly fine with all my other computers including Mac mini, Windows Dell Laptop and Lenovo PC running both Windows and Linux, but unfortunately does not work with my brand new Raspberry Pi 400 when enabling 4kp60 via Commenting out Here's my EDID: My timings for This is really a bummer since Pi4 and Pi400 are advertised as 4K capable, but 4kp60 does not work as advertised with such popular 4k monitor as mine. |
|
Same here with an LG 27UL850 and a Pi 4 8GB model. Was trying various settings, like HDMI mode force, with HDMI Group 1, Mode 97, and obviously 4kp60 enabled. With 4kp60 I'd always get a blank screen on one HDMI port, and a 1080p screen on the other port. Disabling DT overlay sorted the problem immediately. Attached is my edid output for the monitor. |
Same here. But I wouldn't call disabling DT overlay a solution since it disables 3D acceleration, which cripples the graphics performance. We need a real solution. FYI this problem was described also in two threads on the forums: @itoral @anholt Humbly asking for your help or if you know someone who can help with this apparently v3d related issue. |
|
If this is an FKMS issue it is not something I can help with, but I'll try to ping someone at Rpi to look into it. By the way, does the issue persist using the real KMS driver? |
|
When using KMS I cannot even see UHD 60Hz modes in With FKMS But if I try to switch to @popcornmix Sorry to ping you here, but you maybe have an idea who could help with this issue? |
|
Patches for 4k60 in vc4-kms-v3d are still to be merged - they're on dri-devel at present and should be merged soon. Forcing your EDID via config.txt has come up fine on my Dell 4k monitor, and That it works without vc4-fkms-v3d is odd. The only real difference is that in loading vc4-fkms-v3d is that it will force a mode change to the DRM selected timings rather than the ones chosen by the firmware. |
This is exactly what this thread and my and others reports are about. If we disable
Yes, when I disable Here's Also, comparing timings reported by X when https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#Structure,_version_1.4
|
Actually in this case, no. You've hijacked a thread where someone had a totally non-standard 4k60 mode advertised by their monitor.
It sounds like something in the setup isn't re-enabling scrambling correctly. HDMI2.0 requires this for any mode with a pixel clock above 340MHz, and it also alters the HDMI TMDS clock rate as well. What firmware and kernel versions are you running? Part of the HDMI handling was reworked recently. After March 10th 2021 should have that. |
I am sorry to hear that. If I did it it was unintentional. Still there were other reports at https://www.raspberrypi.org/forums/viewtopic.php?t=255563 linked to this issue, and there was also @vatbrain reporting same problem before I did, and then @rlkennedyreid after my post. So this place looked like most relevant place to post to, especially when you read the subject.
I presume I'd need try pull Just double checking because I can read in
|
|
Yes, rpi-update pulls in the absolute latest firmware and kernels. Any investigations will always be on the absolute latest firmware & kernel. |
Understood. I updated to the latest firmware & kernel and still no luck with 4k@60Hz with |
|
Without vc4-fkms-v3d, disconnect and fully power cycle the monitor (ie pull the mains cable), and then reconnect to the Pi. Does it recover? |
Agreed, @nanoant. 'Solved' was bad wording here - I have just decided to use 30Hz until there's a fix. Disabling 3D acceleration is certainly no fix - absolutely cripples almost anything you want to do, especially in-browser. |
Yes it does. I pulled HDMI cable out of Pi400, turned off the monitor, pulled the power cable, put the cable back, powered the monitor, plugged the HDMI cable back and I get the Pi400 screen. |
@rlkennedyreid Yeah, indeed. If you read https://www.raspberrypi.org/products/raspberry-pi-4-model-b/ you can get excited that pi4 can drive two 4k displays, but then if you read details you see it can drive only one 4k display at 60Hz with |
|
I've been following this thread for a while, hoping that it would see some activity. Given how quickly multiple people chimed in, I suspect there may be a few others in a similar boat. In case it helps any, here is another edid (from a BenQ PD3200U monitor), for which I see the exact same symptoms (boots either on 3840x2160-30 with vc4-fkms-v3d, or on 3840x2160-60 disabling vc4-fkms-v3d, but not 3840x2160-60 with vc4-fkms-v3d). To add a bit more detail, when trying to boot on 4k60 with vc4-fkms-v3d, I see the terminal-style initial boot screen (the one with the Raspberry Pi logo), followed by the color wheel screen, and then the HDMI signal cuts out. |
|
folks, it would be wise to be precise about which video resolution you are talking about , as people often talk about 3840x2160-60 and 4096x2160-60 as 4k60. I've found the latest fkms to work with 3840x2160-60 pretty well, but to crash badly with 4096x2160-60 (raspberrypi/linux#4271). not trying to hijack the thread, just pointing out the ambiguity. |
|
Yes, good point. I was referring to 3840x2160-60 which does not work on Pi 4B for me on my BenQ PD3200U monitor. (The monitor works fine on this setting with other computers.) |
|
Yes, my problem is also about 4096x2160 aka 4K DCI on other hand is not that popular and related to cinema industry. Therefore I'd say ops or @MartenBE could add |
|
why not use the actual resolution? seems a lot clearer than an arbitrary TLA. |
MartenBE
changed the title
dtoverlay=vc4-fkms-v3d causes blank screen when enabling 4K@60hzdtoverlay=vc4-fkms-v3d causes blank screen when enabling 4K (3840x2160) @60hz
|
I have updated the title. The screen in my situation has the 3840*2160 resolution. I have sold my Pi shortly after the bug report, so I cannot assist any further anymore. |
@MartenBE, out of curiosity, was the 4K support the reason you've sold your Pi?
@6by9, since you mention SCDC which seems to be DDC extension, I also tested if DDC works correctly with Is this SCDC communication done by the firmware or linux driver? Is it something that is open-source? Because if it is I am willing to do my best and try to work on the issue.
I understand KMS is complete rewrite that does no rely on DisplaymanX. Does it mean HDMI 4kp60 support is also rewritten and independent from the firmware?
@itoral Current KMS build does not include 4kp60, but as @6by9 wrote above it looks there are some patches for that on dri-devel that will be merged soon. |
Yes. Control of hdmi (and hvs) is purely from arm code and doesn't make use of the firmware drivers. |
|
@popcornmix I have pulled latest kernel build that seems to contain raspberrypi/linux#4302 introducing 4k @ 60Hz support for KMS driver by @mripard I confirm that now I can see new Unfortunately switching to 60Hz produces "no signal detected" on my monitor, similar to what has been already observed with FKMS. The only case when 4k @ 60Hz works is when no FKMS or KMS are enabled. What shall we do now? |
|
have you tried overclocking the pi, as in the fkms bug report? |
If you mean Anyway I had impression that I am really trying to give Pi400 a chance, but I am so far really disappointed. Not to mention horrible tearing when dragging windows or web content while running |
|
Please have some patience. 4k60 support has just been merged but there are likely to be some rough edges still, and it is being worked on. Setting core_freq/core_freq_min to 600 is required for 4096x2160. It shouldn't be required for 3840x2160. You've just said you can't get 3840x2160@60 working on full KMS. FKMS has known issues with vsync events. Wait for the rough edges to be sorted with full KMS - it shouldn't be long. |
|
what sort of bug reports will be useful for the new kms release?
…On Wed, Apr 21, 2021 at 12:31 PM 6by9 ***@***.***> wrote:
Please have some patience. 4k60 support has just been merged but there are
likely to be some rough edges still, and it is being worked on.
Setting core_freq/core_freq_min to 600 is required for 4096x2160. It
shouldn't be required for 3840x2160.
You've just said you can't get ***@***.*** working on full KMS. FKMS has
known issues with vsync events. Wait for the rough edges to be sorted with
full KMS - it shouldn't be long.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1392 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANPGZ5JPJMD62CEAWUVTN7TTJ4R2HANCNFSM4NGY5UOQ>
.
|
|
quick update: 3840x and 4096x are working with kms. vsync (as measured by consistency of input lag) looks right. Will do more testing but this is looking like a great step forward. tvservice needs an update to at least warn that it's not supported under kms as the error message ([E] No device present) isn't very helpful. |
What makes me bit worried is that Rpi4 was released June 2019, so almost 2 years ago and it was advertised as 4K capable including decoding H.265 at 4K and 60Hz. I understand that KMS is completely new driver and 4K @ 60Hz support (i.e. scrambling) has been just added/merged. But still I would like to know how this issue here is supposed to be resolved? Are the Rpi developers working on KMS or/and FKMS aware of the problem? Do they have or need an access to the monitors that have the problem? |
|
switching back to normal cpu clock, I'm not having as much success, even with 3840x, with it working for the first 10 or so seconds and then failing with [ 598.238501] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] ERROR [CRTC:76:crtc-3] flip_done timed out too soon to be sure if this is just an intermittent issue or actually tied to the clock. |
|
^ postscript: it's definitely tied to the cpu clock. with core_freq/core_freq_min 600, 3840x works reliably (entered and exited video mode 10 times in a row with no problems), without overclock, it fails about half the time, either immediately, or after a few seconds. Does this need a new issue opened? same test with 4096x works fine (entering and exiting 10x with core_freq/core_freq_min 600). |
|
@alanbork this issue is about the fkms driver. |
|
@popcornmix If we focus only on FKMS and 3840x2160 @ 60Hz, is there anything else we can do to move this forward? I think most important information is that 60Hz works when neither FKMS or KMS are enabled. Can you please explain in such case which driver is driving HDMI at 60Hz? Because if it works there I think it should be possible to make FKMS and KMS work with our monitors. |
|
Both fkms and "no kms" use the same firmware side code for setting hdmi mode. |
|
@popcornmix Thanks for suggesting checking With no overlay (no FKMS or KMS) I get: With FKMS overlay enabled my X starts in 30 Hz (I set it once in Screen Configuration, now it seems to persist) and I get: What is suspicious that the mode is When I change to 60Hz with xrandr (or Screen Configuration) and get blank screen (no HDMI signal according to my monitor):
And there goes interesting part, if I use NOTE: I have already tried So any ideas why FKMS driver is selecting some Btw. here's output of |
|
The firmware will always choose one of the standard CEA or DMT modes. It does look at the detailed timings in the EDID, but only to see which standard mode most closely matches. tvservice will therefore always report one of the standard modes. KMS (whether vc4-kms-v3d or vc4-fkms-v3d) parses the full EDID and creates a full mode definition for each and every mode described therein. It passes that full timing to the driver to select a mode, therefore there has to be different handling within the firmware to be able to accept that, and that is why tvservice shows CUSTOM - it's using the FKMS specific entry. So the real question is why KMS is seemingly coming up with a mode definition that is apparently incompatible with your monitor.
KMS will almost certainly go for the former. The firmware will go for the latter. I'll try to remember in the morning to hook that EDID up with our HDMI analyser to confirm that the Pi is putting out the mode described, but if so it largely means that your monitor's EDID is incorrect. Edited to remove erroneous information |
|
And this is why hijacking issues is a bad idea - I'd actually picked up MartenBE's EDID with the non-standard 4k60 mode which is where this thread started. Last night's post updated to remove the erroneous information. Tested with your EDID on the analyser on a CM4. Syncs fine, and the analyser reports VIC 97 from the AVI frame, so DRM is ending up with the same mode. What you're doing with your tvservice and xrandr commands is just reselecting effectively the same mode. |
Yes it does. |
|
OK, so something on your particular system seems to not like the mode switching. The timing on that is involved, but is robust on most systems. I can't answer at the moment as to whether your system is an edge case, or if something else is involved. |
|
It seems the problem lies in timing according to EDID provided by monitor, because CEA 97 seems to be robust for me and others reporting here and on the forums, since 60 Hz works for us when FKMS/KMS are not enabled. An option forcing CEA timings for both FKMS (and KMS for future) would be good workaround for all of the users here I believe. Or am I demanding too much? Also I don't understand how my system can be an edge case if my LG 27UK650-W is extremely popular model from well known brand producing computer screens. Moreover others are having same problem with other brands such as AOC, Lenovo or Benq. So this is not an isolated case. |
|
I've asked in the past for a way to add CEA modes (some or even the entire set) to the list offered by DRM/KMS via config.txt, but that's been shot down. however there's nothing preventing you from generating a modeline that exactly matches cea 97 and putting that in your xorg file or whatever. |
it's just not an option architecturally. config.txt is parsed by firmware and not seen by kernel. The kms driver controls hdmi hardware directly without firmware support. Theoretically it could be supported for fkms, but as that is just a stepping stone to kms, introducing new ways of controlling behaviour that will stop working in the future would be undesirable. Custom modelines should be added using standard linux mechanisms (e.g. xorg.conf or provide a custom edid). |
@6by9 I just did Which is exactly CEA 97 mode.
Okay, so it seems that So since I am in both cases setting exactly the same mode, proposed solution to "force" CEA would have absolutely no effect in my case. Also using manual In the end it looks like some timing problem, where firmware setting the mode gets it right, but fKMS not. Not to mention KMS does not either with my monitor. I think I have lost my patience and I am going to sell my Pi 400 because on top of this 4K 60Hz issue, Pi4 exhibits rather horrible tearing which seems not be fixed in the latest KMS driver, and the bug report about that raspberrypi/linux#3641 was closed and locked for further comments by Pi's devs despite being unresolved, calling it "cosmetic issue". |
As I'd responded:
Your EDID does indeed have describe CEA mode 97.
Correct, and that is the expected behaviour.
We've just had a discovery on one monitor that it isn't registering the request to enable scrambling and the high tmds clock ratio which is required for HDMI pixel clocks over 340MHz. Miss that and the monitor won't be able to decode it. It's down to how tolerant the monitor of the HDMI sequencing. |
Describe the bug
When hooking up a Rasberry Pi 4B to a AOC U3277FWQ monitor with 4K@60hz enabled causes a black screen on boot. The problems go away when the
dtoverlay=vc4-fkms-v3dis removed from the boot config. This thread describes the problem very accurately: https://www.raspberrypi.org/forums/viewtopic.php?t=255563To reproduce
This behavior has been confirmed by two separate cases as described in https://www.raspberrypi.org/forums/viewtopic.php?t=255563
Expected behaviour
To correctly boot the raspberry and display the screen
Actual behaviour
The screen is blank
System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:
Raspinfo output: https://pastebin.com/SbJ04KSJ
cat /etc/rpi-issue)?vcgencmd version)?uname -a)?Logs
Base64 of the EDID:
Full dmesg log can be seen at https://pastebin.com/SbJ04KSJ (bottom). At the bottom I noticed the following errors:
Xorg.0.log:
Additional context
When
hdmi_ignore_edid=0xa5000080is set as described in https://www.raspberrypi.org/documentation/configuration/config-txt/video.md, the raspberry pi boots fine in 1920x1080 on the monitor in question.The text was updated successfully, but these errors were encountered: