https://bugzilla.kernel.org/show_bug.cgi?id=204181 --- Comment #39 from Alex Deucher (alexdeucher@xxxxxxxxx) --- (In reply to Sergey Kondakov from comment #38) > > 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. Here is your issue: "simple 2x1080p" multiple display are really hard to deal with. The display timing may be different, the blanking periods may not align, etc. X uses a single surface for each multi-display desktopso when you are updating multiple displays, if the timings are not aligned, one display will show older content. For this to work smoothly, you really need the compositor to have each display using it's own set of buffers and doing vsynced rendering to each display separately. -- You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
