Refresh rates with multiple monitors
ppaalanen at gmail.com
Tue Jun 13 09:20:20 UTC 2023
On Tue, 13 Jun 2023 01:11:44 +0000 (UTC)
Joe M <brainsnacks at yahoo.com> wrote:
> Hi, I was wondering about the internals of Wayland (wl_compositor?)
> with multiple physical screens/displays attached. I'm using EGL so if
> those details are contextual to the answer please include if possible.
I wrote a bit of an introduction here first to give some depth to the
answer, so pardon for straying a bit.
The first thing to recap is that Wayland is not a program you could run.
Wayland is not an implementation but only a language that applications
and display servers use to talk to each other.
- A Wayland compositor is a display server.
- An application is a Wayland client.
- An output is usually a monitor.
- Repainting is the action of rendering a new composition for an output.
Wayland does pose some assumptions, especially related to a window that
happens to be on multiple outputs simultaneously:
- Each output is allowed to be repainted independently of others.
- An output can be repainted regardless of client actions at any time.
- A client draws the image of a window, and that one image is used on
any outputs as necessary.
- A client does not need to draw, if the window image does not need
- From client perspective a window has a single update loop
(timings), therefore it can synchronise to only one timing source
(output) at a time.
Wayland does not define how or when Wayland compositors should repaint
their outputs. Wayland also does not define what to use for the timings
of a window. Compositor implementations decide on those details as they
A popular approach is for a compositor to repaint each output
independently and without tearing, using whatever is the latest image
for each window.
> As I understand, there is one global wl_display. Is there always one
> wl_compositor too?
That is inconsequential.
Protocol objects (wl_proxy - an instance of, say, wl_compositor) are
always private to a Wayland client, but multiple protocol objects even
from different clients can refer to the same underlying "thing", like
a wl_output object refers to an output.
Sometimes there is no particular "thing" to refer to. Both wl_display
and wl_compositor essentially refer to the compositor as a whole. They
are merely pieces of API. Our jargon calls wl_compositor a "singleton
global". wl_display is even more fundamental and on client side it
represents the Wayland connection to a compositor.
> I'm able to create a surface in two different apps (or multiple
> instance of the same app), and call "set_fullscreen" on each one.
> Wayland (or, weston, I guess?) does the right thing and puts them on
> separate physical screens.
> Now, eglSwapBuffers takes as parameters the EGLDisplay and the
> EGLSurface. Is the vsync that the two apps observe at all
> interdependent, as a result of the display singleton?
No fundamental dependency there. What actually happens depends on how
the compositor in question is implemented and on which outputs the
windows are shown.
> If one monitor's mode is 30Hz and the other 60Hz, will both apps be
> constrained to the 30hz refresh?
I believe most, if not all, compositor implementations allow each app
to have its own pace according to the monitor it is on. IOW, no.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel