GLX apps are swapping at the wrong refresh rate under Xwayland

[Daniel van Vugt]

GLX apps are swapping at the wrong refresh rate under Xwayland.

My monitor runs at 59.95Hz and this is what I see:

Xwayland:

$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
428 frames in 5.0 seconds = 85.552 FPS
300 frames in 5.0 seconds = 59.993 FPS
301 frames in 5.0 seconds = 60.006 FPS
301 frames in 5.0 seconds = 59.983 FPS
301 frames in 5.0 seconds = 60.016 FPS WRONG
300 frames in 5.0 seconds = 59.999 FPS
300 frames in 5.0 seconds = 59.986 FPS
301 frames in 5.0 seconds = 60.004 FPS
301 frames in 5.0 seconds = 60.002 FPS
300 frames in 5.0 seconds = 59.998 FPS

$ weston-info | grep refresh
  width: 1920 px, height: 1200 px, refresh: 59.950 Hz,

Xorg:

$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
481 frames in 5.0 seconds = 96.146 FPS
300 frames in 5.0 seconds = 59.952 FPS
300 frames in 5.0 seconds = 59.956 FPS
300 frames in 5.0 seconds = 59.943 FPS
300 frames in 5.0 seconds = 59.948 FPS RIGHT
300 frames in 5.0 seconds = 59.953 FPS
300 frames in 5.0 seconds = 59.951 FPS
300 frames in 5.0 seconds = 59.949 FPS
300 frames in 5.0 seconds = 59.956 FPS
300 frames in 5.0 seconds = 59.947 FPS
300 frames in 5.0 seconds = 59.952 FPS

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xwayland 2:1.19.5-0ubuntu2
ProcVersionSignature: Ubuntu 4.13.0-25.29-generic 4.13.13
Uname: Linux 4.13.0-25-generic x86_64
ApportVersion: 2.20.8-0ubuntu6
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
Date: Tue Jan 30 13:30:34 2018
DistUpgraded: Fresh install
DistroCodename: bionic
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation Xeon E3-1200 v3 Processor Integrated Graphics Controller [8086:041a] (rev 06) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Xeon E3-1200 v3 Processor Integrated Graphics Controller [17aa:30a1]
InstallationDate: Installed on 2017-12-12 (48 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20171211)
MachineType: LENOVO 30AJS05700
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.13.0-25-generic.efi.signed root=UUID=f9fe7460-9c41-4d4a-8376-e5ceb57bbec8 ro quiet splash vt.handoff=1
SourcePackage: xorg-server
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/02/2015
dmi.bios.vendor: LENOVO
dmi.bios.version: FBKTB6AUS
dmi.board.name: SHARKBAY
dmi.board.vendor: LENOVO
dmi.board.version: SDK0E50519 PRO
dmi.chassis.type: 7
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnLENOVO:bvrFBKTB6AUS:bd08/02/2015:svnLENOVO:pn30AJS05700:pvrThinkStationP300:rvnLENOVO:rnSHARKBAY:rvrSDK0E50519PRO:cvnToBeFilledByO.E.M.:ct7:cvrToBeFilledByO.E.M.:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: 30AJS05700
dmi.product.version: ThinkStation P300
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.13.1+18.04.20171116-0ubuntu1
version.libdrm2: libdrm2 2.4.89-1
version.libgl1-mesa-dri: libgl1-mesa-dri 17.2.4-0ubuntu2
version.libgl1-mesa-glx: libgl1-mesa-glx 17.2.4-0ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.19.5-0ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.10.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2

[Grmat (grmat)]

Looks like xwayland doesn't report the correct refresh rate/vsync timings(?) to clients. I've been working around compositor implementation flaws by using a custom EDID file. Now the compositors I've tried (Mutter, KWin, Sway) run at the correct 144 Hz, however xwayland clients still only refresh at 60 Hz.

This is bad because if using a monitor with no even multiple of 60 Hz (like 72, 75, or 144 Hz monitors), there is stutter instead of smooth playback. And I guess many common apps will be running through xwayland for quite some time.

I can also confirm the problem running glxgears, which runs v-synced and prints 60 FPS to the console.

