Created attachment 91488 [details] reproducer The attached testcase fills a GLX Pbuffer with 0x80 gray. It never creates a window and thus should not affect the screen. However, passing actual screen dimensions in arguments: ./a.out 1920 1080 causes the screen to become gray (as if the pbuffer's contents became visible). It also "works" to pass actual screen width and a fraction of actual height, in which case the top fraction of the screen becomes gray. Passing 4096 4096 in my case caused the test to be killed with "bus error". The window manager (xfwm4, fluxbox) becomes non-functional after triggering the issue. This is reproducible on IVB with UXA, but not SNA. Is UXA, um, somehow misallocating buffers for the pbuffer or swapping Mesa's offscreen buffers onscreen? I'd try to debug it myself, but I have no idea how to approach it. Please let me know if additional info is required.
Do you also see a SIGSEGV (gen7_update_renderbuffer_surface, gen7_wm_surface_state.c:509)? Anyway this is rather weird.
commit 28810d5b367942c96acbc696f27105259422a0d1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jan 6 14:26:38 2014 +0000 uxa/dri: Pixmap are offscreen and not attached to any display As the code current assumes that pixmaps are located at screen origin (0,0), it assumes that they are all on the first CRTC. However, since they are offscreen, this leads to such complications as attempting to emit vsync swapbuffers, and even worse attempting to swap a GLXPixmap onto the scanout following a DRI2SwapBuffers. Reported-by: Alexander Monakov <amonakov@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73282 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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.