With the help of a newly introduced function, weston_desktop_surface_set_orientation(),
this patch adds missing tiled states from the xdg-shell protocol.
The orientation state is passed on as a bitmask enumeration flag, which the
shell can set, allowing multiple tiling states at once.
These new states are incorporated the same way as the others, retaining
the set state, but also avoiding sending new configure events if nothing
changed since previously acked data.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Changing the mode will destoy the GBM surface for the output. As a result all
corresponding BOs are deleted regardless of the drm_fb refcount.
While a commit is pending, the last_state may contain a reference to such a BO.
So delay the mode switch until the commit is finished and the reference is
release.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
weston_output_set_position() currently assumes the output is enabled, but
we could be using weston_output_move() to configure an output that hasn't
yet been enabled.
If that's the case, we don't want to send signals or perform setup that
will eventually happen when the output is enabled anyway.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Make sure we don't enable an output that overlaps with other enabled
outputs.
We should probably do something similar when moving outputs, but we can't
realistically do that right now, so at least leave a comment explaining
why we're ignoring that case.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is pretty counter-intuitive, and should probably happen outside of
the core in the front end while configuring the outputs.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
When an atomic commit fails then the output will be stuck in
REPAINT_AWAITING_COMPLETION state. It is waiting for a vblank event that was
never scheduled.
If the error is EBUSY then it can be expected to be a transient error. So
propagate the error and schedule a new repaint in the core compositor.
This is necessary because there are some circumstances when the commit can fail
unexpectedly:
- With 'state_invalid == true' one commit will disable all planes. If another
commit for a different output is triggered immediately afterwards, then this
commit can temporarily fail with EBUSY because it tries to use the same
planes.
- At least with i915, if one commit enables an output then a second commit for a
different output immediately afterwards can temporarily fail with EBUSY. This
is probably caused by some hardware interdependency.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
As wayland-backend is blitting the output decorations into the output
buffer itself, it pretends towards the pixman-renderer that there is no
decorations area. The pixman_image_create_bits() call wraps the
previously allocated buffer with an offset so that pixman-renderer will
paint in the right position.
The bug is that this pixman image was using the original buffer width
and height, instead of the composited area width and height. So the
pixman image looks too big to pixman-renderer, but the renderer didn't
care. The image being too big does risk access out of bounds in
pixman-renderer.
I found this when I was making renderers explicitly aware of the
frambuffer size and resizing, added asserts, and they surprisingly
failed. This fixes that.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The GL format and type are already recorded with pixel_format_info, use
that instead of a switch on Pixman formats.
Less special-casing, less dependency on Pixman formats.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Everywhere we are standardising to drm_fourcc.h pixel format codes, and
using struct pixel_format_info as a general handle that allows us to
access the equivalent format in various APIs. In the name of
standardisation, convert weston_compositor::read_format to
pixel_format_info.
Pixman formats are defined CPU-endian, while DRM formats are defined
always little-endian. OpenGL has various definitions. Correctly mapping
between these when the CPU is big-endian is an extra chore we can
hopefully offload to pixel-formats.c.
GL-renderer read_format is still defined based on Pixman format, because
of the pecualiar way OpenGL defines a pixel format with
GL_UNSIGNED_BYTE. That matches the same Pixman format on big-endian but
not the same drm_fourcc.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Sometimes you will have a pixman_image_t and you need the corresponding
drm_fourcc format.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A following patch is going to need the introduced 'area' and 'fb_size'
variables. Until then though, a little hack is needed to avoid no-gl
builds failing with error: variable 'fb_size' set but not used.
While starting to use struct weston_geometry, convert also the input and
opaque regions to use it. This shortens and simplifies the code, as we
can drop the roughly duplicate code of doing stuff for with vs. without
a frame.
No change in behavior, this is pure refactoring.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Pixman image formats are CPU-endianess dependent while drm_fourcc are
not. Standardise around drm_fourcc because DRM-backend uses them anyway.
This also makes Pixman-renderer use the same format as GL-renderer will
prefer on headless.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This allows for setting a buffer offset without having to make it part
of the wl_surface.attach request. This is useful for e.g. setting a DND
surface icon hotspot offset when using Vulkan; or doing the same with
EGL without having to use wl_egl_window_resize().
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
In the future we'll have multiple output support, which makes storing
the peer list on an output rather tricky.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The paint_node_z_order_list contains all views, not just the ones visible on the
current output. So all views are moved to the primary plane when one output
does not support planes.
This will be relevant with multiple backends: When an output without plane
support is rendered then the views of all other outputs are removed from
the current planes and the corresponding outputs will be repainted
unnecessarily.
So only reset the plane if the view is actually on the current output.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
It is only enabled by a debug key binding, currently not tested at all,
and is seems it doesn't really work, so let's remove it. This also
removes it from the man page.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
A head may have its output protection set before it is attached to an
output. Recompute the output protection whenever a head is attached to
make sure it correctly set in output.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
This skips over xdg-shell v4, which can be implemented with no changes
as it's just another optional event.
v5 adds a capabilities event, which we send to inform clients of the
window manager's capabilities.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This protocol allows clients to create single-pixel RGBA buffers. Now
that we have proper support for these buffers internally within Weston,
we can expose them to clients.
This bumps the build container version, as we now depend on
wayland-protocols v1.26.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This patch acts as bandaid in the core compositor to avoid the renderer
doing a flush after the buffer has been released. Flushing after release
can happen due to problems in the internal damage tracking, is violating
the protocol, and causes visible glitches.
A more proper fix would be to handle compositor side damage correctly.
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Acked-by: Daniel Stone <daniel.stone@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Since b38b735e20, 'backend-drm: Remove Pixman conditional
for keep_buffer' the Pixman renderer keeps its own reference to buffers
when attached to surfaces, rather than flipping keep_buffer variable for
the surface. Problem is that when switching from the Pixman render to
the GL would not work and could result in a crash upon first repaint.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When an output is destroyed then the output state is freed immediately. In this
case, the plane state is only partially destroyed because it is the currently
active state. This includes the buffer reference.
Without the output, the plane will not be updated any more until it is used by a
different output (if possible) or the output returns and the plane is used
again.
As a result, the buffer reference is kept for a long time. This will cause some
applications to stall because weston now keeps two buffers (the one here and
another one for a different output where the application is now displayed).
To avoid this, do a synchronous commit that disables the output. The output
needs to be disabled anyways and this way the current state contains no
buffers that would remain.
`device->state_invalid = true` in drm_output_detach_crtc() is no longer
needed, because drm_output_detach_crtc() is called only when initialization
failed and the crtc was not yet used or in drm_output_deinit() when the
crtc was already disabled with the new synchronous commit.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Introduced with e0a858a5f2, commit 'weston-debug: Introduce
weston_log_subscription and weston_log_subscriber objects'. We don't
really return a weston_log_subscription so let's remove it.
Some newer doxygen detects this and we are treating warning as errors.
Fixes#594
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This was introduced in a partial MR, where the later commits in the new
multi-GPU MR fully fix it, but the initially cherry-picked ones don't.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We were only destroying these when the parent display removed the output
global. Do it on shutdown too, so we can avoid leaking it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We're going to need this to properly send xwayland events later, so add
API to get the current x,y co-ordinates of a shell surface and add it to
the kiosk and desktop shells.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
noop-renderer needs to actually access the buffer content, to ensure
that the bad-buffer test works. This was previously done using a
volatile variable, but clang rightly pointed out that the variable
access had no effect (since the volatile stack variable was never read
from, and the source is not volatile), so 9b0b5b57dd changed it to be
explicitly marked it as unused to suppress the compiler warning.
Unfortunately suppressing the warning still leaves the compiler free to
optimise out the access.
Replace the variable decorations with actually using the result of the
read, so we can be really sure that it's never going to be optimised
away.
Signed-off-by: Daniel Stone <daniels@collabora.com>
ca9bb01fe6 made it so that we already set shm_buffer, width, height,
etc, in the core. There's no need for the renderer to do this.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Our positioning of override redirect windows falls apart when an
app is on the fullscreen layer, because we end up putting its
menus and tooltips beneath it. This patch raises the special
override redirect layer to be just below things like on-screen
keyboards (and, unfortunately, above things like panels).
There is no perfect way to deal with this problem, especially
for content like tooltips that don't come with transience hints.
In some cases override redirect menus could be better placed by
using the parenting/transience information provided with them
at map time, and we should probably do that at some point, but
that would still leave us with tooltips below full screen
applications, and the need for this layer change.
based on a patch
Co-authored-by: Hideyuki Nagase <hideyukn@microsoft.com>
Co-authored-by: Steve Pronovost <spronovo@microsoft.com>
Co-authored-by: Brenton DeGeer <brdegeer@microsoft.com>
I changed the layer position and the comments, so:
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
It's not really useful to have libweston without libweston-desktop. It's
also very little code.
Merging both into the same DSO will allow us to cut out a bunch of
indirection and pain.
Signed-off-by: Daniel Stone <daniels@collabora.com>
A view shouldn't be mapped if a surface isn't mapped, and it shouldn't
be in the scene graph if it isn't mapped either. Print when this happens
so you can see more from the debug.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Currently the idle_repaint_source is removed when the output is destroyed.
This covers the most common case: When a monitor is unplugged then the
corresponding DRM output is destroyed and not just disabled.
However, outputs can be explicitly disabled by the shell. In this case the
output is not removed and idle_repaint() may be called for a removed
output.
Remove the idle_repaint_source in weston_compositor_remove_output() to fix
this. And reset the variable to ensure that the source can be created
again.
Removing the source in weston_output_release() is now no longer necessary
since it calls weston_compositor_remove_output().
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
weston_compositor_reflow_outputs() assumes that all output are positioned from
left to right with no gaps in the same order in which they where created.
If the shell moves an output with weston_output_move() then this assumption is
no longer true. So stop reflowing the outputs in the case. The shell is now
responsible for positioning all outputs as needed.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
This is another followup to ffc011d6a3
("backend-drm: check that outputs and heads are in fact ours") which missed
some places.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
By moving the application of view_alpha after pre-multiplication we can
simplify main() considerably.
The cost is that for straight-alpha input or color_pipeline() we might
be doing three multiplications more than before. However,
a) the cost of running color_pipeline() probably dominates anyway, and
b) to get straight-alpha input you have to use a future Wayland
extension that probably won't be advertised without color management.
So we keep the optimization for the simple case (no color management)
while potentially incurring a small cost on the heavy case (with color
management).
Thanks to Pierre-Yves Mordred for the inspiration in
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/889#note_1411774
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Now that we have the if-else ladder to call color_pipeline() only when
necessary, and since only color_pipeline() needs undo-premult, move
undo-premult into color_pipeline().
This is a small step towards improving code readability.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We always talk about "view alpha", so the name variable in the fragment
shader the same. Now it's clear without the comments, making the code
easier to read overall.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
There is missing dependency on linux-dmabuf-unstable-v1-server-protocol.h
header file in backend-headless, backend-drm and backend-x11. That files
do not depend on that header, in fact. But by this moment they've had
that implicit dependency due to linux-dmabuf.h header.
With specific set of meson configure options the protocol header is not
generated at the right time, what causes build error in 100% cases using
small amount of building threads (from -j1 to -j8).
Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko@unikie.com>
This is a followup to ffc011d6a3
("backend-drm: check that outputs and heads are in fact ours") which missed
some places.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
This uses the legacy DRM API it incomplete and no longer works anyways.
At this point, weston is no longer DRM master, so these calls fail with
"Permission denied".
So just remove the corresponding code.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
If a surface or a view is not mapped, then we should not be trying to
paint it. Check if this is the case and ensure that we only insert
paint nodes for mapped surfaces & views.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: #621
Now we've got a wrapper which tells us whether or not the surface has
valid content, use it.
The 'XXX' comment was removed because it's the same pattern as every
other surface-role implementor: if the surface is not mapped but does
have valid content, then map it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Marius Vlad
Michael Olbrich
Derek Foreman
Pekka Paalanen
Jonas Ådahl
Daniel Stone
Joshua Watt
Hideyuki Nagase
Ivan Nikolaenko