[Intel-gfx] [BUG] HDMI 12bpc causing occasional flickering and blanking

Ville Syrjälä ville.syrjala at linux.intel.com
Mon Feb 15 20:26:33 UTC 2016

On Mon, Feb 15, 2016 at 08:17:23PM +0100, Tore Anderson wrote:
> Hello,
> Since upgrading to the Fedora 4.3 kernel package, the picture on my the
> BenQ M2700 HD monitor I've got connected to my HP EliteBook Folio 9470m
> laptop began having issues. The monitor is connected with a DP+-to-HDMI
> cable (HDMI in the monitor end), and the resolution I'm using is
> 1920x1080.
> The symptoms are brief flickers of which looks like a thin horizontal
> line (or maybe more) overlaying the picture for a very brief period.
> This is ofte often (but not always) followed by the entire picture
> going completely black (kind of like when xscreensaver blanks the
> screen). Usually, the picture returns after maybe a second, but
> sometimes it remains off for several seconds before returning. It might
> also be that these blankings happen without a horizontal line flicker
> having occurred immediately before, thought it's hard to be certain
> because the flickers are very brief.
> The laptop's internal screen is not impacted, the picture there remains
> stable while the external screen is flickering/blanking (including if
> both screens are set up in xrandr to show the same output).
> Most of the time the flickers and blankings happens only occasionally,
> and be just a minor annoyance. However, some times it gets really bad,
> and the screen spends a majority of the time black - making it
> impossible to use the system. I have not determined anything that will
> with 100% certainty cause the symptoms to manifest themselves, but I do
> have a feeling that it is more likely to happen if the picture is
> mostly white/bright (e.g., when displaying a web browser window or an
> application such as gitk), and also after having resumed from suspend.
> But flickering/blanking certainly does happen if the screen showing
> mostly black xterms and without having suspended/resumed too.
> I bisected the problem, which resulted in the following verdict:
> 7a0baa6234468aa387f9b8a1a79dc2a4b4821f67 is the first bad commit
> commit 7a0baa6234468aa387f9b8a1a79dc2a4b4821f67
> Author: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Date:   Tue Jun 30 15:33:54 2015 +0300
>     Revert "drm/i915: Disable 12bpc hdmi for now"
>     HDMI 12bpc should be working fine now. Let it loose.
>     This reverts commit 5e3daaca09f5158eff9c92290faa1d2001ecc6e4.
>     v2: Rebased due to CHV/BXT port clock check improvemnts
>     Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
>     Reviewed-and-tested-by: Imre Deak <imre.deak at intel.com>
>     Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> I also confirmed that the problem is still present in drm-intel-nightly
> as of today (8ed1804). I'm currently running 8ed1804 + 7a0baa6 reverted
> and the symptoms are gone.
> I've uploaded a kernel logs with drm.debug=0xe here:
> http://filebin.net/r3nlwu09y2
> One file is from when running 8ed1804 (with some comments of when the symptoms
> occurred added by me), the other file is from right now (running
> 8ed1804 + 7a0baa6 reverted) - I've not yet experienced any issues since
> booting the system with this kernel.

Could you test the following hack while using a 1920x1080 mode with 148.5 MHz
dotclock, and see if there's any improvement?

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 4e1321b96522..ea24de873e14 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12842,6 +12842,11 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
+	if (pipe_config->base.adjusted_mode.clock == 148500) {
+		DRM_ERROR("adjusting dotclock\n");
+		pipe_config->base.adjusted_mode.clock = 148800;
+	}
 	pipe_config->cpu_transcoder =
 		(enum transcoder) to_intel_crtc(crtc)->pipe;
Ville Syrjälä
Intel OTC

More information about the Intel-gfx mailing list