On an HP mt20/mt21, if an HDMI cable is connected and then disconnected after waiting for some time for the hotplug to settle, DRM may get into an inconsistent state where the kernel believes the HDMI cable is connected, but it has been physically disconnected. This results in future hotplugs not necessarily behaving correctly, nor has the desktop properly resized due to the cable being disconnected. For example, if the laptop panel is 1920x1080 and a monitor is connected to the unit via HDMI with a native resolution of 1920x1080, a hotplug will now have a desktop of size 3840x1080. When the problem occurs, after the cable has been disconnected, the desktop is *still* 3840x1080. Running the xrandr command *may* get the system back into a consistent state, it almost appears as if a uevent bubbled up to userspace got stuck and the handler for that event never exits, which leaves the the system into an inconsistent state. Running xrandr "pokes" this handler and gets it back to processing. This issue has been reproduced with both the modeset and intel X server drivers, on kernels up to at least 4.15.7. Software Information OS: Ubuntu 16.04.3 LTS Kernel: 4.10.0-28-generic X: 1.19.3 DDX: modeset Mesa: 17.0.7-0ubuntu0.16.04.1 libdrm: 2.4.76-1~ubuntu16.04.1 Hardware Information Processor: Intel Celeron 3865U (Kabylake-U) Graphics: Intel HD Graphics 610 (8086:5906) (ark:https://ark.intel.com/products/96507/Intel-Celeron-Processor-3865U-2M-Cache-1_80-GHz) Quickspecs of the mt21: http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=c05561757
Created attachment 139023 [details] Kernel log on fresh boot Output from the kernel on boot once we have logged into the desktop, using drm.debug=0x06.
Created attachment 139024 [details] Kernel log w/ issue The kernel log after we have reproduced the issue. We know the issue has reproduced because looking at /sys/class/drm/card0-HDMI-A-1/status shows that the connector is "connected" even though we have disconnected the cable.
Created attachment 139025 [details] Kernel log after xrandr Kernel log after we have run xrandr. Running the xrandr command appears to get the system "unstuck" and we get back to (presumably) a consistent state.
Have you Zachary tested this with drm-tip (git://anongit.freedesktop.org/drm-tip). This to understand whether the problem exists with our latest codebase
No I haven't, but usually if I go off and test that or the latest i915, the kernel just does not fully boot, so it isn't a useful test for me to run. -Zack
Can I get an update on this issue? -Zack
I'm unable to reproduce the issue on the below config. KBL NUC7i7BNH Ubuntu 17.10 (Kernel 4.13.0-41) modesetting DDX DDIs: HDMI and TypeC-DP - Have you tried replicating the issue on KBL RVP? - Is the issue seen on DP or is it only HDMI? If its HDMI only, do you have a LsPcon on mt20/21?
Hi Ajit, We don't have a KBL RVP. I've only seen the issue on HDMI at this time. I have no idea of there is an LSPCON on those platforms. I've also not been able to reproduce it on Catan. This could be something specific to the actual hardware of the mt20/mt21, not the chip though. -Zack
I was not able to recreate the issue on the KBL RVP DDI0 eDP and DDI1 HDMI like in the given hardware. Ubuntu 17.10 (Kernel 4.13.0-41) I was however able to recreate the issue on HP hardware (model p/n:X8BA C8 PV), I recreated it on the given Thin Pro OS and also on Ubuntu 17.10 (Kernel 4.13.0-41). it appears the system does not register the unplugging of the HDMI cable, I currently believe this is a Hardware issue since it appears on both operating systems and we will examine the hardware schematics.
Possibly a dupe of bug 107125.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/154.
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.