Created attachment 103346 [details] corruption across screens after "waking" blanked screen for unlocking workstation I'm experiencing some sort of corruption on my relatively new laptop running Debian Sid (w/ GNOME 3). The laptop is a Clevo P150SM based machine (Sager NP8265), which has the screen connected via eDP to the integrated Intel HD 4600 (Core i7 4910MQ), and the discrete (AMD Radeon HD 8970M) has no connected heads. The attached photo (IMG_20140723_105703.jpg) is what I see when I move the mouse to "wake" (unblank) the blanked screens (from having locked the machine). If I click or start typing, the GNOME login shows and allows me to enter my password and unlock the machine. The corruption is slightly different each time. I see similar corruption on the screen when booting into Linux. It seems as though right once KMS activates, that's when I see the corruption. As well, I used to see similar corruption in GNOME's desktop background configuration dialog, but with recent updates this is no longer the case. Last, now that I have PRIME/hybrid graphics working, I also see corruption of window decorations around PRIME backed windows. When I run `DRI_PRIME=1 glxgears`, the gears render fine, but the window decorations are corrupt (typically just plain black) until I move the window or do some window focus dance, at which point they are rendered correctly. I've noticed this issue from day one, 3.12 kernels, and now on 3.14 (and I believe even 3.15 and 3.16 kernels, but I will have to verify that and follow up). I think this is a composting related issue, but it could be deeper or something else entirely.
Created attachment 103347 [details] close up of corruption after unblanking during locked
It has the look of a ddx bug. It looks like it is presenting an uninitialised framebuffer on the scanouts - so either it is failing to update the CRTC or failing to rendering correctly. Please attach your Xorg.0.log (and dmesg just in case).
Created attachment 103352 [details] journalctl -b /usr/bin/Xorg
Created attachment 103353 [details] dmesg
Can you please first test with xf86-video-intel-2.99.914?
(In reply to comment #5) > Can you please first test with xf86-video-intel-2.99.914? I am trying this now. A video of the artifacting upon boot can be seen here: http://loki.ist.unomaha.edu/~nmschulte/VID_20140723_120514.mp4 The artifacting/corruption comes at the end of the video, and unfortunately the camera is out of focus, but it is pretty plainly visible. It is always relegated to the top of the screen (I've never seen it anywhere else during boot).
(In reply to comment #6) > The artifacting/corruption comes at the end of the video, and unfortunately > the camera is out of focus, but it is pretty plainly visible. It is always > relegated to the top of the screen (I've never seen it anywhere else during > boot). That is a different form of corruption resulting from the BIOS reading out of memory that we overwrite for use by our GTT. That is fixed in 3.15 (and technically a regression from about 3.2).
(In reply to comment #5) > Can you please first test with xf86-video-intel-2.99.914? This seems to fix the issue for unblanking corruption. However, it seems DRI PRIME is now broken; `xrandr --setprovideroffloadsink ...` seems to have no effect: running `LIBGL_DEBUG=verbose DRI_PRIME=1 glxinfo` shows the i915 driver infos. As well, when I run the xrandr command, before the desktop background would "flicker" (render the solid chosen color, then the wallpaper on top) as it does when I first login, now it does not. (In reply to comment #7) > That is a different form of corruption resulting from the BIOS reading out > of memory that we overwrite for use by our GTT. That is fixed in 3.15 (and > technically a regression from about 3.2). Alright, good to know. I will verify it is gone in the packaged 3.15/16 kernels.
What! I just spent the last couple of days looking at DRI_PRIME. :|
Using -nouveau, DRI_PRIME seems to be working, but only with DRI2 (you have to xf86-video-intel/configure --disable-dri3). I thought DRI3 had been fixed to work with prime, so I will dig a little deeper just in case.
I tried this on the 3.16-rc5 kernel as well; same deal. However, the background _does_ flicker when I run `xrandr --setprovideroffloadsink ...`, and it looks like it also does on the 3.14 kernel (I just didn't notice that time; or it doesn't always do it). Let me know what else I can provide; I'm not in a situation where I can build the DDXs/rest of the stack. I lack the understanding in how things interop in Debian's packaging, and there are no clear guides to do so. I can build _just_ the DDX, without needing the rest of the stack, correct? That might not be so difficult to do. We should probably close this report now, or should we use it for this new issue?
(In reply to comment #11) > I tried this on the 3.16-rc5 kernel as well; same deal. > > However, the background _does_ flicker when I run `xrandr > --setprovideroffloadsink ...`, and it looks like it also does on the 3.14 > kernel (I just didn't notice that time; or it doesn't always do it). > > Let me know what else I can provide; I'm not in a situation where I can > build the DDXs/rest of the stack. I lack the understanding in how things > interop in Debian's packaging, and there are no clear guides to do so. I > can build _just_ the DDX, without needing the rest of the stack, correct? > That might not be so difficult to do. xf86-video-intel will build and install by itself (just use apt-get build-dep xserver-xorg-video-intel to install the headers required to build the ddx). > We should probably close this report now, or should we use it for this new > issue? The new issue being that you don't see the background flicker? That sounds like a good thing! Or to confirm that it is DRI3 upsetting glxinfo? For the later, that should be a separate bug report (as it is a mesa bug) but only file after checking for updates.
(In reply to comment #12) > xf86-video-intel will build and install by itself (just use apt-get > build-dep xserver-xorg-video-intel to install the headers required to build > the ddx). Oh, of course. I was over-complicating things. I'll attempt to build the DDX w/out DRI3 and I'll report back. > > We should probably close this report now, or should we use it for this new > > issue? > > The new issue being that you don't see the background flicker? That sounds > like a good thing! Or to confirm that it is DRI3 upsetting glxinfo? For the > later, that should be a separate bug report (as it is a mesa bug) but only > file after checking for updates. The latter; both of the corruptions I was seeing are already fixed (one in the DDX, and one in the kernel it seems). The only issue I have now is the DRI PRIME issue, which as you said should go in another report assuming it still exists with the latest codes. I'm marking this as resolved/fixed; feel free to change to a more suitable resolution. Thanks for your support; I wish I had more to contribute.
FYI: Building the intel DDX with --disable-dri3 allows DRI_PRIME to work (version 2.99.914 w/ Debian's patches, if any). There are no newer versions readily available to test, but I will try my hand at building the latest release with DRI3 and see how it goes.
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.