We need to know which output we're on, and the surface type plus output
uniquely identifies us, so just pass that in.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We only have one of those per output, and we need to dig them out later,
so just store a direct pointer to them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Make background and panel surfaces do the right thing: map the surface
when it first gets content applied to it, and only move the view around
when required.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We only want one background and/or panel per output. If another one
comes up, tell the client it's done something very bad, rather than
trying to gently negotiate our way out of the situation.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If our background and/or panel surface already has a view, something
extraordinarily weird has gone on. Don't try to deal with it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
A view is mapped if it's on a layer, so if we find it in a layer then we
don't need to worry about whether or not it's mapped.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The counterpart to weston_surface_is_unmapping(). This is valid for the
duration of processing the surface commit.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If a surface has already been mapped, just return early out of
weston_surface_map(), rather than firing the map signal and rebuilding
the view list.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We already have these for global coordinates, now we have them for
surface coordinates too. In addition to removing some unsightly
unadorned coordinate usage, this also adds appropriate coordinate space
id checks at runtime.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is a tricky bit of code and we use it in two places. Let's make a
single implementation.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Document the --additional-devices parameter to Weston to add secondary
DRM devices that will only be used as outputs, but not for rendering.
Fixes: 3c6cfe6bf4 ("backend-drm: add additional-devices to support multi GPU")
Signed-off-by: Marek Vasut <marex@denx.de>
Second try at removing direct logind support. This time more careful
with the documentation, as libseat can still use logind even if we don't
directly use it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This reverts commit 55bf6b5046.
This accidentally removed things that should have stayed - libseat
can still use the logind API, even if weston doesn't directly use
it.
Note that the logind-launcher does not actually build anymore
because breaking changes landed before this revert.
Since we're removing it again right away, I've not taken care to
fix that.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This avoids spreading around the knowledge that the primary backend is
the first backend on weston_compositor::backend:list.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Let weston_compositor_load_backend() return a backend pointer and remove
the backend pointer from struct weston_compositor.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Releasing the buffer reference here works because the backend has seen the
surface and has updated keep_buffer if necessary. With multiple backends
the assumption breaks. The same surface may be visible (now or later) on an
output from another backend. This backend has not seen the buffer yet so it
cannot update keep_buffer.
As a result, the reference is released to early. A surface that is rendered
on a secondary backend first can no longer be placed on a plane on a DRM
backend.
To avoid this, always keep the buffer reference until it is replaced when
multiple backends are involved.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add a paragraph describing multi-backend support to running-weston.rst
and update the --backend parameter documentation in weston.man.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
All backends add themselves to weston_compositor::backend_list now.
Drop the workaround that catches unconverted backends that still set
weston_compositor::backend.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Insert the backend into the weston_compositor::backend_list instead
of setting weston_compositor::backend. The compositor uses this to
determine whether the backend is capable of being loaded simultaneously
with other backends.
The X11 backend can only be loaded as primary backend.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Insert the backend into the weston_compositor::backend_list instead
of setting weston_compositor::backend. The compositor uses this to
determine whether the backend is capable of being loaded simultaneously
with other backends.
The Wayland backend can only be loaded as primary backend.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Insert the backend into the weston_compositor::backend_list instead
of setting weston_compositor::backend. The compositor uses this to
determine whether the backend is capable of being loaded simultaneously
with other backends.
To stay backwards compatible, the VNC backend can be loaded as primary
backend. It also supports being loaded as secondary backend.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Insert the backend into the weston_compositor::backend_list instead
of setting weston_compositor::backend. The compositor uses this to
determine whether the backend is capable of being loaded simultaneously
with other backends.
To stay backwards compatible, the RDP backend can be loaded as primary
backend. It also supports being loaded as secondary backend.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Insert the backend into the weston_compositor::backend_list instead
of setting weston_compositor::backend. The compositor uses this to
determine whether the backend is capable of being loaded simultaneously
with other backends.
To stay backwards compatible, the PipeWire backend can be loaded as
primary backend. It also supports being loaded as secondary backend.
Co-authored-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Insert the backend into the weston_compositor::backend_list instead
of setting weston_compositor::backend. The compositor uses this to
determine whether the backend is capable of being loaded simultaneously
with other backends.
The headless backend can only be loaded as primary backend.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Insert the backend into the weston_compositor::backend_list instead
of setting weston_compositor::backend. The compositor uses this to
determine that the backend is capable of being loaded simultaneously
with other backends.
The DRM backend can only be loaded as primary backend.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add a new --backends command line option and a backends option to the
configuration file that both take a comma-separated list of backends,
similar to the modules option.
The first backend is the primary backend and provides the renderer.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
When multiple backends are loaded simultaneously, they all have
to register their own head change notification listener and
output configuration callback.
To avoid calling output configuration for heads created by other
backends, only iterate over heads that were created from the given
backend by comparing the weston_head::backend pointer to the one
stored in the head change notification listener.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Before loading a backend, clear the weston_compositor::backend pointer
to check whether the backend supports multi-backend operation and adds
itself to the weston_compositor::backend_list.
Keep weston_compositor::backend pointing to the last loaded backend
either way, to allow the calling compositor code to store it away for
later, to check whether a head belongs to a given backend in the output
configuration code. This workaround can be removed after all backends
are converted to be multi-backend aware.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
In preparation for multi-backend support, determine the presentation
clocks that are supported by all backends.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
In preparation for multi-backend support, start/flush/cancel repaint on
all backends by looping over the weston_compositor::backend_list.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
In preparation for multi-backend support, add a list of backends to the
weston_compositor structure. Until backends are converted, this list
just contains the single weston_compositor::backend. Keep that pointer
for now, until the conversion is complete.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add yet another flavor of assertion macros.
Unlike libc assert.h assert(), these cannot be easily disabled by the
build. They also print both the implied expression and the compared
values.
Unlike ZUC macros, there is much less framework code and it can handle
also floating-point types.
The function custom_assert_fail_ can be redefined, meaning that
different compilation units can do different things on failure.
Also the 'compositor' parameter was added to the new macros because we
plan to use these asserts in our log infrastructure, and we want to
print the "failure" messages in the right log scopes. Having the
compositor already in the macros will avoid double work.
Another future possibility is to write specific asserts for the test
suite. So we would be able to write a test suite failure function that
just print what "failed" without aborting.
There is also limited support for custom types.
These are actually pretty similar to libinput's litest macros.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This has been deprecated and non-default for a full release cycle, so
we're going to remove it now.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
And move it back to its place, as we can't differentiante between two
different states: coming back from unmaxized (which makes it so we send
out a widthXheight size matching that of maximized whereas we should send
out 0, 0) and that we're no longer fullscreen. We land basically in the
same spot in both cases, and trying one issue, creates a new one.
Moving the corner case in set_fullscreen makes it so we don't reach both
cases in the same time and avoid introducing other issues.
Fixes: #801
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Replace the finish frame handler logic with a call to the
weston_output_finish_frame_from_timer() helper function that
does the same.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Replace the finish frame handler logic with a call to the
weston_output_finish_frame_from_timer() helper function.
This makes finish_frame_handler() return more exact timestamps
calculated from the previous frame time if the timer callback
was not delayed too much.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Replace the finish frame handler logic with a call to the
weston_output_finish_frame_from_timer() helper function that
does the same.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Extract the finish frame timestamp code and the call to
weston_output_finish_frame() into a new helper function
weston_output_finish_frame_from_timer() that can be reused
by the other timer driven backends sharing the same logic.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Replace the finish frame timer arming logic with a call to the
weston_output_arm_frame_timer() helper function that does the same.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Replace the finish frame timer arming logic with a call to the
weston_output_arm_frame_timer() helper function that does the same.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Replace the finish frame timer arming logic with a call to the
weston_output_arm_frame_timer() helper function that does the same.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
