Created attachment 126703 [details] Output of `dmesg` Using Linux 4.8-rc7 on a Sky Lake system, since installing the GUC and DMC firmware BLOBs [1], the Dell monitor sometimes only shows the right half of the picture. The left part stays black. The monitor is connected using DisplayPort, and it’s reproducible with both ports. A reboot doesn’t fix it, and only half of the image is seen during the firmware stage (UEFI), and bootloader (GRUB) too. Only turning the monitor off and back on fixes the problem. I attach the Linux messages, but as this happens also during non-Linux stages, I assume it’s a hardware problem. It only starts happening though, once GDM is started, and then the problem stays, until the monitor is turned off and back on. That means, today, turning on the system, firmware (UEFI), GRUB, and Linux messages were shown just fine, but starting GDM, only half of the screen was visible. Turning the monitor off and back on, fixed it. ``` $ lspci -nn -s 0:02.0 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) ``` [1] https://01.org/linuxgraphics/intel-linux-graphics-firmwares
Please add drm.debug=14 module parameter, and attach dmesg from boot again. First instinct is that it's a high resolution display implemented with two panels in a DP MST setup.
Created attachment 126705 [details] Output of `dmesg` with `drm.debug=14` passed to Linux (In reply to Jani Nikula from comment #1) > Please add drm.debug=14 module parameter, and attach dmesg from boot again. Please found the output attached. Please note, the problem didn’t manifest itself this time.
This still happens with Linux 4.9.10, though much less frequently. Can I provide any more information?
It doesn't look like an MST display. But since the two halves behave differently I suppose it's possible that's it is constructed out of two panels regardless and it just splits the single stream internally, or something like that. I suspect the underruns are the real problem. Possibly the stream splitting logic in the monitor gets confused and somehow manages to mess up the second panel when there are dropouts in the stream.
(In reply to Ville Syrjala from comment #4) > It doesn't look like an MST display. But since the two halves behave > differently I suppose it's possible that's it is constructed out of two > panels regardless and it just splits the single stream internally, or > something like that. > > I suspect the underruns are the real problem. Possibly the stream splitting > logic in the monitor gets confused and somehow manages to mess up the second > panel when there are dropouts in the stream. Is there a way to verify your theory? That would help me to get in contact with Dell so that they can fix the monitor.
Hello, I could not reproduce the issue with the following configuration: ====================================== Graphic stack ====================================== ====================================== Software ====================================== kernel version : 4.12.0-rc3-drm-tip-ww22-commit-187376e+ architecture : x86_64 os version : Ubuntu 17.04 os codename : zesty kernel driver : i915 bios revision : 4.6 bios release date : 03/02/2017 ====================================== Graphic drivers ====================================== mesa : 17.0.3 modesetting : modesetting_drv.so xorg-xserver : 1.19.3 libdrm : 2.4.81 cairo : 1.14.8 xserver : X.Org X Server 1.19.99.1 intel-gpu-tools (tag) : intel-gpu-tools-1.18-211-g00ce341b intel-gpu-tools (commit) : 00ce341b ====================================== Hardware ====================================== platform : HSW-Nuc motherboard id : D54250WYK form factor : Desktop cpu family : Core i5 cpu family id : 6 cpu information : Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz gpu card : Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) memory ram : 3.79 GB max memory ram : 16 GB display resolution : 1600x900 cpu thread : 4 cpu core : 2 cpu model : 69 cpu stepping : 1 socket : Socket LGA1150 signature : Type 0, Family 6, Model 69, Stepping 1 hard drive : 223GiB (240GB) current cd clock frequency : 450000 kHz maximum cd clock frequency : 450000 kHz displays connected : DP-1 ====================================== Firmware ====================================== ====================================== kernel parameters ====================================== quiet splash fastboot drm.debug=0xe Regards.
(In reply to Armando Antonio from comment #6) > Hello, I could not reproduce the issue with the following configuration: […] Obviously this is display dependent, and doesn’t happen all the time. So what display did you test with?
(In reply to Paul Menzel from comment #5) > (In reply to Ville Syrjala from comment #4) > > It doesn't look like an MST display. But since the two halves behave > > differently I suppose it's possible that's it is constructed out of two > > panels regardless and it just splits the single stream internally, or > > something like that. > > > > I suspect the underruns are the real problem. Possibly the stream splitting > > logic in the monitor gets confused and somehow manages to mess up the second > > panel when there are dropouts in the stream. > > Is there a way to verify your theory? That would help me to get in contact > with Dell so that they can fix the monitor. Hello Paul, You can try to get some extra help in the community forums: https://01.org/linuxgraphics/community Hope it helps.
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.
Paul, is this still issue with latest drm-tip?
The monitor is currently used by a colleague, so I do not have a way to test. Therefore, I’ll close this for now.
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.