For now limited to coefficients and ranges that are typically
supported by KMS drivers. We notably leave out alpha modes and
chroma locations for now.
The protocol initialization is guarded by the WESTON_CAP_COLOR_REP
backend capability and thus not enabled anywhere yet.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Introduce support for the commit-timing protocol to allow applications
to attach a presentation time to a content update.
We use the repaint timer to schedule content updates in advance of
the frame time when they should be displayed.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Currently this shouldn't result in any change, since the times we pass in
are real presentation times.
Later when commit-timing lets applications pass in arbitrary times, it
will be more interesting.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Validate repaint_msec so it's not longer than a refresh interval.
Negative repaint windows will cause problems for frame scheduling in the
future, so remove them.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
When we add timed transactions, we'll want to feed them through the repaint
timer, so share it to allow this in the future.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
In the near future commit-timing + VRR combined will want to have better
than the 1ms precision we're allowed now.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
After moving the drm-backend's scene graph dump, it now always occurs when
repaint_status is REPAINT_AWAITING_COMPLETION, which loses useful timing
information we used to have.
Add timing information for the REPAINT_AWAITING_COMPLETION state, and also
add the expected presentation time.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
When we need to use VRR, we'll miss a potential frame deadline, fail to
deliver a frame, then stop the repaint loop. When a late frame comes
in, we deliver it immediately at the start of a new repaint loop.
The only time we really need to deliver a frame immediately is at
the start of the loop, otherwise we can use the same repaint window
behaviour as any other time.
This still leaves some room for improvement, as we still don't try
to avoid Vactive.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Move some code around so we only derive the next repaint from the next
presentation time and the repaint window once at the end of the function.
In many cases we now subtract the repaint_msec value from "now", but that's
ok because any time earlier than "now" will still result in firing the timer
at the same time.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
These are used to determine if the previous frame was displayed with
tearing, which is useful in determining when the next frame time should
be.
Store these as a step towards breaking the frame time calculations out
of output_finish_frame into a separate function.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
For the upcoming commit-timing protocol, we're interested in when a
scheduled repaint will be displayed, so let's keep track of both the
repaint time and the anticipated presentation time.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This fixes a bug in version 1 where we should've been giving a 0 refresh
for VRR, and introduces version 2 where we're allowed to give a compositor
chosen rate for VRR.
We currently chose the mode's native refresh rate.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Add support for the fifo protocol, which allows an application to submit
a content update that can only be applied after the previous content
update has been active for a display refresh.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Now that we have surface-state application streamlined, it's fairly easy to
add a framework for deferring content updates.
This will be used soon for fifo and commit timing. For now, the
weston_surface_state_ready() call that makes any of this do something
will always return true.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Keep track of whether a view has any unoccluded pixels on an output,
use this information to add a weston_surface_visibility_mask() function
that we'll use later.
Since the visibility information is calculated at repaint, and invalidated
by some (but not all) state updates, we'll keep track of when the previous
repaint's status is still valid by watching surface status bits.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Seems like it makes sense to have it there, and this cleans up a bunch of
paths where we return status bits so a caller can do this.
We can also drop the explicit setting of view_list_needs_rebuild, as it's
going to happen automatically when applying subsurface order.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Latch is the moment when the compositor considers updates for an upcoming
redraw. Nothing that takes place after an output latches for repaint can
change what will be repainted.
This needs a more explicit treatment now that upcoming transactional
protocols require things to happen immediately after the latch (ie:
when it's too late to change the upcoming render).
Add an explicit latch point, a signal to tap for testing, and some asserts
to make sure nothing can violate the inevitability of the current render
state.
Note that currently latch is tied to repaint such that we only claim to
have latched when a repaint will happen. In a future commit this will lead
to forcing the repaint loop to fire without damage when the fifo protocol
needs something to happen after a latch. This could be an area for
future improvement.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We're going to be adding protocols (commit-timing, fifo, syncobj) that
allow deferred surface content updates.
It makes sense to start the perfetto flow ids from the surface state so
we can track a flow from creation (ie:commit) to presentation.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
With the addition of the weston_output_set_ready() call, the shell fade
animation is now started during the very first repaint. The first repaint
doesn't have an accurate frame_time for the previous repaint, as none has
occurred yet.
Since we set the time base for an animation based on the output's frame
time the second time the animation is run, we end up setting the shell fade
start time to 0, and the first real repaint advances the timer to the real
time, generating a warning and truncating the animation.
Instead of tracking the number of animation frames, let's just continue to
reset the time base until we finally get a non-zero time.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
A destroyed paint node must be rebuilt at great cost the next time the
view is displayed on an output.
Keep the paint node around and just remove it from the z order list instead
of destroying it outright.
fixes#1072
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
As weston_compositor_build_view_list() marks all the outputs needing a
paint node rebuild of the re-order list, embed the paint node status
update to ALL_DRITY into straight into weston_output_build_z_order_list().
This way we'll latch it on the view list rebuild.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This de-couples the compositor view build list from the paint node
ordered list to allow a more finer grain over what lists we need to
rebuild upon repaints.
As a consequence to that this avoids a trip over from the compositor
when paint nodes are destroyed and no longer re-created upon rebuilding
the view list.
Fixes: #1070
Fixes: abfe874a ("core: Don't rebuild view list on surface-local changes")
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This was brought up in issue 1063. The assertion in
weston_presentation_feedback_present_list() will trigger randomly during
repeated suspend/resume testing, presumably while a client is animating
and asking for presentation feedback.
drm_output_start_repaint_loop() has a path where drmWaitVBlank() is able
to pull a good timestamp for the last vblank. This results in a call to
weston_output_finish_frame() with a good timestamp and
WP_PRESENTATION_FEEDBACK_INVALID in the flags.
Previously it was assumed that in such case the presentation feedback
list cannot have any entries. This assumption is false. It is possible
that while the output is in idle state, a client will post an update to
a surface and ask for presentation feedback on it. This should trigger
drm_output_start_repaint_loop() with a non-empty feedback list.
It is unclear why this problem was not seen in the wild much more often.
Start-repaint-loop does not present anything by definition, it only acts
to synchronize the output repaint loop with the (hardware) scanout
cycle. Therefore no feedback must be sent there. As
WP_PRESENTATION_FEEDBACK_INVALID flag indicates no feedback must be
sent, use it to avoid calling
weston_presentation_feedback_present_list().
References: https://gitlab.freedesktop.org/wayland/weston/-/issues/1063
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We've added a curtain to the shells so at startup we have something to
render, but this causes a flicker if someone is trying to have a seamless
transition from boot to weston.
Add a ready flag that allows the shell to indicate repaints are safe, so
we can remove the curtains and have no wasted frames at startup.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This already existed for surface, so it is trivial to add.
This will let the upcoming plane state reuse code notice a format change.
This is handy because a client might respond to dmabuf feedback by changing
formats, with the expectation that doing so would land content on a plane.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This was in the late update because attaching buffers is something only
the renderer cares about.
However, the upcoming drm plane state re-use patches need to know if the
buffer changed before assign_planes, so we need this in the early update.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The DRM documentation states:
> Unless explicitly specified (via CRTC property or otherwise), the active
> area of a CRTC will be black by default. This means portions of the active
> area which are not covered by a plane will be black, and alpha blending of
> any planes with the CRTC background will blend with black at the lowest zpos.
See https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-abstraction
This means the view for the primary plane does not need to cover the
whole output and black areas of the scene-graph can be left out.
Doing so has various benefits - most importantly it:
1. allows us to use the plane-only path in more situations and with one
less plane, reducing memory bandwidth usage.
2. opens the path to offload arbitrary background colors in the future.
Iterate over the all visible paint nodes, remove solid-opaque-black
views so they are not considered for plane assignment and aggregate a
region that is later used to assign the primary plane.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
is_fully_opaque notably applies to opaque single-pixel-buffer views
without opaque region. Using it should be purely an optimization.
The check for alpha in turn may fix bugs in certain conditions.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Let's just make them show up in the perfetto traces when they actually
happen, so it's a little easier to see how much benefit we derive from
trying to defer them.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
since abfe874a51 we no longer do a full view list rebuild after a
surface_set_size(), but that was ensuring we always had an up to
date transform in the repaint loop.
Add a weston_view_update_transform() here to dodge the assert in
the repaint loop.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This was missed in e169b77430
when leaving planes in the scene graph meant we no longer needed
to calculate this clip.
It's just a few wasted cycles, so no backport required.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Instead of clipping the visible region to the output, clip the entire
region to the output first and save that, then create the visible region
from that.
Now we have both the clipped and visible view regions that the backends
may want to do plane assignment stored in paint nodes, so we can save
some duplicate math.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Assign planes in the future could benefit from visibility information on
pnodes being up to date.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is a step towards having correct visibility information in
assign_planes. Instead of visible_next and visible, we now have
visible_previous and visible, with visible being set up in the
visibility update function instead of being copied across in
the late update.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
In the future I plan to move the paint node visibility calculation, and
in doing so the different callers to paint_node_damage_below() will have
different visibility regions.
Add the region as a parameter.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We're supposed to generate an INVALID_SIZE error if the buffer size isn't
an integer multiple of the scale.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Allow dictating which color format we'd like to use. This introduces the
front-end side and the core parts, leaving the EDID parsing and DRM
connector property for later patches.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When we're going through assign_planes and repaint, give the backend an
opportunity to see what's changed during this repaint.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If a surface changes size or opaque region, or a view changes position,
we don't need to rebuild the entire view list from scratch: we can just
rebuild what's changed and nothing else.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Nothing uses this, and it was also being set incorrectly, as it would
return true when there was no damage to actually be flushed.
Signed-off-by: Daniel Stone <daniels@collabora.com>
In order to be more in line with weston_view_is_opaque() - which we
use in most cases to set the value - and ensure the expectations of
existing places in the code are honored, see usages in both
draw_paint_node() implementations.
An exception here are holes - these always need to get painted as fully
opaque in the renderer path.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
This test is critical, so only do it once, and throw some asserts around
to make sure we don't mess it up.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
