Bug 103282 - XWayland refresh rate locked to 60 Hz
Summary: XWayland refresh rate locked to 60 Hz
Status: RESOLVED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: XWayland (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Wayland bug list
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 104847 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-10-15 13:28 UTC by grmat
Modified: 2018-06-18 14:04 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.


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.