https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #38 from Sergey Kondakov (virtuousfox@gmail.com) --- (In reply to Alex Deucher from comment #37)
(In reply to Sergey Kondakov from comment #34)
By the way, is there any disadvantage in forcing TearFree to be always on when it works ? Like additional frame of latency or something like that ?
The TearFree option is there to deal with compositors that do not support sync to vblank. The ddx allocates another front buffer and then that buffer is updated synchronized with vblank with the data from the real front buffer. So it uses an additional buffer.
Thanks ! It's a shame, I've already begun believing in "The Silver Bullet of VSync". And it's completely "software" GPU-agnostic function, so alternatives like Wayland would have to just reimplement it the same way ? It always adds a buffer or "smart-enough" compositor can opt-out ? Or "the correct fix for latency" with TF is disabling vsync everywhere (such as kwin's GLPreferBufferSwap=n) else and let it handle it ?
No matter how I previously tried, nothing other than TearFree guaranteed actual lack of tearing in all times in simple 2x1080p configuration but there is abundance of buffering as it is in apps and a compositor + latency of LCD displays. I'm sure, you're aware of https://gitlab.freedesktop.org/xorg/xserver/issues/244 too. Strange that "the magic" of TF isn't done directly in compositors or kernel then.