When we launch clients they currently stay in the same session as
weston, and share its controlling terminal. This means hitting ctrl-c
in weston's controlling terminal will send SIGINT to the clients as
well. It also means SIGHUP will be propagated to our launched clients
if weston's controlling terminal is closed.
While generally not harmful, this behaviour is not beneficial, and
is present by default and not by design.
Problems arise when launching weston in a debugger, as a ctrl-c sent to
the debugger will be propagated not only to the debugger, but all the child
processes sharing weston's session. This results in weston-desktop-shell
being killed by the ctrl-c that was intended to stop weston for debugging.
If weston-desktop-shell is killed within 30 second of startup, it will
result weston performing a clean shutdown. This clean shutdown can
make debugging a little too surprising.
Ostensibly, clients launched via weston_client_launch will be wayland
clients that terminate cleanly on their own if weston is killed, so
there should be no need for them to remain in weston's session to
catch ctrl-c from its controlling terminal. Nor should they need a
controlling terminal for their general operation.
Use setsid() to move them to their own session, devoid of controlling
terminal, to make using a debugger a little less confusing in some
cases.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
signalfd interacts badly with gdb's signal trapping - when hitting
ctrl-c in a debugger attached to weston, weston will receive the
signal. This results in weston exiting cleanly when the intent
was to use gdb to interfere with its operation.
Trapping SIGINT was introduced in commit 50dc6989 which ensured we
would call wl_display_terminate() on SIGINT or SIGTERM to clean
up our socket.
Killing weston with SIGINT is quite common for several developers,
so it's important to preserve this clean shutdown behaviour, so
we can't naively stop trapping SIGINT entirely.
Instead, use the sigaction() function to trap SIGINT, and have
the SIGINT handler send weston SIGUSR2 (SIGUSR1 is already
used by xwayland). SIGUSR2 can be trapped in the proper wayland
way via wl_event_loop_add_signal(). This way we can properly
break our event loop and clean up on SIGINT, but we can also
have gdb intercept SIGINT.
There are other ways around this, but I'm hoping this one allows
people to continue using ctrl-c to stop weston, and doesn't
require additional project specific gdb knowledge.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We've been trapping SIGQUIT for a "clean shutdown" since commit 3cad436a
However, sources such as:
http://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html
indicate we probably shouldn't be trapping it at all, as the intent of
SIGQUIT is to leave a core file and debug artifacts from the run.
We should perform the minimal amount of clean up to ensure the system isn't
left in an unusable state - but these days that's performed by other
software such as logind.
We can safely stop trapping SIGQUIT entirely.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
We can use it just once to define a string instead of having preprocessor
conditionals sprinkled about the code.
Signed-off-by: Derek Foreman <derek.foreman@collabora.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>
Use the common helper provided by the shell-utils helper dependency,
rather than rolling our own.
This commit currently introduces no functional change to
fullscreen-shell, as the 'curtain' provided by shell-utils behaves
identically to the previous solid-color surface created by
fullscreen-shell, given the parameters provided to
weston_curtain_create().
However, now that a common weston_curtain implementation is being used
rather than an open-coded variant, future changes to the implementation
of weston_curtain will result in changes to this code called by
fullscreen-shell, although it is intended that these will not result in
any user-visible behavioural changes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Unlike desktop-shell and kiosk-shell, the fullscreen-shell does not link
with the common shell-utils helpers. This is largely because
fullscreen-shell is largely in 'maintenance mode', seeing little more
than occasional bug fixes or changes required to accommodate new
interfaces.
This commit adds a dependency from fullscreen-shell to use the
shell-utils helper, in order to allow fullscreen-shell to use the new
weston_curtain infrastructure, rather than continuing to open-code the
common pattern of creating a surface and view consisting only of a solid
colour for the background of fullscreen surfaces which do not wholly
cover the output.
In doing this, the 'surface_subsurfaces_boundingbox()' function is
removed, as this has been duplicated between the fullscreen-shell and
the common helper 'library'.
There is no functional change within this commit, as the two functions
were identical, other than a change to the comment which identifies a
known bug within this helper.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Use the helper we have for these, rather than open-coding.
This commit is not believed to result in any functional changes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
shell-utils contains a number of helpers which are currently in use by
both desktop-shell and kiosk-shell. In order to extend this use to
fullscreen-shell as well (which can benefit from reusing the
weston_curtain infrastructure to be able to create solid-colour views
which may or may not be opaque, as well as one function within
fullscreen-shell which was copied wholesale to shell-utils), we need to
create a separate Meson dependency object, and avoid the existing
pattern of including the source from shared/ within the source list for
each shell.
This requires creating a new top-level directory for these shared helper
functions which are required by each shell, but are not part of
libweston in and of itself.
shell-utils depends on libweston-desktop; libweston-desktop depends on
libweston; libweston depends on shared.
Thus it is not possible to expose a dependency object from the shared/
directory which declares a dependency on the libweston-desktop
dependency, as Meson processes directories in order and resolves
variable references as they are parsed.
In order to break this deadlock, this commit creates a new top-level
directory called 'shell-utils' containing only this file, which can be
parsed by Meson after libweston-desktop (making the libweston-desktop
Meson dependency variable available to the build file to declare a
dependency on that), but before the shells (making the new Meson
depenendency object available to each shell which wishes to use it).
This commit contains no functional changes to any observable code.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Use the common infrastructure we have, rather than open-coding again.
In changing to the common weston_curtain infrastructure which was
introduced in a previous commit, there are two small functional
derivations.
After adding the view to a layer, we explicitly call
weston_view_geometry_dirty(). This is believed to have no functional
impact, as weston_views have their geometry-dirty flag set when they are
created.
weston_surface_damage() is also called to ensure that the surface is
scheduled for a repaint. As there is currently no good common mechanic
in the common code to ensure that output repaint will occur, due to the
damage propagating outwards from the weston_surface, we are forced to
call this to predictably ensure that the output will be repainted after
we have made this change to the scene graph which should result in the
user observing the new content being repainted.
It is possible that these changes are not strictly required in order for
the correct behaviour to occur. However, it is felt that explicitly
adding these calls is perhaps the least fragile way to ensure that the
behaviour continues to be correct and breakage is not observed,
especially with both view mapping and surface damage identified as areas
for future work which could be beneficial to Weston. If it is felt that
these calls can be removed, then this is certainly possible at a later
stage.
Lastly, there are many users within desktop-shell of the common pattern
of creating a weston_curtain and inserting it into the scene graph to be
painted. These users have been an area of both theoretical concern and
real-life observed fragility and breakage recently. By making each user
follow a common and predictable pattern of usage, each user is no longer
its own special case. This should make it easier to make the
desktop-shell codebase more robust, not only simplifying the codebase,
but improving observed behaviour.
In doing this, it is hoped that future structural and interface changes
become easier to make, allowing us to improve some of the more difficult
corners of the libweston API.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This will allow us to create a solid weston_buffer as well, since we
need to store that separately.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Just as we do for fullscreen backgrounds, reuse the curtain infrastructure
for focus animations.
This introduces a small functional change, in that the surface's output
is no longer directly assigned. Instead, we call
weston_view_set_output() ourselves. As setting the weston_view's
position (done from the common helper function of weston_curtain_create
which has been introduced in previous commits) will call
weston_view_set_position(), the view's geometry will be dirtied as a
result.
When the geometry of a weston_view is dirty, it is marked to be updated,
which will occur whilst traversing the view list during output repaint.
This occurs for every view which is currently assigned to a layer; when
building the view list, any view reachable through the view list whose
geometry is dirty will have its position recalculated and an output
assigned. Doing so results in the surface's current output being
updated.
It is believed that there is no functional impact from the
weston_surface not having a primary output assigned between creation and
output repaint being called.
Signed-off-by: Daniel Stone <daniels@collabora.com>
desktop-shell's focus surfaces want to reuse this, but they don't want
to capture the input, instead allowing it to fall through.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rationalise it a little bit so we don't need pre-declarations of static
functions, and the order of creation more closely matches the others,
including making the same calls to explicitly set the output.
Doing this makes the behaviour match the other users of the same code
pattern. In making them the same, we make desktop-shell code a little
less magically divergent where people might wonder what the correct
pattern is to use. After we have moved all users to a uniform pattern,
later commits are then able to migrate these users to common helper
code, which reduces code duplication, improves code clarity as it is no
longer necessary to wonder about the exact semantics of every
special-case user of this common pattern, and makes it easier to make
interface changes which improve and clarify the patterns which are
prevalent throughout the desktop-shell code.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Dirtying the geometry only sets a flag on the view saying that the
geometry is dirty, so we don't need to do it twice back-to-back.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Opaque regions are in surface co-ordinate space, not global co-ordinate
space, so the region should be anchored to (0,0).
Signed-off-by: Daniel Stone <daniels@collabora.com>
Not all solid-colour views want to be opaque: sometimes we use them with
non-opaque alpha values in order to shade views underneath them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Given that we have a struct for argument params, we might as well use it
rather than have them split between the struct and native params. For
consistency between the implementations, this also includes a shift from
float to int positioning for the base offset within the compositor's
global co-ordinate space.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The name implied that it was a surface in and of itself, rather than
parameters used by a helper to create a surface and view.
Rename it now that we have weston_curtain as a name, and clean up
initialisers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
create_solid_color_surface actually returns a weston_view that it
creates internally. Since weston_solid_color_view is long and dull,
rename it to weston_curtain.
Signed-off-by: Daniel Stone <daniels@collabora.com>
desktop_shell_removed() won't get called when we shut down, so
explicitly destroy the fullscreen black view.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We could overflow a local buffer if there were more than ten million
concurrently active displays within the current user's session. This
seems vanishingly unlikely, and harmless, but does at least squash a
compiler warning emitted by gcc 12+.
Signed-off-by: Daniel Stone <daniels@collabora.com>
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>
Tablet shell was removed in 873b515aee in
2013. Time to remove the hopefully last reference to it.
We also gained kiosk shell in the mean time, so mention that instead.
Yes, it's a bit of a lie, because we also have ivi-shell and
fullscreen-shell, but I heard they might be on their way out, so I
didn't add them here.
Would be nice to add kiosk-shell in the SHELLS section too, but in this
patch I am only concerned about dropping the tablet shell reference.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Looks like at least from 2016 onwards the gbm-format option has also
been recognized in an output section.
Time to document that.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Since 62a9436417 the gbm-format option has
recognized all pixel formats listed in libweston/pixel-formats.c.
Clarify what pixel formats can be used.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This option is used only with the DRM-backend. Options in weston.ini(5)
should be either generic or for backends that do not have their own man
page yet.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This option is used only with the DRM-backend. Options in weston.ini(5)
should be either generic or for backends that do not have their own man
page yet.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We have a string helper which wraps asprintf(). Uses that one because it
clears out the destination string, but also it won't return the number
of bytes unlinke asprintf().
Fixes warnings like:
warning: ignoring return value of ‘asprintf’ declared with attribute
‘warn_unused_result’.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
weston_config_section_get_double() was not covered with tests before.
This patch follows the testing style already present in the file.
Cannot use ZUC_ASSERT_EQ() here, because that would convert the values
to integers before comparison. Luckily, simple strict equality
comparison works here, because we are testing conversion to float, not
the results of lossy calculations.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This was the only file in Weston using WL_EXPORT on its own line. Fix
the style to follow everything else.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Using `pixel_format_get_info()` can result in formats being
reported as `UNKNOWN` when used on compositors other than Weston.
As `weston-simple-dmabuf-feedback` somewhat succeeds `wayland-info`
as tool for `zwp_linux_dmabuf_v1` debugging from version 4 on, copy
the approach from the later for these cases.
Signed-off-by: Robert Mader <robert.mader@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>
Everywhere else where use this trick, we also have 'used' in the
attributes, except here. Make this consistent.
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/517
Signed-off-by: Pekka Paalanen <pekka.paalanen@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>
When using the libseat launcher, there is one more detail to take care:
stop libseat from managing the VT.
A normal user does not have permissions to manage a VT, so launching
would just fail. In this use case you also do not want to be managing
the VT, because your normal desktop is already owning the seat
associated with the VT.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Give a little more details about how running Weston via ssh or serial
terminal is best done, now that launcher-direct and weston-launch are
gone.
Hopefully the removal of launcher-direct also makes less people run
Weston as root, when seatd is the privileged process. Running 'weston'
as root might still work through libseat's builtin backend without
seatd.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Now that launcher-direct and weston-launch are gone, libseat takes their
place.
Enable libseat support by default to give users a hint in case they miss
either of those.
People who used to get launcher-logind when libseat support was disabled
will now be using logind through libseat. This should not cause any
regressions, and if it does, we want to hear about them, because the
separate logind-launcher is also planned to be deprecated in the future.
Disabling logind-launcher by default is left for when it actually gets
deprecated.
In case someone does not have libseat available but do have logind
running, they can just disable libseat support.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
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>
Derek Foreman
Sören Meier
Michael Tretter
Daniel Stone
nerdopolis
Pekka Paalanen
Marius Vlad
Robert Mader
Michael Olbrich