When we're selecting our renderer, use the enum rather than two
mutually-exclusive booleans to not use the no-op renderer.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Instead of passing --shell=foo-shell.so, just pass --shell=foo, whilst
accepting the old form for compatibility.
Whilst we're at it, document the --shell argument in the manpage and
README.
Signed-off-by: Daniel Stone <daniels@collabora.com>
These shell utils functions are potentially useful to other shells as
well, so make them widely available.
Renamed all functions to weston_shell_utils namespace.
No functional change, copied ad litteram.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Use parse_simple_mode() to allow configuring the VNC framebuffer size
with a mode property in weston.ini, like this:
[output]
name=vnc
mode=1280x720
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
To make it reusable, extract parse_simple_mode() from
wet_configure_windowed_output_from_config().
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
While the --backend parameter looks like it takes a file name, it really
is selected from a list of supported strings that are then funneled
through a translation to enum weston_compositor_backend [1].
Because all backend parameters are of the form "...-backend.so", and
writing "--backend=...-backend.so" is boring, allow the --backend option
to match the backend name without "-backend.so" suffix instead.
For example, this allows to use "--backend=headless" instead of
"--backend=headless-backend.so".
Update help text and documentation. Keep the old way working for
backwards compatibility.
[1] 50dbf38514 ("libweston: use enum to choose the backend")
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
There are no internal users left for this protocol, they have been
migrated to the new weston-output-capture protocol. There are no
external users, because this protocol was private and never installed.
Remove this dead code.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is necessary in order to convert clients/screenshot.c into the
protocol.
We authorize a client the same way as before: if the wl_client is the
one we spawned, it's allowed.
Allowing screenshots on --debug was authorized by an earlier patch in
compositor/main.c.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Replicating the policy of the old screenshooting interface, allow all
screenshot to anyone with the new interface as well when --debug is
used.
Looks like there was one stray trailing space in unrelated code that my
editor deleted. Better this way.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Some monitors expose a selector for the kind of content that will get
displayed, allowing them to optimise their settings for this particular
content type.
I got access to such a monitor, sadly even setting it to game mode
didn’t lower its atrocious latency, but drm_info[1] reports it to be set
correctly so hopefully it’ll work better with other monitors.
[1] https://github.com/ascent12/drm_info
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
This lets us say what we really mean instead of passing a NULL output
and garbage co-ordinates.
This will help later when manufacturing garbage coordinates becomes much
harder to do.
The clear_pointer_focus() path continues to do nothing, and is just a FIXME
macro, as it has been for a very long time...
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This adds basic VNC protocol support using the Neat VNC library
(https://github.com/any1/neatvnc). Neat VNC depends on the AML main
loop library. The backend makes use of AML's integrated epoll backend
and connects AML via file descriptor with the Wayland event loop.
This implementation does not support authentication and hardcodes the
pixel format currently.
Co-authored-by: Philipp Zabel <p.zabel@pengutronix.de>
Co-authored-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Signed-off-by: Stefan Agner <stefan@agner.ch>
[r.czerwinski@pengutronix.de:
- use new (as of 0.5.0) Neat VNC buffer API, with a buffer pool]
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
[p.zabel@pengutronix.de:
- transform repaint damage to output coordinates
- transform pointer coordinates into global space
- check that outputs and heads are in fact ours, see aab722bb1785..060ef82d9360
- track damage across multiple frame buffers
- choose pixel format by drm_fourcc, see 8b6c3fe0ad
- enable ctrl and alt modifiers
- fix frame timing to achieve a constant repaint rate
- pass initial size explicitly, see f4559b0760
- use resize_output with pixman-renderer, see 55d08f9634e8..84b5d0eb4bee
- allow configuring the refresh rate]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This is all a little confusing, so let's split up the variables and throw
around some comments that better explain what's going on.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Our shared buffer isn't actually in output co-ordinates, so
initializing with the output's width/height isn't correct.
While we're here, remove the misleading comment. In a future
patch I'll try to document this code more accurately.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
The region has already been intersected with the output's region before
it was passed to us.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Except the module dir path, they're one and the same. This change
warrants a libweston version bump, if it hasn't been done already.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Replace all uses of weston_transform_region with
weston_matrix_transform_region, then remove the function completely.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes the following warnings when building with _FORTIFY_SOURCE
and optimizations enabled:
../shared/xalloc.h:49:9: error: ignoring return value of ‘write’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
49 | write(STDERR_FILENO, oommsg, strlen(oommsg));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
or
../compositor/main.c:427:25: error: ignoring return value of ‘write’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
427 | write(STDERR_FILENO, fail_seteuid,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
428 | strlen(fail_seteuid));
| ~~~~~~~~~~~~~~~~~~~~~
../compositor/main.c:434:25: error: ignoring return value of ‘write’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
434 | write(STDERR_FILENO, fail_cloexec,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
435 | strlen(fail_cloexec));
| ~~~~~~~~~~~~~~~~~~~~~
../compositor/main.c:442:25: error: ignoring return value of ‘write’ declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
442 | write(STDERR_FILENO, fail_exec, strlen(fail_exec));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As things are, even when mode=current is specified on the .ini file,
a full modeset is needed (and done), which causes a very noticeable
screen blinking. That is because setting the max_bpc on a connector
needs full modesetting.
The idea here is that if mode=current on the .ini, no modesetting
should be done, so the current max_bpc is programmed into the
connector.
But if a custom max-bpc=... is specified, that will be used instead,
even if mode=current on the .ini
Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/660
Signed-off-by: vanfanel <redwindwanderer@gmail.com>
The supplied path for executing the shell client could contain potential
arguments and not only the binary itself. Specifying the platform either
by using an argument (-platform wayland) or using an environmental
variable (QT_QPA_PLATFORM) with clients written in Qt is for instance
an example on why this might be useful to have in.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
When the gl-renderer is not enabled, weston fails to start, as it
doesn't automatically fallback to the pixman renderer, which is
always enabled.
This commit changes the drm-backend to set by default the --use-pixman
option to true when the gl-renderer is disabled (BUILD_DRM_GBM is not
defined).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.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>
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>
This was using read_format for the read_pixels() call, and then using a
hardcoded format for interpreting the data received from read_pixels().
That works only by accident, read_format being the same as the hardcoded
format.
Use read_format for the interpreting too. This should guarantee the read
pixels are processed correctly.
Found by code inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The text_input_manager might be destroyed upon a compositor shutdown, so
verify if it's still set-up before attemping to use it to avoid a UAF.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This is so the systemd-notify module, if used, will notify readiness after
we're ready to accept X connections, instead of before.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is awkward and long deprecated, and makes us load xwayland after all
the other modules so we know if we have to load it or not. Let's remove it.
We do still need to prevent loading the module the wrong way, though.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
If we leave xwayland in weston's process group, it can receive
signals from the controlling TTY intended for weston.
The easiest way to see this is to launch weston under gdb, start an
X client, and hit ctrl-c in the gdb session. The Xwayland server
will also catch the SIGINT, and the X client will be disconnected.
Instead, let's call setsid() when launching Xwayland, like we do
for launched clients.
Suggested-by: Hideyuki Nagase <hideyukn@microsoft.com>
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
[common equivalent of 77cf8cb006 in Xwayland from Pekka Paalanen; its
commit message follows]
Between fork() and exec() in the child process it is only safe to use
async-signal-safe functions. weston_log() definitely is not one, it
allocates memory and does whatnot.
weston_log() is also inappropriate for other reasons: the child process
has its own stream buffers and flight-recorder. No-one looks into the
child process' flight recorder, so messages would be lost there. The
logging machinery might also attempt to write into debug streams,
meaning both parent and child could be writing simultaneously.
It seems that the best we can do is to pre-bake an error message and
only write() it out if exec() fails. There is no mention that even
strerror_r() might be safe to call, so we don't.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Use the custom_env framework we added for Xwayland when forking to
execute clients. This avoids calling the unsafe getenv in between fork
and exec.
Signed-off-by: Daniel Stone <daniels@collabora.com>
It was only a small function, and inlining it will allow us to make it
more safe without having to duplicate a ton of stuff.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This doesn't actually stop us from calling setenv() in between fork()
and exec() when starting clients, but gets us closer to Xwayland's safe
implementation by reusing one of the helpers it added.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Use the arg handling added in the previous commit so that the
environment is completely encapsulated inside the custom env.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rename the bits handling environment variables (currently, all of it),
so we have room to handle args as well.
No functional changes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Between fork() and exec() in the child process it is only safe to use
async-signal-safe functions. Painfully, setenv() is not listed as such.
Therefore we must craft our own custom environment, and we get no help
from libc with that.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Constructing argv before-hand is a little easier to look at, but this is
mostly just anticipating more changes to how Weston spawns processes in
general.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We are already using pipe2() in many places, even in libweston, so let's
simplify the code here as well - not to mention avoid a theoretical
race.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Between fork() and exec() in the child process it is only safe to use
async-signal-safe functions. Surprisingly, snprintf() is not such
function. See e.g. https://stackoverflow.com/a/6771799 and how snprintf
is not listed in signal-safety(7) manual.
Therefore we must prepare the fd argument strings before fork(). That is
only possible if we also do not dup() fd in the child process. Hence we
remove the close-on-exec flag instead in the child process which has
copies of the parent's file descriptors. Fortunately fcntl() is safe.
struct fdstr is helping to reduce code clutter a bit.
Additionally, if fork() fails, we now clean up the fds we created.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Between fork() and exec() in the child process it is only safe to use
async-signal-safe functions. weston_log() definitely is not one, it
allocates memory and does whatnot.
weston_log() is also inappropriate for other reasons: the child process
has its own stream buffers and flight-recorder. No-one looks into the
child process' flight recorder, so messages would be lost there. The
logging machinery might also attempt to write into debug streams,
meaning both parent and child could be writing simultaneously.
It seems that the best we can do is to pre-bake an error message and
only write() it out if exec() fails. There is no mention that even
strerror_r() might be safe to call, so we don't.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Doing any kind of memory allocation calls between fork() and exec() in
the child process is prone to deadlocks and explosions. In general, only
async-signal-safe functions are safe there.
Move the config access to the parent process before fork() to avoid
problems.
See also:
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/941#note_1457053
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This reverts commit 4aa885d4af.
Turns out the problem was not about dupping fds at all, but calling
non-async-signal-safe functions like strdup() between fork() and exec()
in the child process.
For more discussion, see:
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/941#note_1457053
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch fixes the following:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==528956==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7fbc5d66bdd7 bp 0x7ffd465573c0 sp 0x7ffd46557398 T0)
==528956==The signal is caused by a WRITE memory access.
==528956==Hint: address points to the zero page.
#0 0x7fbc5d66bdd7 in wl_list_remove ../../git/wayland/src/wayland-util.c:56
#1 0x7fbc5cb8869e in wxw_compositor_destroy ../../git/weston/compositor/xwayland.c:357
#2 0x7fbc5baf3ca6 in weston_signal_emit_mutable ../../git/weston/shared/signal.c:62
#3 0x7fbc5ba4d6f9 in weston_compositor_destroy ../../git/weston/libweston/compositor.c:8639
#4 0x7fbc5cb7a5f2 in wet_main ../../git/weston/compositor/main.c:3772
#5 0x55bd13de2179 in main ../../git/weston/compositor/executable.c:33
#6 0x7fbc5be61d09 in __libc_start_main ../csu/libc-start.c:308
#7 0x55bd13de2099 in _start (/home/pq/local/bin/weston+0x1099)
The problem is triggered by configuring a bad path to Xwayland in
weston.ini, which causes exec() to fail. The fork() succeeded though,
which means the weston_process was already on the watch list, and the
watch can be handled, making sigchl_handler() leave the link
uninitialized.
Making sure the link remains removable fixes this.
Fixes: 18897253d4
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
While developing the new color management, keeping these old plugins
working would require extra work. Let's deprecate these to see if anyone
cares about them, pending removal after the Weston 11.0.0 release.
CI will keep building these in the "Full build" configuration only. Doc
and no-GL builds are no different for these plugins, so there these are
no longer built.
See https://gitlab.freedesktop.org/wayland/weston/-/issues/634
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This way the backends will the actual outputs. And at that point the backend
knows the compositor is shutting down so it can handle this differently if
necessary.
Afterwards wet_compositor_destroy_layout() just deletes the remaining
datastructures.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Replace an oft-duplicated pattern with a trivial helper function. In
doing so, we observe that the one special case (displayfd 'didn't need
to be CLOEXEC') was wrong, because the X server does fork itself
internally, so there is nothing wrong with setting CLOEXEC.
Signed-off-by: Daniel Stone <daniels@collabora.com>
For working around hardware limitations as explained in the man page.
Now added for completeness' sake without knowing if anyone will ever
need this.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
To support heterogeneous outputs, the output must be created by the
same backend as the head(s) it is created for. Solve this by always
creating an output with a first head to attach that determines the
backend to use. Skip already attached first heads in drm_try_attach().
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/268
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Add a struct weston_head parameter to weston_compositor_create_output()
and fold weston_compositor_create_output_with_head() into it.
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/268
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
It's bad form to set the same variable in multiple places, and not all
of them were even equivalent.
Move lcms2 finding to the root level build file only. It is still an
optional dependency like before, and the if-not-found checks are still
in place where actually needed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds an option to program basic display color characteristics from
weston.ini. In the future there will be a way to set this information
from EDID, but because EDID is unreliable that will probably not be the
default. An ICC profile will likely override most or all of this. The
main reason to add this option is to be able to characterise HDR
monitors.
An 'output' section can have a key 'color_characteristics' (string)
set to a name. The name refers to any 'color_characteristics' section
with 'name' set to the same string.
The 'name' key of a 'color_characteristics' section cannot contain a
colon ':'. Names with colon in 'output' section key
'color_characteristics' value are reserved for future use, e.g. to
indicate that the metadata is to be taken from EDID instead of a
weston.ini section.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We currently hardcode a 60Hz update rate for the rdp backend.
In some cases it may be useful to override this to increase the rate
for a faster monitor, or to decrease it to reduce network traffic.
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 already have a way for a single RDP client connection to be
passed from a parent process to a child using a combination
of environment variable (RDP_FD) and env var (--env-socket)
This patch allows a bound socket fd (as opposed to a client
connection) to be established in a parent process and provided
to the rdp backend. WSLg uses this to set up an AF_VSOCK
socket for communication between a Windows RDP client and a
weston compositor running under a hypervisor.
Co-authored-by: Hideyuki Nagase <hideyukn@microsoft.com>
Co-authored-by: Steve Pronovost <spronovo@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>
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>
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>
Found while running with b_sanitize=undefined, which yields:
runtime error: shift exponent 909199186 is too large for 32-bit type 'int'
Converts the shm_formats to a boolean and checks for the correct pixel
format it directly, instead of trying to gather them all in an array and
then later on to do the check.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Trivial fix to clean itself on compositor tear-down. While at it
properly free the command string.
Fixes#298
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
With commit e825fe38, we no longer display the pointer if no movement is
detected, which will cause screen share to fail to start if that is the
case. There could be also legitimate cases where there's no pointer, so
let's allow screen share to function in those cases as well. Makes uses
of previous helper methods to find a proper output to share in case we
don't have an pointer.
Re-uses the shell utils functions.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Input method process may also be a XIM server which requires the correct
DISPLAY to be set after xwayland start up. This helps input method to
work for both wayland and Xwayland.
Signed-off-by: Weng Xuetian <wengxt@gmail.com>
We want to wait for Xwayland to be ready before issuing it blocking
requests, but relying on USR1 is a bit unsafe:
- we can't ascertain the signal originated from Xwayland
- if weston is started as PID1 (e.g. in its own container), then
Xwayland will not send SIGUSR1 and X11 connections will be stuck
forever: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1312
Creating a pipe and using -displayfd, even if we don't care about the
display value itself, is safe and works for all cases
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
The pixel format was hardcoded to PIXMAN_a8r8g8b8. All other
renderer->read_pixels() calls in weston use dynamic format selection via
the compositor->read_format instead.
The problem was spotted on the ARM devices with Mali-400 GPU. The visual
effect of the problem was black screen on the remote display, when using
screen-share with the VNC or RDP backends. Related wayland-devel thread:
https://lists.freedesktop.org/archives/wayland-devel/2020-September/041624.html
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
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>
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>
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>
Make it slightly easier to disambiguate clients when we log the protocol
stream from the server side.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Name the seat created by the screen share plugin "screen-share" instead of
"default", to make it easier to recognize. No functional change intended.
Signed-off-by: Marek Vasut <marex@denx.de>
Leak found running drm-smoke-test with ASan.
Do not forget to free string specific_device in load_drm_backend().
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The code currently checked the return value of weston_config_section_get_bool()
which is incorrect. The return value of weston_config_section_get_bool() is
zero whether the config option is present or not, and it is non-zero in case
the config option is not present.
The code must check whether the config option is either true or false,
or in case the option is not present then default to false. Adjust the
code accordingly.
Reviewed-by: Marius Vlad <marius.vlad@collabora.com>
Signed-off-by: Marek Vasut <marex@denx.de>
This adds "icc_profile" key support in [output] sections for backends
headless, x11, wayland, and drm, and also for remoted and pipewire
outputs FWIW. On the other hand, RDP-backend does not use output
sections from weston.ini, and fbdev-backend does not deserve anything
new (it wouldn't support color management anyway due to no GL-renderer).
This allows one to configure an ICC v2 or v4 file to be used as an
output profile. However, color-lcms does not actually use output
profiles yet, so trying this will fail until support is implemented.
The parent_winsys_profile argument is reserved for using the color
profile from a parent window system where applicable, if nothing else is
set in weston.ini. None of the nested backends provide an output color
profile yet. It is more of a reminder of a missing feature than a
serious implementation.
Note: cms-static Weston plugin uses the exact same weston.ini key for
loading VCGT from ICC profiles. If "color-management" option is set to
false, this new use of "icc_profile" is disabled and the old behavior
with cms-static is kept.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
It will cause on following situation:
* Enable weston-simple-im
* It's also reproducible with IBus or Fcitx5
* Connect a mouse or a touch panel
* Don't connect keyboad
* Launch weston-editor and touch the text area
It doesn't reproduce with weston-keyboard because it doesn't use
grab_keyboard of input-method-context-v1.
Signed-off-by: Takuro Ashie <ashie@clear-code.com>
Currently the screen sharing has to be manually started after weston has
started by pressing Ctrl+Alt+S on a keyboard. Add new bool config option
to the screen-share section which permits starting the screen sharing of
all outputs on weston start up. This is useful e.g. for doing screen
mirroring between two devices over network.
Signed-off-by: Marek Vasut <marex@denx.de>
input-method-v1 protocol provides two surface type for the input
panel, `toplevel` and `overlay`. But there is no example for the later
one. This change enables to set weston-keyboard as overlay panel by the
environment variable `WESTON_KEYBOARD_SURFACE_TYPE=overlay` to
demonstrate this feature. In Addition, add weston.ini option
`overlay-keyboard` to set it.
Signed-off-by: Takuro Ashie <ashie@clear-code.com>
Add a command line option to disable the default flight recorders
so we can save a little bit of CPU and memory on systems where
this isn't necessary.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The value of the `path` parameter is executed right before
wl_display_run.
The `watch` parameter is meant for things like tests using
the headless backend and the kiosk shell.
Fixes https://gitlab.freedesktop.org/wayland/weston/-/issues/171
Signed-off-by: Alvarito050506 <donfrutosgomez@gmail.com>
Found by ASan:
Direct leak of 30 byte(s) in 1 object(s) allocated from:
#0 0x7f4dcf029810 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x3a810)
#1 0x7f4dcefd2143 in handle_option ../../git/weston/shared/option-parser.c:56
#2 0x7f4dcefd2473 in long_option ../../git/weston/shared/option-parser.c:84
#3 0x7f4dcefd2bb6 in parse_options ../../git/weston/shared/option-parser.c:175
#4 0x7f4dcefc7b0d in wet_main ../../git/weston/compositor/main.c:3229
#5 0x5593dfa38ffd in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#6 0x5593dfa3ca69 in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#7 0x5593dfa2e511 in fixture_setup ../../git/weston/tests/ivi-shell-app-test.c:139
#8 0x5593dfa2e596 in fixture_setup_run_ ../../git/weston/tests/ivi-shell-app-test.c:141
#9 0x5593dfa3d01e in main ../../git/weston/tests/weston-test-runner.c:661
#10 0x7f4dcec2d09a in __libc_start_main ../csu/libc-start.c:308
#11 0x5593dfa2d769 in _start (/home/pq/build/weston-meson/tests/test-ivi-shell-app+0xd769)
when running
ASAN_OPTIONS=fast_unwind_on_malloc=0,malloc_context_size=50 \
LSAN_OPTIONS=suppressions=/home/pq/git/weston/.gitlab-ci/leak-sanitizer.supp \
./tests/test-ivi-shell-app
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This reverts commit 81ef6d0ab3.
This also removes a bit from "tests: ensure color-lcms plugin loads".
Use of the shadow buffer is determined automatically based on
color transformations by the previous commit
"gl-renderer: use shadow framebuffer automatically".
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
