[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>
Found by Address sanitizer on test-devices:
==10640==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000000580 at pc 0x7fa0f050dcd1 bp 0x7fff41c908e0 sp 0x7fff41c908d8
WRITE of size 8 at 0x60c000000580 thread T0
#0 0x7fa0f050dcd0 in unbind_input_method ../../git/weston/compositor/text-backend.c:852
#1 0x7fa0efd1b20d in destroy_resource ../../git/wayland/src/wayland-server.c:724
#2 0x7fa0efd1f7f1 in for_each_helper ../../git/wayland/src/wayland-util.c:372
#3 0x7fa0efd1fcde in wl_map_for_each ../../git/wayland/src/wayland-util.c:385
#4 0x7fa0efd1b35c in wl_client_destroy ../../git/wayland/src/wayland-server.c:883
#5 0x7fa0f050ea82 in text_backend_destroy ../../git/weston/compositor/text-backend.c:1067
#6 0x7fa0ebb69f2f in shell_destroy ../../git/weston/desktop-shell/shell.c:5012
#7 0x7fa0efd55933 in wl_signal_emit /home/pq/local/include/wayland-server-core.h:478
#8 0x7fa0efd7d061 in weston_compositor_destroy ../../git/weston/libweston/compositor.c:7896
#9 0x7fa0f050a349 in wet_main ../../git/weston/compositor/main.c:3493
#10 0x559c1e794354 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#11 0x559c1e797dc0 in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#12 0x559c1e786ab8 in fixture_setup ../../git/weston/tests/devices-test.c:39
#13 0x559c1e786b3a in fixture_setup_run_ ../../git/weston/tests/devices-test.c:41
#14 0x559c1e798375 in main ../../git/weston/tests/weston-test-runner.c:661
#15 0x7fa0f016e09a in __libc_start_main ../csu/libc-start.c:308
#16 0x559c1e786769 in _start (/home/pq/build/weston-meson/tests/test-devices+0xc769)
0x60c000000580 is located 0 bytes inside of 120-byte region [0x60c000000580,0x60c0000005f8)
freed by thread T0 here:
#0 0x7fa0f0618fb0 in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0xe8fb0)
#1 0x7fa0f050df1d in input_method_notifier_destroy ../../git/weston/compositor/text-backend.c:902
#2 0x7fa0efd86d77 in wl_signal_emit /home/pq/local/include/wayland-server-core.h:478
#3 0x7fa0efd98086 in weston_seat_release ../../git/weston/libweston/input.c:3475
#4 0x7fa0ebb0d002 in test_seat_release ../../git/weston/tests/weston-test.c:132
#5 0x7fa0ebb0e197 in device_release ../../git/weston/tests/weston-test.c:314
#6 0x7fa0efca88ed in ffi_call_unix64 (/lib/x86_64-linux-gnu/libffi.so.6+0x68ed)
previously allocated by thread T0 here:
#0 0x7fa0f0619518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
#1 0x7fa0f050a8bf in zalloc ../../git/weston/include/libweston/zalloc.h:38
#2 0x7fa0f050e6f1 in text_backend_seat_created ../../git/weston/compositor/text-backend.c:1011
#3 0x7fa0f050e947 in handle_seat_created ../../git/weston/compositor/text-backend.c:1040
#4 0x7fa0efd86d77 in wl_signal_emit /home/pq/local/include/wayland-server-core.h:478
#5 0x7fa0efd97d57 in weston_seat_init ../../git/weston/libweston/input.c:3440
#6 0x7fa0ebb0ce4b in test_seat_init ../../git/weston/tests/weston-test.c:110
#7 0x7fa0ebb0f699 in wet_module_init ../../git/weston/tests/weston-test.c:592
#8 0x7fa0f04f8d69 in wet_load_module ../../git/weston/compositor/main.c:941
#9 0x7fa0f04f914d in load_modules ../../git/weston/compositor/main.c:1012
#10 0x7fa0f0509ec1 in wet_main ../../git/weston/compositor/main.c:3441
#11 0x559c1e794354 in execute_compositor ../../git/weston/tests/weston-test-fixture-compositor.c:432
#12 0x559c1e797dc0 in weston_test_harness_execute_as_client ../../git/weston/tests/weston-test-runner.c:528
#13 0x559c1e786ab8 in fixture_setup ../../git/weston/tests/devices-test.c:39
#14 0x559c1e786b3a in fixture_setup_run_ ../../git/weston/tests/devices-test.c:41
#15 0x559c1e798375 in main ../../git/weston/tests/weston-test-runner.c:661
#16 0x7fa0f016e09a in __libc_start_main ../csu/libc-start.c:308
Fix UAF by resetting wl_resource user data, and ensuring it is valid
before used.
Setting seat->input_method to NULL may not be necessary since it is
being called from seat destroy listener, but added just in case.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Since commit "libweston: add required_capabilities test suite quirk"
a new function that depends on test_data is being called in wet_main().
We should check if test_data is NULL before calling it, otherwise
we have a segfault when running outside the test suite.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This allows tests to skip when required capabilities are not present.
The output damage test for the shadow buffer case needs this.
required_capabilities is added to struct weston_testsuite_quirks which
is libweston public API just because there is no better place currently.
This is a little weird because the code to check it is in compositor,
not libweston.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The capability strings will be printed also in another occasion, where
the colon does not fit with the capability description.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds an output section option use-renderer-shadow in weston.ini.
This option is only recognized with headless and DRM backends, because
it requires GL-renderer and does not support resizing outputs.
The option is called use-renderer-shadow because this is what it does
right now. In the future the same setting will be used to turn on more
complex image processing when operational pieces required for color
management land. Once color management is implemented, this option is
expected to be removed. This option allows developer testing of features
to be used to implement color management.
This is a rewrite of "weston.ini: introduce use-shadow-fbo in output
config" by Harish Krupo. The main.c code is structured differently, the
weston.ini option is renamed, and the man page paragraph is moved to
weston.ini.man with different content.
Cc: Harish Krupo <harishkrupo@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds the libweston capability bit for "color operations" which
refers to a renderer's support for operations needed for color
management. GL-renderer will grow the support while Pixman-renderer will
not, which is why the cap is needed.
To make an example use of the cap, this also adds new API:
weston_output_set_renderer_shadow_buffer(). This is a temporary API to
enable future experimental features. The first such feature will be the
renderer internal shadow buffer, the boolean variable for it taken from
Harish Krupo's "weston.ini: introduce use-shadow-fbo in output config".
Obviously this patch does not implement the renderer shadow buffer. No
renderer sets WESTON_CAP_COLOR_OPS yet so trying to enable it will fail.
The documentation here is deliberately vague, because the bits needed
for color management will come in trickling for a long time until we can
call it color management in any sense. Until then, the temporary API
shall remain, perhaps poorly named.
Cc: Harish Krupo <harishkrupo@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
shm buffer should be freed in case of `out_pixman_error`, and should
be inserted into shared_output just before the success return.
Signed-off-by: xndcn <xndchn@gmail.com>
The buffer created for flight recorder, the allocations done in 'logger' and
'flight_rec' subscribers were not freed when wl_display_create() fails. So
move them to out_display
Signed-off-by: Anurup M <anurup.mokkil@gmail.com>
Without this patch, the DRM-backend would rewrite the 'require-input',
core section option given by the user.
This removes 'continue_without_input' DRM-backend option and takes into
consideration the cmd line option only if that was passed (Pekka Paalanen).
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Until now we had the test quirks initialization in wet_main(),
just after calling weston_compositor_create(). But there are
some cases that require the quirks during struct weston_compositor
creation time.
Move test quirks initialization to weston_compositor_create()
in order to cover more use cases for the test quirks mechanism.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We have two functions with the name weston_screenshooter_shoot():
1. screenshot protocol function that the screenshooter
client uses to request screenshots to the compositor
2. libweston function used by the compositor to take
screenshots as requested by the screenshooter client
Until now we had no problem with that, but in the next commits
we are going to use the screenshot protocol in the test suite,
which is also user of libweston. So rename screenshot protocol
function to weston_screenshooter_take_shot() to avoid the conflict.
For consistency, also rename screenshooter_shoot() to
screenshooter_take_shot() in compositor/weston-screenshooter.c
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Until now we had struct wet_testsuite_data as an opaque
struct that should be defined by the testsuite of libweston
users. Instead, keep the data as a void * and document that
users are responsible for defining the data type.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There are some specific cases in which we need Weston to
behave differently when running in the test suite. This
adds a new API to allow the tests to select these behaviors.
For instance, in the DRM backend we plan to add a writeback
connector screenshooter. In case it fails for some
reason, it should fallback to the renderer screenshooter
that all other backends use. But if we add a test to
ensure the correctness of the writeback screenshooter,
we don't want it to fallback to the renderer one, we
want it to fail. With this new API we can choose to
disable the fallback behavior specifically for this test.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This was forgotten in "weston: remove SEGV and ABRT handlers". It is
unused.
Fixes: bb707dc0fe
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This commit alters the way that Weston picks a Wayland display socket
name. Instead of using wl_display_add_socket_auto to look for the first
available name in wayland-0, wayland-1, .... to wayland-32, the code now
checks names wayland-1, wayland-2, .... up to wayland-32.
This change is a workaround for a suboptimal behavior of
libwayland-client. If a client program calls wl_display_connect(NULL) and
the WAYLAND_DISPLAY environment variable is not set, then the program will
by default try to connect to 'wayland-0'. This is a problem when a
computer has a running Wayland compositor but is being accessed in some
other fashion, such as through an X session on a different virtual
terminal, over ssh, etc. Client programs launched through those means may
attempt to connect to an unrelated compositor. Changing libwayland
behavior to remove the default would also work, but a) libraries have
stronger backward compatibility expectations b) that would likely break
more people's setups than just changing Weston would.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
directory
Weston is also a user of the plug-ins, so make use of it. With this
change we unconditionally install the plug-in headers even though
libweston might not be built with support for them.
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The missing build dependency was added. The override to disable this
check can be removed.
Signed-off-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
cms-colord uses cms-helper functions which require lcms2. Therefore,
lcms2 must be added as a build dependency.
Signed-off-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
In the test suite we may want to run a DRM-backend test on a
non-default seat, which may not have a input device associated.
Weston's default behavior is to not open if input devices are
not found, as it may cause troubles. For instance, Weston can
open but if no input device is set than the user can not
interact or leave it.
Add flag --continue-without-input to DRM-backend so we can run
these types of tests with no input. Notice that this won't force
the compositor to skip opening a input device if it finds it on
the non-default seat.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
If users ask explicitly to log to a file, it makes sense to quit
when we fail opening that file. Continuing execution would mean
wasting users' time if they expect to find the log file at the
end of the session.
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When failing to open the log file nothing is reported to the user,
therefore we print a message on stderr when that happens.
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
As in aaf35586f4, we want to fail when we are passed an invalid
transform name, not just blindly configure on using the normal
transform. The previous commit missed the callsite from the headless
backend's command-line parsing.
Fix this so that headless fails when an invalid transform is specified
on the command line.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If the output only has a single weston_head attached to it, take its
declared transform as the default transform.
With the previous patches, this allows a device declaring the KMS 'panel
orientation' property (e.g. through DeviceTree) to autoconfigure to the
correct display rotation when running Weston.
Signed-off-by: Daniel Stone <daniels@collabora.com>
If an invalid transformation is provided for an output, fail the output
configuration rather than continuing on using whatever we chose as the
default transform.
After !383, this will result in configurations using the old definition
failing and exiting, rather than continuing on the wrong way around.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Regardless of the default transform passed in, weston_parse_transform
would always return 'normal' if there was an output section. This is
because, if a section was declared for that output, it would ask
weston_config for the transform, with the default being 'normal'.
Fix it so we return the passed-in default transform when we have a
matching output section without a transform key. If the transform is
declared but invalid, we can remove the line resetting to the default
transform, because we've already set the default transform up top.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The test suite wants to start using different output scales, and this is the
easiest API to configure it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
It was discovered in issue #99 that the implementations of the 90 and 270
degree rotations were actually the inverse of what the Wayland specification
spelled out. This patch fixes the libweston implementation to follow the
specification.
As a result, the behaviour of the the weston.ini transform key also changes. To
force all users to re-think their configuration, the transform key values are
also changed. Since Weston and libweston change their behaviour, the handling
of clients' buffer transform changes too.
All the functions had their 90/270 cases simply swapped, probably due to
confusion of whether WL_OUTPUT_TRANSFORM_* refers to rotating the monitor or
the content.
Hint: a key to understanding weston_matrix_rotate_xy(m, c, s) is that the
rotation matrix is formed as
c -s
s c
that is, it's column-major. This fooled me at first.
Fixing window.c fixes weston-terminal and weston-transformed.
In simple-damage, window_get_transformed_ball() is fixed to follow the proper
transform definitions, but the fix to the viewport path in redraw() is purely
mechanical. The viewport path looks broken to me in the presence of any
transform, but it is not this patch's job to fix it.
Screen-share fix just repeats the general code fix pattern, I did not even try
to understand that bit.
https://gitlab.freedesktop.org/wayland/weston/issues/99
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Before commit "weston-log: destroy subscriptions with
destruction of subscribers", we had to destroy subscribers
before the log context. Currently there's no required order,
both are valid.
But since we've created log context before the subscribers,
we can destroy it after them. This is a style change and
also a prove that now this order is valid as well.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Log subscriber API is not type-safe. File and flight recorder
subscribers are created with functions that return
weston_log_subscriber objects. But there's a problem: to destroy
these objects you have to call the right function for each type
of subscriber, and a user calling the wrong destroy function
wouldn't get a warning.
Merge functions that destroy different types of subscribers, making
the log subscriber API type-safe.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The cms-static, desktop-shell, hmi-controller, ivi-shell, and screen-share
modules use symbols from libexec_weston, e.g.:
$ ldd /usr/lib/x86_64-linux-gnu/weston/desktop-shell.so | grep "not found"
libexec_weston.so.0 => not found
Loading these modules from weston happens to work because the weston executable
itself links against libexec_weston, and has an rpath set. Still, these modules
depend on a library in a non-standard location. Adding an rpath could help
static checkers to make sure all shared objects' dependencies are present.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
`no_outputs` is declared on the stack and left uninitialized if no
weston option changing its value is provided.
Signed-off-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
Allow to set and get one opaque pointer. The test suite will then use this to
pass data from the test runner to the test plugin, so that the plugin can then
run what it needs to. This is useful when the test runner calls wet_main()
directly instead of forking a compositor.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The only reason why we have both weston_compositor_tear_down() and
weston_compositor_destroy() is that the only we had to destroy
the log context was keeping weston_compositor alive and calling
weston_log_ctx_compositor_destroy().
After commit "weston-log: replace weston_log_ctx_compositor_destroy()
by weston_log_ctx_destroy()", it's not necessary to keep a zombie
weston_compositor just to be able to call
weston_log_ctx_compositor_destroy().
Fold weston_compositor_tear_down() into weston_compositor_destroy(),
as this split is useless now.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
