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.
Can you please attach 5.0.1 kernel dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M?
Created attachment 143666 [details] DRM log
Requested log attached for Linux 5.0.1 connected via HDMI.
Can you also attach a similar dmesg from a working kernel?
Created attachment 143668 [details] DRM log from good kernel
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;
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.
(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.
(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.
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.