FS#50374 - [mesa] weird drawing bugs
Attached to Project:
Arch Linux
Opened by c (c) - Friday, 12 August 2016, 19:36 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 30 August 2016, 15:33 GMT
Opened by c (c) - Friday, 12 August 2016, 19:36 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 30 August 2016, 15:33 GMT
|
Details
Description:
I don't know if it's latest X11, Intel DDX or Mesa 12, but right around the time mesa got updated to 12.0 some weird drawing issues started to appear in Xorg. The issue is some odd controlled flickering of the content or event-based partial drawing of the wrong buffer or parts of the buffer. When it happens, which is maybe three times during a day, this is what happens: Say you're running xterm (or urxvt), you're typing stuff and suddenly you don't see what you're typing, part of the content is invisible and as you type random (wrong) text is displayed as if it was flickering. It's not screen flickering, just the content reacting to X events. After a few redraw cycles or by forcing a larger area damage (refresh), it's all back to normal. Another way to see this is in a terminal multiplexer where the whole window is just empty (no text at all) and switching screen/tmux windows refreshes it enough to draw the right content. I don't know what it is, but this kinda looks like there's some buffering bug somewhere. I'm going to try to downgrade mesa to 11 to see if that fixes it. But first I'll try linux-lts. Additional info: * intel gpu hd 3000 * linux 4.6.5 and 4.7.0 * xorg-server 1.18.4-1 * mesa 12.0.1-7 * xf86-video-intel 1:2.99.917+691+ga77397a-1 |
This task depends upon
Closed by Doug Newgard (Scimmia)
Tuesday, 30 August 2016, 15:33 GMT
Reason for closing: Fixed
Additional comments about closing: xf86-video-intel 1:2.99.917+698+g71d3273-1
Tuesday, 30 August 2016, 15:33 GMT
Reason for closing: Fixed
Additional comments about closing: xf86-video-intel 1:2.99.917+698+g71d3273-1
BTW, wouldn't I basically be exercising the same code path by changing acceleration from sna to glamor?
backend = "xr_glx_hybrid"
vsync = "opengl-swc"
I've switched back to DRI2 with Intel DDX and turned on glamor acceleration as a test. So, TearFree, compton vsync, dri2, accel=glamor, though I'm likely to return to accel=sna and see if that's completely free of corruptions.
Also, I have no idea what "compton vsync" means.
You're right as it's been removed in the meantime: https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=0aa2edbd29c8dd26a5f3748e3875c445ea358a6d
> Also, I have no idea what "compton vsync" means.
Forcing vsync via a compositor, in this case compton, in order to complete fix tearing issues. Tearing manifests itself mostly prominently in browsers (scrolling) and video players (playback).
Are you saying there should be zero tearing with either the generic modesetting driver or intel ddx in dri3 mode (without tearfree option)?
compton.conf:
backend = "xr_glx_hybrid"
vsync = "opengl-swc"