Rather than punching through to set the surface as a solid colour,
attach an actual weston_buffer to it instead.
This becomes the first user of attaching non-client-generated buffers
to a weston_surface. As a result, it is necessary to introduce a
function which will allow compositors and shells to attach a buffer to a
surface. weston_surface_attach_solid() is therefore introduced as a
special-purpose helper which will attach a solid buffer to a
weston_surface.
It is not intended as a general-purpose mechanism to allow compositors
to attach client-generated buffers to surfaces, as doing so would have
unknown effects on this core part of the compositor itself.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we're checking to see if a view is suitable to go on a plane, check
for (and reject) solid-colour buffers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The Pixman renderer keeps its own reference to buffers when attached to
surfaces, through its surface state: just use that instead.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Refactor the buffer-type check slightly so we can handle solid-color
buffers, which we do exactly nothing with.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Currently solid-colour displays (e.g. the background for fullscreen
views) is implemented by a special-case weston_surface which has no
buffer attached, with a special punch-through renderer callback to set
the colour.
Replace this with a weston_buffer type explicitly specifying the solid
colour, which helps us eliminate yet more special cases in renderers and
backends.
This is not handled yet in any renderer or backend, however it is also
not used by anything yet. Following commits add support to the renderers
and backends.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When the renderer/backend indicate that they do not need a surface's
buffer content to be preserved, most often because they have copied it,
simply downgrade the buffer reference to 'will not access', rather than
drop the buffer reference altogether.
Signed-off-by: Daniel Stone <daniels@collabora.com>
In the original conception, a weston_buffer_reference indicated that the
underlying contents of the wl_buffer would or could be accessed, so
wl_buffer.release must not be sent until the last reference was
released, as the compositor may still use it.
This meant that renderers or backends which copied the buffer content -
such as the GL renderer with SHM buffers - could only send a buffer
release event to the client by 'losing' the buffer reference altogether.
The main side effect is that `weston-debug scene-graph` could not show
any information at all about SHM buffers when using the GL renderer, but
it also meant that renderers and backends grew increasingly exotic
structures to cache information about the buffer.
Now that we have an additional buffer-reference mode (still referring to
the weston_buffer/wl_buffer, but not going to access its content), we
can allow the weston_buffer_reference and weston_buffer to live as long
as the buffer itself, even if we do send a release event.
This will enable a bunch of backend and renderer deduplication, as well
as finally making scene-graph more useful.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Add a mode argument to weston_buffer_reference which indicates whether a
buffer's storage may/will be accessed, or whether the underlying storage
will no longer be accessed, e.g. because it has been copied. This will
be used to retain a pointer to the weston_buffer whilst being able to
send a release event to the client.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Keep the weston_buffer alive for as long as at least one of the
underlying wl_buffer or a backend usage exists.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Make sure we don't die if we're asked to flush the damage on a SHM
buffer which has subsequently been destroyed.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We currently allow a weston_buffer to outlive the underlying wl_buffer
iff the renderer/backend has cached it. Currently the 'is this buffer
valid?' test relies on looking for the validity of the weston_buffer
itself; shift these tests to looking at the validity of the underlying
resource.
Signed-off-by: Daniel Stone <daniels@collabora.com>
y_inverted meant that the buffer's origin was (0,0), and non-inverted
meant that the buffer's origin was (0,height). In practice, every buffer
was 'inverted' into our natural co-ordinate space that we use
everywhere.
Switch to using an explicit origin enum to make this more clear.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rather than calling accessors (wl_shm_buffer_get etc) to figure out
which type our buffer is, just look in the structure.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rather than open-coding various resource -> type accessors, just stick a
type enum in the buffer struct.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rather than only filling weston_buffer information when we first come to
use it, add an explicit hook so we can fill the dimensions the first
time the buffer's attached.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Make sure we only import dmabufs where the underlying pixel_format is
known: if we can't reason about the buffer content, we're not entirely
likely to be able to display it well.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When we first see a buffer attached, we create a weston_buffer for it.
The weston_buffer doesn't contain any useful information in and of
itself; that's left to renderers to populate later.
Switch this to doing it in the core at the first opportunity, at least
for SHM and dmabuf buffers; EGL buffers will follow in the next commit.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We already have the buffer in the caller, and every no-op implementation
will want to access the buffer. So might as well pass it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The comment about needing to have destroyed images is somewhat less true
now that we actively avoid doing so.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 0b51b02c5e ("gl-renderer: Don't re-import dmabufs")
Add some logging helper functions along with two log scopes for debug
and extremely verbose debugging information.
Also add tangentially related logging for the synchronize event, so
the debug stream isn't empty right now. The vast majority of verbose
usage will come later.
Co-authored-by: Steve Pronovost <spronovo@microsoft.com>
Co-authored-by: Brenton DeGeer <brdegeer@microsoft.com>
Signed-off-by: Hideyuki Nagase <hideyukn@microsoft.com>
Signed-off-by: Steve Pronovost <spronovo@microsoft.com>
Signed-off-by: Brenton DeGeer <brdegeer@microsoft.com>
There are currently compatibility issues between FreeRDP's implementation
of the RemoteFX codec and Microsoft's implementation.
Perhaps this will be fixed in the future and this option can go away,
but for now it's necessary to have a way to disable the codec if the
windows client is going to be connecting to a weston server.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Seems that we're still missing layer clean-ups, with the touch
calibrator being one of them. Call the appropriate function when
shutting down the compositor instance.
Fixes: #603
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Server generated key repeats are ignored - and they don't generate
matching release events. We early return to avoid generating events
for them.
We also need to push the idle inhibition counting after that early
return to prevent breaking idle inhibition with unmatched events.
Co-authored-by: Steve Pronovost <spronovo@microsoft.com>
Co-authored-by: Brenton DeGeer <brdegeer@microsoft.com>
Signed-off-by: Hideyuki Nagase <hideyukn@microsoft.com>
Signed-off-by: Steve Pronovost <spronovo@microsoft.com>
Signed-off-by: Brenton DeGeer <brdegeer@microsoft.com>
Refactor some of rdp.c into a header file.
Co-authored-by: Steve Pronovost <spronovo@microsoft.com>
Co-authored-by: Brenton DeGeer <brdegeer@microsoft.com>
Signed-off-by: Hideyuki Nagase <hideyukn@microsoft.com>
Signed-off-by: Steve Pronovost <spronovo@microsoft.com>
Signed-off-by: Brenton DeGeer <brdegeer@microsoft.com>
We've already allocated the listener by the time we hit this failure,
so we must exit through the path that frees it.
Co-authored-by: Steve Pronovost <spronovo@microsoft.com>
Co-authored-by: Brenton DeGeer <brdegeer@microsoft.com>
Signed-off-by: Hideyuki Nagase <hideyukn@microsoft.com>
Signed-off-by: Steve Pronovost <spronovo@microsoft.com>
Signed-off-by: Brenton DeGeer <brdegeer@microsoft.com>
In 913d7c15f7 stricter error checking was
introduced to the strtol call, which broke reading backlight values.
Since every sysfs backlight file ends with a newline.
As noted in a comment in the previous MR to prevent damaged pointers
after calling asprintf, replace every asprintf call with str_printf.
Previous-MR: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/543
Signed-off-by: Sören Meier <soerenmeier@livgood.ch>
The repaint_data is entirely backend specific. Moreover, it is only used by the
drm backend, while other backends ignore the repaint data.
There will always be only one repaint active, thus, there is no need to pass the
repaint data from the outside.
The repaint_data breaks with the multi-backend series, which calls repaint begin
for all backends to get the repaint_data. The repaint_data of the last backend
will then be passed to all other backend. At the moment, this works, because the
drm backend is the only backend that implements the begin_repaint call.
Another option would be to track the repaint data per backend in the compositor,
but actually, it the backend needs to track state across the calls, it's its own
responsibility.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
The pending_state is already stored in the backend and can be directly retrieved
from there.
This avoids involving the compositor in passing state between the repaint
phases for a single backend.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Fbdev backend was deprecated in the Weston 10.0.0 release with
6338dbd581. Before that, I suggested
already in 2019 to remove it, but it was too soon then. Now it seems the
final voices asking for fbdev to be kept have been satisfied, see the
linked issue.
Fbdev-backend uses a kernel graphics UAPI (fbdev) which is sub-par for a
Wayland compositor: you cannot do GPU accelerated graphics in any
reasonable way, no hotplug support, multi-output support is tedious, and
so on. Most importantly, Linux has deprecated fbdev a long time ago due
to the UAPI fitting modern systems and use cases very poorly, but cannot
get rid of it if any users remain. Let's do here what we can to reduce
fbdev usage.
I am doing color management related additions to libweston which require
adding checks to every backend. One backend less is less churn to write
and review.
Libweston major version has already been bumped to 11, so the next
release will be Weston 11, without fbdev. enum weston_compositor_backend
entries change their numerical values.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/581
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These are supported by some other compositors already.
Add them to the list so `weston-simple-dmabuf-feedback`
reports them correctly.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
The built-in backend of libseat requires users to enable a logging
level in order for libseat to start writing out log messages. For that
to happen we split out the info and error log level messages into the
compositor's log scope, while debug level messages go into a dedicated
scope.
With that, this patch brings in a new scope, called libseat-debug, which
users need to explicity create a subscription for it as to retrieve/have
access to debug message coming out of libseat. Note that by default we
have a subscription for the log-scope so any errors/info from libseat
would be displayed to the user.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Otherwise, the client will assume that dragging is in progress and remains in
that state forever.
This can happen when weston processes the mouse up event just before the
start_drag() arrives.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
This doesn't work with any of the launchers we've kept. Remove the option
and all the bits that handle it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Daniel Stone
Hideyuki Nagase
Derek Foreman
Marius Vlad
shierote
Sören Meier
Michael Tretter
nerdopolis
Pekka Paalanen
Robert Mader
Michael Olbrich