|Summary:||[i915] xf86-video-intel breaks secondary display in Xorg|
|Status:||RESOLVED DUPLICATE||QA Contact:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|i915 platform:||i915 features:|
Description roccobaroccoSC 2019-10-11 08:20:10 UTC
Symptoms: -- Secondary display cannot be used anymore. -- Every attempt to activate the secondary dislpay crashes and restarts the KDE session to login screen. -- Xorg -configure produces a usable configuration file, but when starting KDE with that configuration, only primary display has contents. The secondary display is not recognized by xrandr and is empty, but the mouse cursor CAN move into the secondary display. Mouse has the generic X-shape form on the secondary display (apparently this display is still usable by Xorg but not by KDE). System environment: -- cpu: Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz -- chipset: i915 -- system architecture: x86_64 -- xf86-video-intel version: 1:2.99.917+893+gbff5eca4-1 (Arch package) -- xorg version: 1.20.5-2 -- kernel version: 5.3.5-arch1-1-ARCH -- Linux distribution: Arch -- Machine or mobo model: lenovo W520 (NVIDIA+Intel Graphics, NVIDIA is turned off in BIOS) -- Display connector: Integrated monitor + external monitor on VGA connector Reproduce: -- Connect a secondary VGA monitor (the bug may concern also other types of connectors). -- Update xf86-video-intel from version 1:2.99.917+870+g6f4972d5-1 to version 1:2.99.917+893+gbff5eca4-1 (Arch package versioning) -- Make sure no xorg.conf is present. -- Start a KDE session --> Secondary display is scrabled or missing. When trying to enable it, KDE session crashes and restarts. xrandr does not show the secondary monitor. Downgrade xf86-video-intel back to version 1:2.99.917+870+g6f4972d5-1. Secondary display works.
Comment 3 roccobaroccoSC 2019-10-11 09:52:50 UTC
Created attachment 145703 [details] xorg.conf snippet
Comment 4 roccobaroccoSC 2019-10-11 10:02:46 UTC
Created attachment 145704 [details] xrandr --verbose output
Comment 5 roccobaroccoSC 2019-10-11 10:05:41 UTC
Created attachment 145705 [details] xrandr --verbose, old driver version - working correctly
Comment 6 roccobaroccoSC 2019-10-11 10:09:34 UTC
The bug is also reproducible with Gnome+Xorg and Gnome+Wayland.
Comment 7 Ville Syrjala 2019-10-11 13:17:48 UTC
The only theory I have is that it's due to commit 581ddc5d2f55 ("sna: Fix compiler warnings due to DrawablePtr vs. PixmapPtr"). Ie. maybe this thing was working by sheer luck before. Can you build from source and revert that commit?
Comment 8 roccobaroccoSC 2019-10-11 22:28:41 UTC
I tried building the package from source (version 870, last known good). For some reason when I build it, it crashes somewhere in the libc, called by intel_drv. Installing a centrally built version by Arch (same code) works just fine. Apparently I somehow messed my build configuration (flags). With this in mind, I would not be able to build from source and test, really sorry about that. If I succeed running my custom build I'll let you know.
Comment 9 roccobaroccoSC 2019-10-11 22:46:46 UTC
I found something interesting! The last known good arch package 870 had a patch file that was deleted in the next version! The patch file explains exactly the same symptoms as mine. https://git.archlinux.org/svntogit/packages.git/plain/trunk/0001-SNA-fix-PRIME-output-support-since-xserver-1.20.patch?h=packages/xf86-video-intel&id=ac52f309e918498f64b4c33e6967846cd0a551f6 I have no idea why the patch file was removed but this explains why my own built sources did not work - I did not have the Arch patch. Here is what the patch describes: " Since xorg-server 1.20, an external monitor would remain blank when used in a PRIME output slave setup. Only a cursor was visible. The cause is "Make PixmapDirtyUpdateRec::src a DrawablePtr" in xserver, the "src" pointer might point to the root window (created by the server) instead of a pixmap (as created by xf86-video-intel). Use get_drawable_pixmap to handle both cases. " For more details see the URL above.
Comment 10 roccobaroccoSC 2019-10-11 22:53:31 UTC
I think the change was integrated later on, that's why the patch is unnecessary. Now I can build and test.
Comment 11 roccobaroccoSC 2019-10-11 23:33:53 UTC
I can now confirm that the problem appears with this commit: 581ddc5d2f55efa2cf5ec76a802fb781ee142b01 "sna: Fix compiler warnings due to DrawablePtr vs. PixmapPtr" The previous commit bfeeae4de951712e9e00f681d582c6bd7f40dcd6 works with the patch I mentioned above: https://git.archlinux.org/svntogit/packages.git/plain/trunk/0001-SNA-fix-PRIME-output-support-since-xserver-1.20.patch?h=packages/xf86-video-intel&id=ac52f309e918498f64b4c33e6967846cd0a551f6 The said patch seems to have been integrated into 581ddc5d2f55efa2cf5ec76a802fb781ee142b01 but obviously the patch does not contain all the changes. The source of the problem must be in a change that is not in the patch file.
Comment 12 roccobaroccoSC 2019-10-12 00:29:36 UTC
I found a difference. sna_accel.c, line 17686 In git the line "src = dirty->src;" was substituted for +#ifdef HAS_DIRTYTRACKING_DRAWABLE_SRC + assert(dirty->src->type == DRAWABLE_PIXMAP); +#endif + + src = (PixmapPtr)dirty->src; however, in the applied patch file the block is: +#ifdef HAS_DIRTYTRACKING_DRAWABLE_SRC + src = get_drawable_pixmap(dirty->src); +#else src = dirty->src; +#endif This seems to be the only difference that makes xorg crash.
Comment 13 roccobaroccoSC 2019-10-12 00:40:46 UTC
Created attachment 145716 [details] [review] sna_accel.c_secondary_monitor.patch This patch fixed the problem for me.
Comment 14 Peter Wu 2019-11-16 16:06:37 UTC
Arch Linux was carrying my patch from bug 100086, I should have tried harder to push it upstream. In meantime an independent patch was merged that only addressed the compiler warnings, but not the crash. A rebased patch with an updated commit message can now be found here: https://lists.freedesktop.org/archives/intel-gfx/2019-November/220136.html I will go ahead and mark this bug as duplicate of bug 100086 since it is exactly the same issue, it just did not surface before for you because of the downstream patch. *** This bug has been marked as a duplicate of bug 100086 ***