Implement fifo-v1 protocol: the capability for clients to explicitly queue wl_surface
commits.
The design of the wl_surface interface defines a double buffer, which is intended to support only
(from the point of view of the client) what is sometimes called the 'mailbox' presentation mode:
each request on a wl_surface operates on an accumulated pending state until a .commit request is
issued, immediately and atomically replacing the wl_surface's current state. This means that only
the state related to the latest .commit request will be latched onto.
fifo-v1 is a protocol that aims to support an important use case, namely the FIFO display
presentation mode, which allows to queue the accumulated pending state until the next latching
deadline occurs.
Signed-off-by: Sergio Gómez <sergio.g.delreal@gmail.com>
schedule_frame is only called when the client has submitted damage
and a new frame should be rendered immediately. schedule_frame is
not called when the capture client is waiting for the next frame
but hasn't submitted damage.
Sources implementing a rendering loop based on the capture rate
need to know when a capture client is ready to accept a new frame.
Such sources want to trigger a redraw if and only if (1) they are
dirty (their contents have changed) and (2) the capture client is
ready to accept a new frame.
Replace schedule_frame with request_frame, triggered each time a
client sends a capture request. A flag indicates whether the capture
client has submitted damage.
This makes it so callers no longer need to juggle with raw pixel
pointers anymore, and only need a single wlr_buffer-based codepath.
Additionally, cursors can be unloaded without risking use-after-free.
This is useful in these cases:
- The same surface is added to two different scene-graphs. wlroots
can't figure out on its own which scene-graph should drive the
Xwayland stacking.
- A compositor uses multiple Xwayland servers (e.g. one per app).
wlroots will try to restack surfaces from different Xwayland
instances and this will not go well.
Storing the frame pacing output in a per-scene and per-surface
struct doesn't play well with multiple scenes. outputs_update is
only triggered for outputs the scene knows about, but operates on
all outputs the surface has entered regardless of the scene. Thus
leaving an output on one scene will not refresh the frame pacing
output on other scenes, and these other scenes will operate with
a stale frame pacing output. The surface will not receive any more
wl_surface.frame done events.
This also avoids keeping a dangling pointer around when the frame
pacing output is destroyed but the output isn't added in the scene.
References: https://github.com/swaywm/sway/issues/8885
This avoids hardcoding lists of TFs/primaries in compositors.
I've considered adding wlr_color_manager_v1_create_with_renderer()
instead, but I'm worried that some aspects of the options struct
don't really depend on the renderer, but on the compositor. Such
things are features and render intents.
I've considered returning a const array, but this would tie our
hands if we want to make the renderer advertise the set of
TFs/primaries it supports, instead of having a single flag gating
all of them.
This is needed for cases where the touch operation goes over a region
where no surfaces are present. In this case, we'd want to notify the
touch grabs (for example DnD grabs) that no focus is currently focused.
Fixes d1c88e9 "render/vulkan: add linear single-subpass"
`find_or_create_render_setup` still assumed a single-buffer setup
always implied use of an srgb format
When an FD is passed to xcb_connect_to_fd(), xcb takes ownership of that
FD and is responsible for closing it, which it does when
xcb_disconnect() is called. But the xwayland handler code also keeps a
copy of the FD and closes it via safe_close() in
server_finish_process().
This double-close can cause all sorts of problems if another part of
wlroots allocates another FD between the two closes - the latter close
will close the wrong FD and things go horribly wrong (in my case leading
to use-after-free and segfaults).
Fix this by setting wm_fd[0]=-1 after calling xwm_create(), and ensuring
that xwm_create() closes the FD if startup errors occur.
The important bit here is whether this is using a single or two
sub-passes. The flag isn't used for anything else.
Preparation for an upcoming one-subpass codepath.
Upon leasing, the wlr_drm_lease_connector_v1 will be automatically clean up by the wlr_output
destroy handler. There is no need for the wlr_drm_lease_manager to keep track of leased connectors.
