Created attachment 132331 [details] configs, dmesg w/ drm.debug=0xe, EDIDs, fb0 sysfs, inxi, Xorg.0.log, picture of screen I have a Thinkpad X270 with an i7 7500U / Intel HD Graphics 620, running Fedora 25, Mint, and Xubuntu (attachments are from Xubuntu.) I had been using a 26" Vizio E261VA TV over HDMI as an external monitor for a few months without any issues, but after upgrading to any kernel >= 4.11.0-rc1, the display becomes very pixelated and text is almost unreadable. On 4.10 it looks fine. One thing I noticed was that the "mode" for the fb0 device is now set to "U:1360x768p-0". In the working kernel it's "U:1920x1080p-0". The issue only happens over HDMI; the picture still looks fine if I use a USB-C -> VGA adapter. The native resolution for this TV is 1360x768, which is the resolution I run it at, and the laptop screen is running at 1920x1080. I have tried uninstalling the Xorg intel driver but it didn't make a difference. I have also tried booting the kernel with the parameter video=HDMI-A-2:1920x1080M@60. That will change the framebuffer mode back to what it was in 4.10, but I still can't seem to get the pixelation to go away. I tried to force the EDID from VGA using drm_kms_helper but it didn't help either. I built a kernel from cgit.freedesktop.org/drm-tip today (6/28/17) and I still see the issue. Attached the configs I am using for 4.10 and the drm-tip kernel. I noticed quite a few changes in the logs for 4.11.0-rc1 involving drm/i915, framebuffers, EDID, and HDMI, so I assume this has something to do with that. I'm not 100% sure it involves the framebuffer, but the resolution change caught my eye. I see the pixelation before X even starts, while the startup checks are running down the screen. Please let me know if I can provide any other info. Thanks!
Adding tag into "Whiteboard" field - ReadyForDev *Status is correct *Platform is included *Feature is included *Priority and Severity correctly set *Logs included
Created attachment 132808 [details] git bisect log
I did a git bisect on the kernel and here's what it came up with. I'm compiling a current mainline kernel with this commit reverted to see if that fixes the issue for me. I also noticed a new Lenovo UEFI with "(New) Revert VBIOS to 1046." in the changes, so I'll try that too and see if it has any effect. # first bad commit: [fcc8a22cc9053a8d1bbb94833ec103cd5961feef] drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F commit fcc8a22cc9053a8d1bbb94833ec103cd5961feef Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Jan 11 14:57:25 2017 +0200 drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F CEA-861-F tells us: "When transmitting any RGB colorimetry, the Source should set the YQ-field to match the RGB Quantization Range being transmitted (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB, set YQ=1) and the Sink shall ignore the YQ-field." So let's go ahead and do that. Perhaps there are sinks that don't ignore the YQ as they should for RGB? I wasn't able to find similar text in CEA-861-E, so it would seem to be a fairly "recent" addition. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
Confirmed that reverting the commit fixes the problem, and the UEFI update didn't make a difference.
(In reply to Neil Kownacki from comment #4) > Confirmed that reverting the commit fixes the problem, and the UEFI update > didn't make a difference. Thanks for the update, if more information is required for this case it would be commented below.
Fixed in drm-misc-fixes. commit 9271c0ca573e02a360b636ecd8cb408852f4e9f6 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Nov 8 17:25:04 2017 +0200 drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
Hello Neil, could you confirm that comment 6 fixed it? Thank you.
Confirmed that the patch in Comment 6 fixes the problem. I'm running the 4.14 kernel with no issues now. Thanks for your help with this!
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.