Bug 110047 - Bad 4kp60 modeset over HDMI
Summary: Bad 4kp60 modeset over HDMI
Status: CLOSED WONTFIX
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-14 00:31 UTC by Freddie Witherden
Modified: 2019-06-26 11:02 UTC (History)
2 users (show)

See Also:
i915 platform: SKL
i915 features:


Attachments
DRM log (878.10 KB, text/x-maxima-out)
2019-03-14 12:35 UTC, Freddie Witherden
no flags Details
DRM log from good kernel (776.34 KB, text/x-maxima-out)
2019-03-14 13:57 UTC, Freddie Witherden
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Freddie Witherden 2019-03-14 00:31:04 UTC
I have an Intel NUC NUC6i7KYK and an AOC U3277PWQU monitor.  Under Linux 4.14.13 both DisplayPort and HDMI outputs work as expected.  However, after updating to Linux 5.0.1 there appears to be a regression in how the mode is set over HDMI.

During the boot process the BIOS sets the resolution to 3840*2160 which carries over the GRUB.  After the kernel loads the resolution is temporarily reduced to ~VGA until mode setting kicks in and sets the resolution back to 3840*2160.  Using HDMI on Linux 5.0.1 this mode set appears to go awry.  Although the resolution is correct (4kp60) the console background (which should be black) turns blue and the text (which should be white) develops colour fringes.  The issue persists even after the desktop loads (which takes on an almost greyscale appearance). 

As such it appears as if there has been a regression in the kernel mode driver somewhere between 4.4.13 and 5.0.1.

I appreciate that this is a somewhat vague report and so please let me know what specific details are required on my end in order to further debug this issue.
Comment 1 Lakshmi 2019-03-14 11:26:32 UTC
Can you please attach 5.0.1 kernel dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M?
Comment 2 Freddie Witherden 2019-03-14 12:35:54 UTC
Created attachment 143666 [details]
DRM log
Comment 3 Freddie Witherden 2019-03-14 12:36:35 UTC
Requested log attached for Linux 5.0.1 connected via HDMI.
Comment 4 Ville Syrjala 2019-03-14 12:55:05 UTC
Can you also attach a similar dmesg from a working kernel?
Comment 5 Freddie Witherden 2019-03-14 13:57:28 UTC
Created attachment 143668 [details]
DRM log from good kernel
Comment 6 Ville Syrjala 2019-03-14 14:57:17 UTC
Nothing obvious in the logs. The one change is that we now set the infoframe for the LSPCON chip.

Can you test with latest drm-tip branch to make sure we haven't fixed this in the meantime?
git://anongit.freedesktop.org/drm-tip drm-tip


To rule out the infoframe we could try something like this:
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c b/drivers/gpu/drm/i915/intel_lspcon.c
index 8d202b13e24f..1eac926c0821 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -473,6 +473,8 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
        const struct drm_display_mode *adjusted_mode =
                &crtc_state->base.adjusted_mode;
 
+       return;
+
        if (!lspcon->active) {
                DRM_ERROR("Writing infoframes while LSPCON disabled ?\n");
                return;
Comment 7 Freddie Witherden 2019-03-14 23:37:28 UTC
Applying the patch below results in display going blank immediately after bootup.

Although I do not feel confident trying drm-tip I am happy to repeat the experiment when 5.1 is released.  Also, let me know if there are any specific fixes or tests you would like me to try.
Comment 8 Lakshmi 2019-05-29 11:25:37 UTC
(In reply to Freddie Witherden from comment #7)
> Applying the patch below results in display going blank immediately after
> bootup.
> 
> Although I do not feel confident trying drm-tip I am happy to repeat the
> experiment when 5.1 is released.  Also, let me know if there are any
> specific fixes or tests you would like me to try.

Can you please try to verify the issue with drmtip or latest kernel?git://anongit.freedesktop.org/drm-tip drm-tip

Verifying the issue with drmtip is recommended.
Comment 9 Freddie Witherden 2019-06-20 14:10:37 UTC
(In reply to Lakshmi from comment #8)
> (In reply to Freddie Witherden from comment #7)
> > Applying the patch below results in display going blank immediately after
> > bootup.
> > 
> > Although I do not feel confident trying drm-tip I am happy to repeat the
> > experiment when 5.1 is released.  Also, let me know if there are any
> > specific fixes or tests you would like me to try.
> 
> Can you please try to verify the issue with drmtip or latest
> kernel?git://anongit.freedesktop.org/drm-tip drm-tip
> 
> Verifying the issue with drmtip is recommended.

So unfortunately I do not have access to that hardware/device combination.  The last version I was able to verify it on was 5.1.
Comment 10 Lakshmi 2019-06-26 11:02:07 UTC
We need a user to reproduce this issue with latest drmtip, without that it's impossible to go forward with this bug.
Closing this as WONTFIX.

Please reopen this issue if someone can reproduce this on drmtip. Remember to attach dmesg from boot when you reopen.


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.