Refresh rates with multiple monitors

[Pekka Paalanen]

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.

Hi,

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.

Some vocabulary:
- 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
  changes.
- 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
see fit.

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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20230613/51f01eb3/attachment.sig>