Rather than using wl_surface::commit to count the frame rate, use the
painted frames for each paint node, and implictly the surface.
This happens in the output repaint paint node list parsing, and includes
also a perfetto counter to display it.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This is a continuation of work from
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/24
This patch adds a surface callback frame rate counter to the scene-graph
debug scope.
The timer interval is set by default to 1 second. This use a timer to
periodically compute the current frame callback commits in that interval
as the surface frame rate per timer interval. Note that is solely based on
wl_surface::commit call.
Together with this, this patch also adds perfetto counter that stores
the same computed frame rate. This means the counter will be updated on
the next interval timer when the timer is armed/fired such that that
perfetto drawings will show up in a window period of time (interval).
Helpful to identify what frame rates clients achieve to debug
performance issues as to provide an objective common group. Using the
debug-scope aggregates all surfaces at the same place. This is not based
on the GPU whatsoever so it can also work on SHM type of buffers.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Signed-off-by: Changwoo Cho <changwoo.cho@lge.com>
This way we can use the same ID when for perfetto counters to allow
to identify clients much easier.
Also, renamed "surface" with "unlabelled surface" when get_label function
is not set.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Shells need to find their own internal structures for weston_outputs.
Let's make that process trivial instead of a list walk.
Add a getter and setter for this private data and use it from the kiosk
shell.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
When in VRR mode, repainting without a wait might happen instantly,
so do it.
This is likely not the best long term solution, but is ok for now
while weston's vrr support is experimental.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Query the vrr_capable property for heads, and expose it to frontends.
Currently we only support game mode VRR, but expose VRR capabilities as
an enum in anticipation of supporting QMS VRR in the future.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This can end up being the first function to touch a surface in a flow,
which leads to confusing traces.
Just trace the function without a flow instead.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We add a flow_id when we touch a surface that has no flow id, and clear
it when we flush damage, so a flow line will be drawn connecting any
operations on a surface and terminating in its damage clear.
This is less useful for surfaces that never receive explicit damage after
they're set up, such as background images and the panel, as they might
never show up as a damage track, and have an unterminated flow line.
For surfaces that do show up on a damage track, we can follow them back to
the commit that caused them to update.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This shouldn't cause any problems with WESGR output, since the timing
will still be very close to what it was previously.
With perfetto tracing, this helps with event ordering. The final flush
event will now come after the damage accumulation function calls instead
of before. This is better when we add flow lines in a following commit.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Try to roughly achieve feature parity with WESGR by processing the same
timepoint data and feeding it into perfetto, with output and surface
specific tracks.
We can't match the way WESGR draws this information, because perfetto has
a different display paradigm, but we can try to at least make sure all the
same information is visible in an understandable way.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Just pepper some perfetto tracing about.
These functions are picked mostly to provide some visibility into repaint,
but in the future we might want to add more sites, such as input
processing.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This borrows heavily from the Mesa project's perfetto instrumentation, and
for now just adds perfetto to the build and a collection of useful macros
for adding trace points.
The atomics have been cargo culted in - Weston currently has no need of
such things, but I guess they're harmless for now and could be useful if
we consider threads in the future.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
I'll be adding perfetto instrumentation, which will want to know the
timepoint name without having to parse it.
For now, just pass an enum and add a helper function to convert to strings.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
It's currently assumed by backends that renderers discard
renderbuffers on resize. This commit introduces a new
weston_renderbuffer_discarded_func callback that must be passed at
renderbuffer creation in order to be notified of discarded events from
the renderer. This discarded event could potentially be reused later
by renderers on other occasions without having to change backends once
they get proper support for that.
On output resize, once a discarded event handler fails (returns false)
on a renderbuffer, all the remaining renderbuffers in the output list
go stale and weston_renderer_resize_output() ultimately returns false
for backends to be notified of the failure.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Renderbuffers currently have a libweston-internal base data structure
with a ref-counting system to handle their lifetime. The problem is
that renderers keep a ref to all renderbuffers in a list per output
(to deal with damages) and that it prevents backends from releasing
renderbuffer resources when not needed anymore. Renderbuffers are then
only released (last ref removed) when the output is destroyed or
resized. dma-buf renderbuffers even expose a dedicated function
remove_renderbuffer_dmabuf() to explictly request the release of their
resources.
This commit proposes to get rid of the ref-counting system by exposing
a single entry point to explicitly destroy all types of renderbuffers
from the renderer.
Instead of removing a renderbuffer from its output list and dropping
its ref when the output is resized, this commit also introduces the
concept of stale renderbuffers which consists in releasing the
resources of a renderbuffer when it's discarded by the renderer while
keeping it in the output list, with a stale state, until it's
explicitly destroyed.
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
This is problematic as we don't have namespacing for these and some of
the macros can interfere with other defines.
This reverts commit 8634c7e349.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When the head is already destroyed, its global resource still can be
accessible by the client, which leads to a UAF crash.
This sets the head's global resource's user data to null before the
head is destroyed, and when the `bind` request is being handled but the
object's user data is null, do what we do when the the head's output is
null.
Signed-off-by: Paul Pu <hui.pu@gehealthcare.com>
If the scene graph is empty at repaint the renderer will do nothing to the
buffer. On some platforms this results in displaying garbage, and on
platforms where we use frame buffer compression we can cause longer
lasting visual problems.
Make sure we never get here with an empty scene graph.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
A client can call get_xdg_output() at any time. If the output was destroyed,
then all output resources are orphaned. This includes clearing the user data of
the resource.
This can happen, for example, when a monitor or HDMI switch quickly toggles the
HDMI hotplug pin.
So check if a head is associated with the resource. If not, just create the
resource and then return immediately.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Doing these in the wrong order breaks content protection, and breaks
placing direct-display paint nodes on underlays.
Fixes: 827e2276 ("gl-renderer: Draw holes on primary plane for the view on underlay")
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
As weston_windowed_output_get_api needs ARRAY_LENGTH() move helpers to a
libweston/ so other users can re-use that instead of re-defining these
all over. Easier for other front-ends to make use of them.
With this change windowed-output-api.h also includes the helpers header.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
We can startup with the display already in type1 content protection mode.
When this happens, we call weston_output_dirty_paint_nodes() on a display
that hasn't yet been enabled. The paint node list isn't initialized yet,
so we crash.
We don't actually need to touch the paint nodes here anyway, as
weston_output_damage() ensures a repaint if the ourput is enabled, and
weston_output_dirty_paint_nodes() just forces calculation of things
unrelated to protection, and we'll override most of that in
maybe_replace_paint_node() if necessary when we get there.
Just drop the weston_output_dirty_paint_nodes() call to stop the
crash.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Since c4eb15d453 we keep a copy of
native mode parameters, however we forgot to initialize the
native mode parameters in some situations, which breaks the
output mirroring code when it sees uninitialized data.
Fixes c4eb15d453Fixes#949
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This would allow to screen-share a particular output like the
following:
[output]
name=vnc
same-as=DP-5
[output]
name=rdp-0
same-as=DP-4
[output]
name=pipewire
same-as=eDP-1
Both 'vnc', 'pipewire' 'rdp-0' remote outputs would then be a
screen-share 'DP-5', respectively, 'e-DP1', or the 'DP-4' DRM output.
Currently, this is intended only for VNC, RDP and PipeWire remote outputs.
This patch exports weston_output_set_position(), and uses that for
overlapping a remote output with a native DRM one, rather than using
weston_output_move() as that has a side-effect when reflowing outputs
from shells.
Further more creating this remote output is driven entirely by compositor
signal events such that enabling an DRM native output would enable the
remote output, while disabling the native would have the same outcome
for the remote one.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This avoids dereferencing a possible stale pointer, and allows
retrieving the modeline/refresh later on when one needs to retrieve
those values. This is a temporary band-aid.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
commit 5fe02dc68e partially resolved the issue in #937 by bringing back
the old band-aid solution for layer moves. However, since the events of
commit bf228370ff and following commits we have a problem with
subsurfaces leaving garbage behind when minimized - see #366 which was
probably fixed for a while then became broken again.
When we minimize a view that has subsurfaces, by moving it to a layer
outside of the scene graph, we need to be sure to handle the subsurface
views - which follow their parent's layer instead of having
weston_view_move_to_layer() explicitly called.
Do this by assuming layers with an empty link are not part of the scene
graph and unmapping views when they're moved to these layers. This will
recursively unmap the subsurface views.
We can now remove the band-aid paint node destroy, as the unmap process
will destroy paint nodes as appropriate.
Fixes 5fe02dc68eFixes#937Fixes#366
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
For the following sequence, weston will not trigger a repaint:
1. create the main surface
2. create another surface and attach it as a sub-surface to the main surface
3. set the sub-surface to desync
4. attach a buffer to the main surface and commit it
5. attach a buffer to the sub-surface and commit it
Step 5 should cause the sub-surface to become mapped. However, Weston fails to
schedule a repaint in that case, so the sub-surface will not appear until
something else causes a repaint on that output, e.g. the main window.
And sub-surfaces are special when it comes to mapping because
weston_surface_is_mapped() will not return true until the parent surface is
mapped as well. So right now, weston_surface_map() may be called multiple times
and it will send the map_signal each time.
So to fix all this and make it clearer:
1. define a separate weston_surface_start_mapping() function to make it clearer
that the (sub-)surface may not be fully mapped at the end
2. check surface->is_mapped explicitly to ensure that the sub-surface is only
mapped once.
3. call weston_view_update_transform() for all views of the sub-surface when the
parent surface is already mapped to ensure that a repaint for all relevant
outputs is triggered.
The new test checks this by waiting for a frame event for the first subsurface
commit. Without these changes, the test will block until it is killed by the
timeout.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
The main differences is the split of cm_surface functionality with
cm_surface and cm_feedback_surface.
There can only be one cm_surface to set, unset image descriptions. When
cm_surface is destroyed, the image description is automatically unset.
There can be multiple feedback_surfaces for one surface though.
Now the "preferred_changed" signal can be an initial event.
Creator params now have a new request: set_luminances.
Signed-off-by: Joan Torres <joan.torres@suse.com>
Commit f2486c8b96 removed some helper functions for layer changes, but
the loop to delete stale paint nodes was elided.
We need to delete paint nodes on a layer change to ensure damage is tracked
properly.
Fixes f2486c8b96Fixes#937
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This new public API is intended to deliver EDID etc. information to the
frontend. The use case here is display colorimetry, to help the frontend
craft output image descriptions (color profiles).
The frontend will need to link to and use libdisplay-info to make use of
this. This avoids having to replicate in libweston the high-level API
that libdisplay-info already has. The libdisplay-info API is also likely
to be extended, and it is not nice to play catch-up with it.
As a di_info can only be destroyed by calling into libdisplay-info,
libweston core can only ensure it has already been freed. There is not
enough reason to make libweston core depend on libdisplay-info, only the
DRM-backend is.
It will be up to DRM-backend to ensure display_info is updated and
device_changed is set only when necessary.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Instead of attaching and flushing damage when performing
weston_surface_copy_content, just return the contents as the renderer
currently knows them.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We've got output->scale, output->current_scale, output->original_scale and
output->native_scale.
output->scale is apparently just a weird temporary variable, and has led
to some confusing bugs.
Remove it entirely.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
commit 0f99e081c4 broke xwayland client
input regions. The xwayland window manager sets input regions in the
pending state without going through the function that sets the
WESTON_SURFACE_DIRTY_INPUT bit.
Just add the dirty bit to the xwm code.
Also, fix the whitespace error the same patch introduced.
fixes 0f99e081c4
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Whenever an output repaint fails, we leave the presentation-feedback
requests hanging. Requeue them back to the surface so the next repaint
attempt can collect them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fundamentally, the flags are a property of each paint node, rather than
each view as such. Move them over there so it gets a little less painful
to work with.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add a boolean member named need_hole in weston_paint_node, which is used
to indicate whether the renderer should draw through hole on primary
plane when rendering.
For paint node whose view are placed on the underlay plane, this
member should be set to true, otherwise it is false.
Signed-off-by: Chao Guo <chao.guo@nxp.com>
This reverts f843ba34d1 ("drm-backend: limit
reset/restart to output of a failed commit") and actually solves the problem
correctly.
The pending_state is no longer valid at this point, so it cannot be used to
determine the outputs of the current commit. So only clear will_repaint when
starting to repaint, so it can be used to determine which outputs of a device
were actually repainted and use it to reset/restart those outputs.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
After c08a6ff8 moved attach to the render loop, we have a bad situation
when clients delete an attached shm buffer. We try to query the stride
at attach time, but the shm_buffer has been destroyed, and we crash.
Instead of carefully fixing that, I've instead stored the stride at
buffer creation time (as we already do with buffer width and height).
This lets attach succeed in the gl-renderer, keeping the old texture data
available for any upcoming rendering.
Fixes: #927
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Tested-by: Connor Abbott <cwabbott0@gmail.com>
We can skip posting damage beneath planes that are fully translucent,
but that doesn't mean we can skip posting damage beneath planes that
are not fully opaque.
Add a check for content that is entirely blended, and use that instead.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
weston_output_schedule_repaint() already checks the compositor state but
idle_repaint() is called asynchronously so the state may have changed.
Check the state again and abort if necessary.
Without this the DRM compositor might execute a modeset in
drm_output_start_repaint_loop() which should not happen while sleeping or
offscreen.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Currently only the return value of the last backend that implements
repaint_flush() is actually used. That only works because the drm backend is the
only backend that implements repaint_flush().
In the drm backend only the return value of the last device is used. And if a
failure is actually detected, then all repainted outputs of all backends are
reset. This can trigger asserts:
weston_output_schedule_repaint_reset() (or _restart()) will change the state of
the output but the backend that did not cause the failure will still call
weston_output_finish_frame().
The same thing can happen with multiple devices in the drm backend. Or outputs
get stuck if an error is dropped.
Since the drm backend is the only one that implements repaint_flush() anyways,
move the failure handling into the backend and make it device specific.
This way only the outputs that need it are reset.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
When a repaint is triggered then not all backends may have outputs that need to
be repainted.
Check which outputs will be repainted first and then repaint only the backends
that need it.
This way unnecessary repaint_begin() and repaint_flush()/repaint_cancel() can
be skipped and errors are handled for each backend separately.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Stop writing weston_buffer::shm_buffer when weston_buffer::type is not
WESTON_BUFFER_SHM. Instead, explicitly write to the union field
that corresponds to the buffer type.
Also add a comment why we clear the shm_buffer/dmabuf/legacy_buffer
pointer here.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
With attach only being called at render time, the dmabuf can be deleted
along with its private data before we attach for the first time.
Let's move the first-time logic into its own callback to call at
buffer setup time instead.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
