Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Laurent Carlier (lordheavy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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
Comment by Samantha McVey (samcv) - Friday, 12 August 2016, 21:54 GMT
You should also try removing xf86-video-intel and see if that fixes anything. That will make xorg use glamor acceleration. For me that is usually less buggy. It's probably more likely it's a problem with xf86-video-intel at least at first glance.
Comment by c (c) - Saturday, 13 August 2016, 00:30 GMT
I tried the generic modesetting driver before and there's no way to fix the heavy tearing it causes. With the Intel DDX I can at least enable Tearfree and combine that with compton's vsync to get into tear-free territory. I'm pretty sure that people's success with the generic modesetting driver is hardware-dependent. The arch default of DRI3 since a couple package versions also causes bugs like visible resizing from a small rectangle to the final size of mpv's video window on startup, but that can be lived with and, no, DRI3 doesn't fix tearing by itself as promised.

BTW, wouldn't I basically be exercising the same code path by changing acceleration from sna to glamor?
Comment by c (c) - Saturday, 13 August 2016, 00:31 GMT
I will experiment with the generic modesetting driver again, and see if it can be made free of tearing. Didn't work last month. However, this bug isn't about tearing, it's about drawing issues that look like buffer related regressions.
Comment by c (c) - Saturday, 13 August 2016, 00:53 GMT
Nope, the generic modesetting driver is still super bad.
Comment by Samantha McVey (samcv) - Saturday, 13 August 2016, 01:58 GMT
What options are you launching compton with? Or if you use a config file can you post that? Thanks. I have the same Intel graphics card as you so I will test it out with your options.
Comment by c (c) - Saturday, 13 August 2016, 12:09 GMT
compton.conf:
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.
Comment by Doug Newgard (Scimmia) - Saturday, 13 August 2016, 13:34 GMT
The Intel DDX doesn't have glamor.

Also, I have no idea what "compton vsync" means.
Comment by c (c) - Saturday, 13 August 2016, 14:14 GMT
> The Intel DDX doesn't have glamor.

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)?
Comment by Doug Newgard (Scimmia) - Saturday, 13 August 2016, 14:27 GMT
You were listing DDX options, was "compton vsync" one of those or just some random option from elsewhere you threw in?
Comment by c (c) - Saturday, 13 August 2016, 14:32 GMT
"compton vsync" means "using compton's vsync feature". See the config pasted above and here:
compton.conf:
backend = "xr_glx_hybrid"
vsync = "opengl-swc"
Comment by c (c) - Saturday, 13 August 2016, 14:33 GMT
compton is a standalone compositor which became prominent due to the vsync feature. In the past it has been used for transparency and shadows, but currently it's most popular for forced vsync. I mean, if you search for tearing X11, compton will be one of the first solutions presented.
Comment by c (c) - Saturday, 13 August 2016, 14:36 GMT
Currently testing explicitly DRI2 because (1) that way there's no mpv visible window small-to-final-rectangle resize and (2) DRI3 has also become the default around the time of mesa 12, so DRI3 may be the actual culprit of the buffer corruptions.
Comment by c (c) - Sunday, 14 August 2016, 11:08 GMT
Also happens with intel ddx in dri2 mode. Just now saw Firefox's tab flicker, solved by switching tabs twice to force invalidation/redraw. I'll see if I can get mesa 11 running. It might require downgrading many packages, which I'm doubtful will work.
Comment by c (c) - Sunday, 14 August 2016, 12:16 GMT
Downgrade to mesa and mesa-libgl 11.2.2 successful. Let's see if the corruption occurs again.
Comment by c (c) - Monday, 15 August 2016, 23:09 GMT
So far no corruptions with mesa 11.2.2. Testing longer to be sure.
Comment by c (c) - Tuesday, 23 August 2016, 20:10 GMT
Currently testing mesa 12.0.1-7 with xf86-video-intel 1:2.99.917+698+g71d3273-1 (local pkg).
Comment by Andreas Radke (AndyRTR) - Saturday, 27 August 2016, 12:01 GMT
Can we close this one as fixed?
Comment by c (c) - Tuesday, 30 August 2016, 15:15 GMT
xf86-video-intel 1:2.99.917+698+g71d3273-1 seems to have fixed the buffer regressions, and the commits seem to relate to that.

Loading...