|Summary:||Black Screen Flickering|
|Product:||DRI||Reporter:||Wolfgang Haupt <haupt.wolfgang>|
|Component:||DRM/Intel||Assignee:||Swati Sharma <swati2.sharma>|
|Status:||RESOLVED MOVED||QA Contact:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|Priority:||medium||CC:||fritsch, intel-gfx-bugs, jani.nikula, shashank.sharma, suresh.kumar.kurmi, ville.syrjala|
|i915 platform:||KBL||i915 features:||display/LSPCON|
Description Wolfgang Haupt 2017-10-19 20:03:12 UTC
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
Comment 1 Wolfgang Haupt 2017-10-19 20:06:02 UTC
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
Comment 2 Wolfgang Haupt 2017-11-10 19:19:07 UTC
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.
Comment 3 Wolfgang Haupt 2017-11-10 19:19:41 UTC
Created attachment 135379 [details] YUV 4:2:0 dmesg
Comment 4 Jani Saarinen 2018-03-29 07:11:43 UTC
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.
Comment 5 Wolfgang Haupt 2018-04-04 14:32:12 UTC
This is still relevant. I've tested with drm-tip recently and it is still the case.
Comment 6 Jani Saarinen 2018-04-04 15:37:50 UTC
HI, so you are expecting series of: https://patchwork.freedesktop.org/series/36068/ to land to drm-tip?
Comment 7 Wolfgang Haupt 2018-04-04 15:49:28 UTC
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.
Comment 8 Ville Syrjala 2018-04-04 16:02:37 UTC
(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.
Comment 9 email@example.com 2018-04-04 16:03:45 UTC
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
Comment 10 Wolfgang Haupt 2018-04-04 16:07:09 UTC
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.
Comment 11 Wolfgang Haupt 2018-04-04 16:09:06 UTC
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.
Comment 12 Jani Saarinen 2018-04-25 08:18:52 UTC
What is your version of LSPCON FW? Can you provide: cat /sys/kernel/debug/dri/0/i915_display_info
Comment 13 Wolfgang Haupt 2018-04-26 15:13:03 UTC
I'm on lspcon 1.72
Comment 15 Jani Saarinen 2018-05-04 09:54:15 UTC
Jani, Shashank, Ville. Any help here?
Comment 16 firstname.lastname@example.org 2018-05-04 17:12:59 UTC
Would it be possible to share the monitor's edid in text format ? - Shashank
Comment 18 Ville Syrjala 2018-05-07 12:25:42 UTC
(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.
Comment 21 Martin Peres 2018-07-17 14:10:43 UTC
Ville, Shashank, could you have a look at Wolfgang's EDID?
Comment 22 Swati Sharma 2018-12-04 14:20:42 UTC
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.
Comment 23 Lakshmi 2019-02-20 06:51:45 UTC
No response for more than two months, priority of this bug is changed to medium. Wolfgang, are you able to reproduce the issue with latest FW 1.75?
Comment 24 Wolfgang Haupt 2019-02-20 08:53:38 UTC
(In reply to Lakshmi from comment #23) > No response for more than two months, priority of this bug is changed to > medium. > > Wolfgang, are you able to reproduce the issue with latest FW 1.75? Hey Lakshmi, Sorry for the silence, it's a pita for me to actually even the the latest FW 1.75 on my box, cause there's afaik no way to flash it without trashing the linux system, install windows and install my distro again. I have a super busy time the next 2-3 weeks, so I'm not exactly sure if I can retest during this timeframe. I'll come back to you asap with my results.
Comment 25 Wolfgang Haupt 2019-03-16 13:06:10 UTC
Hi, I've installed windows on my nucs now to do the update. But in the downloadcenter the latest fw for lspcon is 1.72. Where can I find 1.75?
Comment 26 Wolfgang Haupt 2019-03-25 14:19:45 UTC
Ping. Can anyone tell me more about fw 1.75?
Comment 27 Swati Sharma 2019-04-03 12:44:33 UTC
(In reply to Wolfgang Haupt from comment #26) > Ping. > Can anyone tell me more about fw 1.75? Hi, We have got the official release of the FW, wait for a day or two it will be uploaded on downloadcenter
Comment 28 Wolfgang Haupt 2019-04-15 09:47:22 UTC
It's been a few days now. In the downloadcenter 1.72 is still latest.
Comment 29 Swati Sharma 2019-04-17 14:17:47 UTC
(In reply to Wolfgang Haupt from comment #28) > It's been a few days now. > In the downloadcenter 1.72 is still latest. ODMs are engaged to update LSPCON firmware images for the NUC devises and devises are doing testing. Once its done, downloadcenter will be updated with FW 1.76
Comment 30 Frederik O. 2019-10-25 08:11:55 UTC
Is there any news on MCA FW 1.76? (or maybe 1.75.01) The downloadcenter only has 1.72 and 1.71. Currently I have 1.72 installed and can still reproduce this: https://bugs.freedesktop.org/show_bug.cgi?id=108473 Posting here, because it has concrete discussion on the release. Thanks!
Comment 31 Lakshmi 2019-10-29 14:11:52 UTC
@Suresh, any updates here?
Comment 32 Swati Sharma 2019-11-09 23:30:56 UTC
(In reply to Frederik O. from comment #30) > Is there any news on MCA FW 1.76? (or maybe 1.75.01) > The downloadcenter only has 1.72 and 1.71. > > Currently I have 1.72 installed and can still reproduce this: > https://bugs.freedesktop.org/show_bug.cgi?id=108473 > > Posting here, because it has concrete discussion on the release. > Thanks! Hi Frederik, Intel download center for NUC devices has FW V 1.77 available, along with the flashing utility. -FW for Coffee Lake based NUC: https://downloadcenter.intel.com/download/29092/HDMI-Firmware-Update-Tool-for-NUC8i3BE-NUC8i5BE-NUC8i7BE -FW for our Kaby Lake NUC: https://downloadcenter.intel.com/download/29162/HDMI-Firmware-Update-Tool-for-NUC7i3BN-NUC7i5BN-NUC7i7BN?product=95067 Can you please update your FW and let us know whether issue still exists?
Comment 33 Swati Sharma 2019-11-09 23:31:51 UTC
(In reply to Wolfgang Haupt from comment #28) > It's been a few days now. > In the downloadcenter 1.72 is still latest. Hi Wolfgang, Intel download center for NUC devices has FW V 1.77 available, along with the flashing utility. -FW for Coffee Lake based NUC: https://downloadcenter.intel.com/download/29092/HDMI-Firmware-Update-Tool-for-NUC8i3BE-NUC8i5BE-NUC8i7BE -FW for our Kaby Lake NUC: https://downloadcenter.intel.com/download/29162/HDMI-Firmware-Update-Tool-for-NUC7i3BN-NUC7i5BN-NUC7i7BN?product=95067 Can you please update your FW and let us know whether issue still exists?
Comment 34 Frederik O. 2019-11-12 12:19:44 UTC
Hi, I am sorry, I did not check the relevant generation. I only own a Apollo Lake board. Is the firmware still applicable?
Comment 35 Swati Sharma 2019-11-12 18:35:26 UTC
FW for the Apollo Lake NUC: Yet to be released You have to wait a little more :) Will update shortly once released.
Comment 36 Martin Peres 2019-11-29 17:30:42 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/59.