Bug 103282

Summary: XWayland refresh rate locked to 60 Hz
Product: Wayland Reporter: grmat
Component: XWaylandAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: bugzilla, bwat47, daniel.van.vugt, jan.public
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
See Also: https://launchpad.net/bugs/1746163
Whiteboard:
i915 platform: i915 features:

Description grmat 2017-10-15 13:28:00 UTC
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.
Comment 1 stevengruspier 2017-10-18 00:21:16 UTC
(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
Comment 2 Michel Dänzer 2017-10-18 13:25:21 UTC
(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.
Comment 3 Daniel van Vugt 2018-01-30 05:41:50 UTC
*** Bug 104847 has been marked as a duplicate of this bug. ***
Comment 4 Daniel van Vugt 2018-01-30 05:42:38 UTC
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
Comment 5 Roman Gilg 2018-05-13 11:07:11 UTC
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.
Comment 6 Daniel van Vugt 2018-05-16 02:30:21 UTC
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).
Comment 7 Daniel van Vugt 2018-05-16 02:30:46 UTC
^^^
https://bugzilla.gnome.org/show_bug.cgi?id=781296
Comment 8 Daniel Stone 2018-06-04 07:53:37 UTC
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.
Comment 9 tempel.julian 2018-06-18 11:00:58 UTC
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.
Comment 10 Michel Dänzer 2018-06-18 11:05:58 UTC
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)
Comment 11 tempel.julian 2018-06-18 11:39:09 UTC
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.
Comment 12 Michel Dänzer 2018-06-18 14:04:25 UTC
(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.
Comment 13 Shmerl 2018-12-05 04:15:26 UTC
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.
Comment 14 Daniel van Vugt 2018-12-05 04:18:45 UTC
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.
Comment 15 Michel Dänzer 2018-12-05 15:10:54 UTC
(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.
Comment 16 Shmerl 2018-12-05 20:12:45 UTC
(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
Comment 17 Michel Dänzer 2018-12-06 08:42:14 UTC
(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).
Comment 18 Shmerl 2018-12-06 22:27:22 UTC
I opened a follow up bug, for more focus: https://gitlab.freedesktop.org/wayland/wayland/issues/67
Comment 19 Shmerl 2018-12-07 01:40:33 UTC
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
Comment 20 Shmerl 2018-12-07 06:07:07 UTC
(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

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.