More details at:
On top of that I've updated the tearing demonstration code:
This new version can take a command line argument - number of swaps per frame
and when invoked like: "~/tmp/gl/teartest 2" will tear even without DRI3(i.e.
with DRI2) (though with some override-redirect magic outlined in the first post)
With DRI3 it more or less always tears (fullscreen, nothing on top).
This leads me to suspsect that this is connected to bugs #97957 and #97173
My, perhaps naive, attempts to validate this hunch by compiling and using
Mesa/DRI from git head weren't entirely successful.
I've made a fatal mistake of assuming that not having Driver="intel" inside
the Device section will make X pick up modesetting by default, alas, it picked
intel in my case, so everything that has been said in this bug report and
in the mailing list posts applies to intel driver not modesetting. Sorry about
The tearing state of affairs with modesetting are as follows - no amount of
tinkering with xrandr has any effect on tearing, the teartest example from the
previous comment always tears, well, only when it doesn't and it doesn't in two
cases (at least those are the ones I've came across):
a) The window covers whole screen and there is nothing on top of it
b) The window is "strategically placed in the vertical direction"
(for example teartest with default window size of 640x480:
xdotool search nswaps windowmove 0 0 - tears
xdotool search nswaps windowmove 0 120 - does not tear)
If the screen was reflected/rotated tearing is always there for fullscreen
When more than one clear/swap is done in a quick succession (for instance
when teartest is invoked like so - ./teartest 3 or '3' is pressed while teartest
has input focus) the video output becomes quite chaotic (might require a couple
of seconds for it to become evident) Similar(though not quite the same) to the
ffect one can obtained by having vblank_mode set to N where N < 2)
-- 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/mesa/mesa/issues/1612.