Created attachment 134928 [details] dmesg When I choose 3180x2160_60Hz my TV starts to blink/flicker black. The black screen shows about 1-2sec. Unfortunately at the time the flicker happens, there is no indication in dmesg. uname -a: Linux lrplayer 4.14.0-rc4 #1 SMP Tue Oct 10 21:53:48 CEST 2017 x86_64 GNU/Linux Linux Distribution: LibreELEC Machine: Intel NUC7i5BNK
I tried to attach the video that shows the issue, but it failed. So here is my dropbox link: https://www.dropbox.com/s/ekb1qt6ncfxdn36/20171019_214555.mp4?dl=0
I did some investigation and it seems to be a bandwith issue. I've rebased following patch series on current (todays) drm-tip: https://patchwork.freedesktop.org/series/28536 You can find the branch here: (I applied the patches with std patch, so I lost author information, I added the original author with the signed-off tag, not sure if this is the right thing to do, it's only for discussion anyway) https://github.com/a1rwulf/drm-tip/commits/yuv420 It didn't work out and my system never switched to 4:2:0 until I tried this commit: https://github.com/a1rwulf/drm-tip/commit/45998e4d79aa20a31594143a3a053279fa52ab87 According to my dmesg output something seems wrong, though (yuv420_dmesg.log). But this fixes the blackscreen flickering. I'd really like to see progress with this yuv 4:2:0 mode as it seems to fix a big issue for many Intel NUC users that want to use it as a HTPC and have a GUI running in 4k@60.
Created attachment 135379 [details] YUV 4:2:0 dmesg
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
This is still relevant. I've tested with drm-tip recently and it is still the case.
HI, so you are expecting series of: https://patchwork.freedesktop.org/series/36068/ to land to drm-tip?
At least this seems to fix the black screen flickering for me (tried to explain it in my early comments on this issue). However I don't know if anyone can answer why 4k@60 doesn't work with YUV 4:4:4.
(In reply to Wolfgang Haupt from comment #7) > At least this seems to fix the black screen flickering for me (tried to > explain it in my early comments on this issue). > However I don't know if anyone can answer why 4k@60 doesn't work with YUV > 4:4:4. The usual suspect is the cable, connectors, dongles etc.
Even though this series provides the infrastructure for YCBCR444, there is no interface for user (like a drm_property) to select its preference of YCBCR444 over RGB. We had tried to add this property during HDMI 2.0 enabling but we realized that it was not mapping to the long term goal of HDR pipeline support. So, to summarize, modeset picks RGB output by default. In case of LSPCON based YCBCR 4:2:0 outputs, we run pipe at YCBCR 4:4:4 config, and then LSPCON scales it down to 4:2:0 sub-sampling, and that's where we need the infrastructure. So in order to support YCBCR 4:4:4 outputs, we need a drm_property which picks user's preference between RGB/YCBCR444. - Shashank
Sorry maybe I'm not aware of all the technical aspects, if you say normal behaviour is RGB444, then this means my problem is actually black screen flickering with RGB444 as well.
Please note that I tried cables of 3 different manufacturers and I don't use any dongles. My NUC is directly connected to the TV and there's several people that have this issue with kaby lake NUC's.
What is your version of LSPCON FW? Can you provide: cat /sys/kernel/debug/dri/0/i915_display_info
I'm on lspcon 1.72
Created attachment 139137 [details] displayinfo
Jani, Shashank, Ville. Any help here?
Would it be possible to share the monitor's edid in text format ? - Shashank
Created attachment 139400 [details] edid-decode
(In reply to Wolfgang Haupt from comment #17) > Created attachment 139400 [details] > edid-decode Always raw binary/hex please. We don't want to be at the mercy of the decode tool as those may have bugs or missing features.
Created attachment 139409 [details] EDID binary
Created attachment 139410 [details] lg hex
Ville, Shashank, could you have a look at Wolfgang's EDID?
Hi Wolfgang Haupt, Can you please update the MCA fw to 1.75, you are still using the older version? Since YCBCR 420/444 series is recently merged https://patchwork.freedesktop.org/series/50897/ this issue shouldn't be there. Even if the issue persists with latest kernel and after updating the fw, we will take next steps.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.