[platforms/X11] Disable VSync for QtQuick Windows

Authored by ekurzinger on Jun 14 2019, 8:38 PM.



QtQuick windows created by KWin currently use the default swap interval of 1,
meaning buffer swaps will block until vblank. However, this results in a problematic
interaction on hybrid graphics systems running the proprietary NVIDIA driver.
VSync on such setups relies on a system called "PRIME synchronization", where
the xf86-video-modesetting driver controlling the display will signal the NVIDIA
driver when vblank has occurred. The issue is that it will only do so if there has been
damage to the screen.

So, when KWin creates a QtQuick window, compositing will stop waiting on the
window to render, therefore no damage to the screen will occur. But this means
that no vblank notifications will be delivered to the NVIDIA driver, so the glXSwapBuffers
call by the QtQuick window will block perpetually. The end result is a freeze of the

To get around this, we can simply disable vsync for QtQuick windows by setting the
swap interval for the default QSurfaceFormat to 0. Since they are redirected, this
shouldn't cause any tearing.

BUG: 406180

Test Plan

Using the proprietary NVIDIA driver on a hybrid graphics system, with PRIME synchronization enabled
(see https://devtalk.nvidia.com/default/topic/957814/linux/prime-and-prime-synchronization/),
perform any action causing a QtQuick window to be created by KWin, for example, triggering the
application switcher dialogue with alt + tab.

Ensure the desktop does not temporarily freeze.

Note, this required a Qt build that includes commit https://code.qt.io/cgit/qt/qtbase.git/commit/?id=0c1831178540462da31fd7a4b6d2e446bc84498b
resolving a bug that prevented the changing the swap interval.

Diff Detail

R108 KWin
Lint Skipped
Unit Tests Skipped
ekurzinger created this revision.Jun 14 2019, 8:38 PM
Restricted Application added a subscriber: kwin. · View Herald TranscriptJun 14 2019, 8:38 PM
ekurzinger requested review of this revision.Jun 14 2019, 8:38 PM
ekurzinger retitled this revision from [platformx/X11] Disable VSync for QtQuick Windows to [platforms/X11] Disable VSync for QtQuick Windows.Jun 14 2019, 8:47 PM
alexeymin added a subscriber: alexeymin.EditedJun 14 2019, 9:54 PM

Qt build that includes commit 0c1831178540462da31fd7a4b6d2e446bc84498b

Which Qt repo/module? qtdeclarative? or maybe a link to commit?

ngraham edited the summary of this revision. (Show Details)Jun 14 2019, 10:04 PM
davidedmundson accepted this revision.Jun 14 2019, 10:08 PM
This revision is now accepted and ready to land.Jun 14 2019, 10:08 PM
romangg added inline comments.

Please add a one-line comment why it's done.

ekurzinger edited the test plan for this revision. (Show Details)Jun 14 2019, 11:05 PM

added brief explanation comment

ekurzinger marked an inline comment as done.Jun 14 2019, 11:19 PM
zzag added a subscriber: zzag.Jun 15 2019, 7:38 AM
zzag added inline comments.

Each include section has to be sorted alphabetically.

ekurzinger updated this revision to Diff 60003.Jun 17 2019, 6:11 PM

alphabetized #include statements

ekurzinger marked an inline comment as done.Jun 17 2019, 6:12 PM
zzag accepted this revision.Jun 17 2019, 6:54 PM

This perhaps needs to go in 5.16.

I have one question. What should we do about 5.12?

Definitely 5.16

I have one question. What should we do about 5.12?

I say we revert the original patch. It's had issues, and given this requires the matching Qt fix it's not immediately fixed either.

There was mention of switching QtQuick to use SW rendering on PRIME systems, would that be preferable to reverting the tearing fix?
I just learned that RandR will report a property named "PRIME Synchronization" for any affected outputs, so it should actually be easier than I originally thought to detect. Just need to call XRRListOutputProperies (or whatever the xcb equivalent is).
I can try to get a quick patch up for review if so.

This revision was automatically updated to reflect the committed changes.