The predictive frame scheduler builds upon the presentation scheduler,
adding a delay based on the measured CPU and GPU time required to
prepare a frame to place the frame event as close as safely possible to
the commit deadline.
Previously, needs_frame was only set specifically when a non-damaging
update was required, and would only be cleared when the backend
committed the frame.
Under the new frame scheduler, needs_frame is always set when a frame is
scheduled, with effectively a single scheduling path for all change
sources, and needs_frame must have been true for a frame to be emitted.
Drop wlr_scene_output_needs_frame to make it clear that such a check is
no longer meaningful.
Headless present events aren't suitable for the present scheduler. This
new scheduler is a good place for headless' existing frame logic to go,
so move it into there.
With this decoupling, there's nothing tying the scheduler to the
headless backend, hence the generic name.
This changes the behavior of wlr_linux_drm_syncobj_surface_v1 to
automatically signal release of previous commits as they are replaced.
Users must call wlr_linux_drm_syncobj_v1_state_add_release_point or
wlr_linux_drm_syncobj_v1_state_signal_release_with_buffer to delay the
signal as appropriate.
Add color_representation to wlr_output_state, holding color
representation metadata about the primary buffer. This can be set
using wlr_output_state_set_primary_color_representation() and a
new enum value WLR_OUTPUT_STATE_COLOR_REPRESENTATION in
wlr_output_state.committed indicates when this data is present.
Also add color-representation to wlr_output, and discard
color-representation in wlr_output_state if it matches what's already
been committed to the output.
Currently we send wl_surface.enter/leave when a surface is hidden
and shown again on the same output. In practice, this happens very
often since compositors like river and sway enable and disable
the scene nodes of surfaces as part of their atomic transaction
strategy involving rendering saved buffers while waiting for
clients to submit new buffers of the desired size.
The new strategy documented in the new comments avoids sending
redundant events in this case.
wlr_box_intersection generates a new box based on the intersection of
two boxes. Often we simply want to know *if* two boxes intersected,
which we can answer much cheaper.
Add wlr_box_intersects, in similar vein as wlr_box_contains_box but
returning true for any overlap.
Exposing libinput_tablet_tool from libinput allows compositors
to set tool specific configuration options like pressure range
and eraser button behavior.
See 'libinput_tablet_tool_*()' functions which require a
'libinput_tablet_tool' handle:
https://wayland.freedesktop.org/libinput/doc/1.30.0/api/group__config.html
(libinput 1.30.0, latest at the time of writing).
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.
