On Tue, 13 Jun 2023 01:11:44 +0000 (UTC) Joe M <brainsna...@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
pgppPkh7r7fdK.pgp
Description: OpenPGP digital signature
