Bug 103282

(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

(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.

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

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

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.

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).

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

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.

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.

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)

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.

(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.

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.

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.

(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.

(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

(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).

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

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

(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