| Summary: | Dual monitors unusable with DRI3 on Ivy Bridge | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | John Lindgren <john> | ||||||||||||
| Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||||||||||
| Status: | RESOLVED MOVED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||
| Severity: | major | ||||||||||||||
| Priority: | medium | CC: | flyser42, jimijames.bove, michel, sergeyn | ||||||||||||
| Version: | git | ||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||
| OS: | Linux (All) | ||||||||||||||
| Whiteboard: | |||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||
| Attachments: |
|
||||||||||||||
Created attachment 126765 [details]
X.org log with DRI2
Created attachment 126766 [details]
dmesg log with DRI3
Created attachment 126767 [details]
dmesg log with DRI2
That sounds like the compositor is not noticing the configuration change (or something similar). When you switch to extended configuration, we copy the current frontbuffer to the new configuration (tiling so that it looks like the original clone) and then go back to normal. If the DRI3 client continues to only update its original window it will only cover the left output. The challenge is proving that, and finding the bug. I added some tracing to compton and confirmed that it is aware of the change in screen size (ConfigureEvent received on the root window with the new size), and calls glViewport with the new size. I'm not sure where else to look for a bug on the client side. The xrender backend doesn't suffer from the same problem, only --backend glx. Mesa/dri3 has its own event/hook XCB_PRESENT_CONFIGURE_NOTIFY which it requires to notice the change in back buffer size. If that was missed, the compositor would be rendering the new size but only the original size would be shown - that would be easy to see. dri3_get_buffer() would be the right spot to add printfs to see what was going on. Compiling xf86-video-intel with ./configure --enable-debug=full would generate a huge Xorg.log from which we can check what size of pixmap is being rendered. But again not why. (In reply to Chris Wilson from comment #6) > ... dri3_get_buffer() would be the right > spot to add printfs to see what was going on. I am not very familiar with the mesa/dri architecture. Is dri3_get_buffer() a function in mesa? I can try adding some printf's at some point but for now I will probably stick with DRI2, which "just works". Yes, under mesa/src/loader/loader_dri3_helper.c No worries, if you don't have time/inclination to do it. Could I ask for a full-debug Xorg.0.log though? Will hopefully get around to trying a compton + DRI3 + multimonitor setup sometime in the near future... Created attachment 126835 [details]
X.org log with DRI3, debug=full
Here it is. The system froze shortly after trying to extending the desktop to both displays, but hopefully enough of the log was captured first to be useful to you.
At least that says what I expected; after the resize, we continue to process SwapBuffers only covering the left 1920x1080. Something is definitely amiss in the dri3 window resizing. FWIW, seems to work fine with the compton option --paint-on-overlay. Compositors should really draw to the composite overlay window instead of to the root window — all other popular compositors I know of do so by default, not sure why compton doesn't. On the server side, looks like present_config_notify doesn't get called for the root window. Given the above, I'd be inclined to resolve this as either NOTOURBUG (compton should use the composite overlay window by default or even unconditionally) or WONTFIX (looks like this may not be fixable in the Present extension for the root window). I can confirm that --paint-on-overlay works around the problem. So is it correct to say that by design, DRI3 will not work (or will not work properly) for painting the root window? If that's true, then perhaps mesa ought to be smart enough to fall back to software rendering in that case. That would be better than silently failing to update the screen contents. I just had a very long night of troubleshooting before figuring out, I have this exact bug, and the --paint-on-overlay option fixes it for me, too. And yeah, it is indeed not intel-specific, because I'm on nouveau. But even though this is fixed for me now, there are two things I can't figure out on my own that I'd like explained to me, if they're explicable: 1. Why did I not run into this issue until going from 4.9.8 to 4.10.8, when John started having it in 4.7.4? I'm also on Arch Linux, so our packages can't be different besides their versions. 2. Why did disabling compton, which was one of the first things I tried at the beginning of this painfully long night of troubleshooting, not fix the issue? Why did I have to either downgrade my kernel or apply the --paint-on-overlay option? Is XFCE's (or generally Linux's for all I know) dual monitor support SUPPOSED to be broken for people who don't use a compositor? (In reply to jimijames.bove from comment #13) No, it sounds like you ran into a different issue without compton, most likely either in XFCE or the nouveau drivers. But I already tried downgrading XFCE and the nouveau drivers and literally everything that has anything to do with X or my graphics drivers, and this issue, which showed up on my first reboot after updating all of those things, never went away until I downgraded the kernel. Plus running compton with that option fixes it. Despite all that, is it still probably a separate bug? Because if it is, I think it's still a bug in the kernel, rather than XFCE or nouveau. You might have run into the issue fixed by https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=924083938c8f209d8f6ff472caf8692a644f7e78 . I don't think so. That bug seems to cause the display to never come back on at all until X is restarted. My behavior was different. On boot, I had a properly functioning dual monitor setup, but once the 2nd monitor got disconnected (it's on an HDMI switch with gaming consoles and such), it started having 100% identical behavior to this bug report here. Until I turned the display off and back on in XFCE's Display preferences--then it would go back to a proper dual setup. Anyway, since your problem doesn't happen under exactly the same conditions as the one this report is about, it's clearly not the same. Please file your own report. Here's that report for anyone who's curious: https://bugzilla.kernel.org/show_bug.cgi?id=195321 -- 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/126. |
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.
Created attachment 126764 [details] X.org log with DRI3 Using Arch Linux x86_64 with: linux 4.7.4-1 xorg-server 1.18.4-1 xf86-video-intel 1:2.99.917+703+g15c5ff1-1 xfwm4 4.12.3-2 compton 0.1_beta2.5-3 With default settings (no xorg.conf), dual monitors can only be used in "clone" mode. When trying to switch to "extend" mode, the right-hand display freezes and continues to display a snapshot of the cloned display contents at the time of the switch. Using Option "DRI" "2" in xorg.conf is a workaround. My system is a Dell Latitude E5530 (Core i5 3210m). The left-hand monitor in this case is the laptop display and the right-hand monitor is an Acer external display connected to the docking station with a DVI cable.