[Stevengruspier (stevengruspier)]

(In reply to grmat from comment #0)
> Looks like xwayland doesn't report the correct refresh rate/vsync timings(?)
> to clients. I've been working around compositor implementation flaws by
> using a custom EDID file. Now the compositors I've tried (Mutter, KWin,
> Sway) run at the correct 144 Hz, however xwayland clients still only refresh
> at 60 Hz.
>
> This is bad because if using a monitor with no even multiple of 60 Hz (like
> 72, 75, or 144 Hz monitors), there is stutter instead of smooth playback.
> And I guess many common apps will be running through xwayland for quite some
> time.
>
> I can also confirm the problem running glxgears, which runs v-synced and
> prints 60 FPS to the console.

You might be interested in this one Bug Report for wanting to add different refresh rates to mutter: https://bugzilla.gnome.org/show_bug.cgi?id=781296

[Michel Dänzer (michel-daenzer)]

(In reply to stevengruspier from comment #1)
> You might be interested in this one Bug Report for wanting to add different
> refresh rates to mutter: https://bugzilla.gnome.org/show_bug.cgi?id=781296

This is an Xwayland issue, the Wayland compositor has nothing to do with it.

[Daniel van Vugt (vanvugt)]

*** Bug 104847 has been marked as a duplicate of this bug. ***

[Daniel van Vugt (vanvugt)]

My monitor runs at 59.95Hz and this is what I see:

Xwayland:

$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
428 frames in 5.0 seconds = 85.552 FPS
300 frames in 5.0 seconds = 59.993 FPS
301 frames in 5.0 seconds = 60.006 FPS
301 frames in 5.0 seconds = 59.983 FPS
301 frames in 5.0 seconds = 60.016 FPS WRONG
300 frames in 5.0 seconds = 59.999 FPS
300 frames in 5.0 seconds = 59.986 FPS
301 frames in 5.0 seconds = 60.004 FPS
301 frames in 5.0 seconds = 60.002 FPS
300 frames in 5.0 seconds = 59.998 FPS

$ weston-info | grep refresh
  width: 1920 px, height: 1200 px, refresh: 59.950 Hz,

Xorg:

$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
481 frames in 5.0 seconds = 96.146 FPS
300 frames in 5.0 seconds = 59.952 FPS
300 frames in 5.0 seconds = 59.956 FPS
300 frames in 5.0 seconds = 59.943 FPS
300 frames in 5.0 seconds = 59.948 FPS RIGHT
300 frames in 5.0 seconds = 59.953 FPS
300 frames in 5.0 seconds = 59.951 FPS
300 frames in 5.0 seconds = 59.949 FPS
300 frames in 5.0 seconds = 59.956 FPS
300 frames in 5.0 seconds = 59.947 FPS
300 frames in 5.0 seconds = 59.952 FPS

[Kristoffer Brissman (brisse)]

Running my monitor at 119.88hz, yet xwayland is locked to 60fps. Causes some severe stutter in anything from scrolling through webpages in Firefox to games running through xwayland. This bug is a big reason why I currently do not use Wayland for everyday tasks.

[Subdiff (subdiff)]

For fullscreen applications using the Present extension you should try again with xorg-server 1.20. The new per window flip mode should allow now arbitrary refresh rates in this case.

[Daniel van Vugt (vanvugt)]

Note that users of gnome-shell will still have a problem even if Xwayland is fixed. Because gnome-shell is locked to 60.00Hz too (bug 781296).

[Daniel van Vugt (vanvugt)]

^^^
https://bugzilla.gnome.org/show_bug.cgi?id=781296

[Daniel Stone (daniels)]

Resolving as fixed with the Xwayland Present implementation in 1.20; the Mutter 60Hz issue is a bug in Mutter which is being tracked there.

[Daniel van Vugt (vanvugt)]

Upstream says the fix is in v1.20, and that appears to be in cosmic-proposed now.

[Tempel-julian (tempel-julian)]

Is there some setting that needs to be toggled first? My situation is still the same for me as with 1.19 with KWin on Plasma 5.13. My desktop runs with fluid 73Hz, but e.g. browsers with Xwayland are still stuttery 60fps@73Hz.

[Michel Dänzer (michel-daenzer)]

With KWin, the changes referenced in comment 8 only have an effect for fullscreen applications. (With gnome-shell, it can also have an effect for windowed apps using client-side decorations)

[Tempel-julian (tempel-julian)]

Confirmed, an Xorg game looks fluid here in fullscreen (unfortunately not fullscreen mode of Firefox). Thank you, so I suppose it's up to the DE devs then.

Is it planned or possible to turn vsync entirely off for Xorg fullscreen applications like games to e.g. have lowest input latency? I suppose doing unwanted vsync could also interfere with FreeSync once it's there in free driver stack one day.

[Michel Dänzer (michel-daenzer)]

(In reply to tempel.julian from comment #11)
> Is it planned or possible to turn vsync entirely off for Xorg fullscreen
> applications like games to e.g. have lowest input latency?

This can be controlled to some degree via the usual GLX/EGL functionality, which can be overridden via the driconf vblank_mode setting. Beyond that, it's up to the Wayland compositor.

> I suppose doing unwanted vsync could also interfere with FreeSync

Not really. The only difference with FreeSync is that the length of the vertical blank period can vary within bounds, other than that it works more or less exactly the same as fixed refresh.

> once it's there in free driver stack one day.

The Wayland compositor will also have to support it.

[Daniel van Vugt (vanvugt)]

Upstream says:

"Resolving as fixed with the Xwayland Present implementation in 1.20"

So fixed in cosmic.

[Shmerl (shmerl1)]

What is the way to do it in XWayland and KWin for borderless fullscreen like in Wine (not true fullscreen)? I'm testing The Witcher 3 in Wine+dxvk, and framerate is cut at 60 fps in KWin/XWayland.

[Daniel van Vugt (vanvugt)]

For me, Xwayland seems to be locked around 58Hz now, which is a bit weird for a monitor that is 59.95Hz. But that's also a new bug so should be discussed elsewhere.

[Michel Dänzer (michel-daenzer)]

(In reply to Shmerl from comment #13)
> What is the way to do it in XWayland and KWin for borderless fullscreen like
> in Wine (not true fullscreen)?

I suspect "borderless fullscreen" with kwin is the same as windowed as far as Xwayland is concerned.

(In reply to Daniel van Vugt from comment #14)
> For me, Xwayland seems to be locked around 58Hz now, which is a bit weird
> for a monitor that is 59.95Hz.

This is because the granularity of X server timers is 1 ms.

> But that's also a new bug so should be discussed elsewhere.

The fundamental issue is still that windowed apps use a timer instead of tying into the Wayland compositor's refresh cycle.

[Shmerl (shmerl1)]

(In reply to Michel Dänzer from comment #15)
> (In reply to Shmerl from comment #13)
>
> I suspect "borderless fullscreen" with kwin is the same as windowed as far
> as Xwayland is concerned.
>

Is it possible to do anything about it in the compositor, or it's a design limitation?

I opened KWin bug to track this: https://bugs.kde.org/show_bug.cgi?id=401797

[Michel Dänzer (michel-daenzer)]

(In reply to Shmerl from comment #16)
> Is it possible to do anything about it in the compositor, [...] ?

Possibly. Basically, the compositor must not reparent a "borderless fullscreen" X11 window to a larger X11 window (e.g. for drop shadows).

[Shmerl (shmerl1)]

I opened a follow up bug, for more focus: https://gitlab.freedesktop.org/wayland/wayland/issues/67

[Shmerl (shmerl1)]

Sorry for confusion, I opened it for the wrong project. It should have been for Xorg, so here is the correct one:

https://gitlab.freedesktop.org/xorg/xserver/issues/20

[Shmerl (shmerl1)]

(In reply to Michel Dänzer from comment #17)
> Possibly. Basically, the compositor must not reparent a "borderless
> fullscreen" X11 window to a larger X11 window (e.g. for drop shadows).

Re-posted response from KWin developers to this idea in the new bug:
https://gitlab.freedesktop.org/xorg/xserver/issues/20