Since commit "drm-formats: save result of intersection in the first
array", every block of code where weston_drm_format_array_create() and
destroy() are being called could use init() and fini() instead.
Remove these two functions from the API to make it leaner. This patch
also modifies the code that depends on these functions to use init() and
fini().
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
In the current API, we have some set operations: join, intersect and
subtract. Both join and subtract receives two DRM format arrays and save
the result in the first one.
For the intersection we have a slightly different approach, what makes
the API weird. We don't save the result in the arguments, instead we
return a new array with the result.
Modify weston_drm_format_array_intersect() in order to make it similar
to the other two set operations.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
EGL's native display type is not particularly well defined; in
gl-renderer we get around this by always treating it as a void *, since
for all the platforms we care about it's a pointer - gbm_device,
wl_display, or Display *.
The surfaceless platform doesn't care what the native display is (since
it doesn't have one by definition), so just use NULL instead of what may
be either NULL or 0 depending on environmental factors.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The API expects uintptr_t (good!), but we're passing an unsigned long
here. Make the conversion explicit.
Signed-off-by: Daniel Stone <daniels@collabora.com>
pointer/touch drag-n-drop operations could happen if there's no keyboard
hooked up or when it is unplugged.
Fixes: #235
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
And ultimately, fail to start when there are no input devices on the
system. Patchs adds consistency to touch/pointer initialization to
return -1 in case same thing happens.
Further more, when the device is not created we can't assume to retrieve
a valid one from a libinput_device so guard against it. This takes care of
hot-plugging situations when we couldn't create the (keyboard) device,
or when removing it.
Fixes: #117, #402, #485
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Some graphics drivers (currently at least VMware and AMD) will give a 0
timestamp for the atomic mode flip completion event when turning off
the display. This causes us to trip an assertion in
weston_output_frame_finish() because the clock jumps backwards, which
isn't a condition the presentation feedback code should be dealing with.
This is a good assertion and we'd like to keep it. And there's some
expectation that this is buggy behaviour in the graphics drivers that will
be fixed at some point.
Pragmatically speaking though, there's nothing productive we can do with a
correct timestamp for the display shutdown. So let's just flag the
event sent for DPMS off as invalid so presentation feedback doesn't have
to worry about it, and the assert doesn't fire.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
weston_frame_callback is needed primarily to store the doubly-linked list link,
but it can be also retrieved by using the wl_resource_get_link() function.
This removes an extra heap allocation per every wl_callback object.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Conditionally build support when libdrm is at least 2.4.107 to make use
of it. Plug it in when printing out the buffer information.
With this in, we add a hard dependecy for libweston to link against
libdrm.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Potential failures when creating the EGL image could cause an incorrect
number of num images (num_planes > num_images). With this change
egl_image_unref() requires an additional check to avoid any potential NULL
derefs when cleaning up. We do it straight in egl_image_unref() instead
of adding guards all over the necessary parts.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As observed on some platforms, importing known DMA buffers can cause
failures, leading to an attempt of destroyng an EGL image not set. This patch
resets the num_images such that loop becomes inert when destroying the
DMA buffer, and avoids passing an egl image to it.
The initial import doesn't have this issue as it sets the num_images in
case it succeeds. This also corrects the assumption that the num_images
were 0 at that point which, if the initial import succeded, was actually set
to 1.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The wayland.c actually include 'xdg-shell-client-protocol.h' instead of
the server one, so fix it. Otherwise, it's possible to get build failure
due to race condition.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
[daniels: Found in OpenEmbedded/Yocto source.]
Fixes a minor leak due to launcher-libseatd:
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f15664e5037 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xaa037)
#1 0x7f156305c59f in zalloc ../include/libweston/zalloc.h:38
#2 0x7f156305c99b in seat_open_device ../libweston/launcher-libseat.c:114
#3 0x7f1563056341 in weston_launcher_open ../libweston/launcher-util.c:79
#4 0x7f156302f1e2 in drm_device_is_kms ../libweston/backend-drm/drm.c:2616
#5 0x7f156302f751 in find_primary_gpu ../libweston/backend-drm/drm.c:2715
#6 0x7f15630309a5 in drm_backend_create ../libweston/backend-drm/drm.c:2970
#7 0x7f15630317ab in weston_backend_init ../libweston/backend-drm/drm.c:3162
#8 0x7f1566025b61 in weston_compositor_load_backend ../libweston/compositor.c:8201
#9 0x7f156640cb9e in load_drm_backend ../compositor/main.c:2596
#10 0x7f156641193c in load_backend ../compositor/main.c:3079
#11 0x7f1566413cc3 in wet_main ../compositor/main.c:3356
#12 0x562ba484b179 in main ../compositor/executable.c:33
#13 0x7f156624fcc9 in __libc_start_main ../csu/libc-start.c:308
But also use the launcher interface to actually close the DRM fd, in
mirror to what weston_launcher_open() does.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Initialize LittleCMS and use it to generate the sRGB EOTF and inverse
curves. Use these curves to define the blending color space as optical
(linear) sRGB by assuming that both content and output color spaces are
sRGB.
As a consequence, this causes Weston to do "gamma correct blending", as
in, blend in light linear space which should avoid distorting colors in
alpha gradients, when color-lcms is active.
This makes use of the 3x1D LUT support added in gl-renderer earlier, and
shows how the color manager is responsible for re-using existing color
transformation objects.
Co-authored-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the blending to output color space transformation when blitting from
the shadow to a framebuffer.
This allows the blending and output color spaces to differ as long as
shadow is used, in case a backend does not off-load the color
transformation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the sRGB to output color space transformation when blitting the
borders (decorations) into an output window (nested compositor).
Nested output does not need to be sRGB anymore, as far as the
decorations are concerned.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the sRGB to blending color space transformation for the censoring
color fill and triangle fan debug drawings.
This removes the assert that the output's blending space is (non-linear)
sRGB.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This makes weston_color_transform object be able to express
three-channel one-dimensional look-up table transformations. They are
useful for applying EOTF and EOTF^-1 mapping, or, gamma curves. They
will also be useful in optimizing a following 3D LUT tap distribution
once support for 3D LUT is added.
The code added here translates from the lut_3x1d fill_in() interface to
a GL texture to be used with SHADER_COLOR_CURVE_LUT_3x1D for
weston_surfaces.
It demonstrates how renderer data is attached to weston_color_transform
and cached.
GL_OES_texture_float_linear is required to be able to use bilinear
texture filtering with 32-bit floating-point textures, used for the LUT.
As the size of the LUT depends on what implements it, lut_3x1d fill_in()
interface is a callback to the color management component to ask for an
arbitrary size. For GL-renderer this is not important as it can easily
realize any LUT size, but when DRM-backend wants to offload the EOTF^-1
mapping to KMS (GAMMA_LUT), the LUT size comes from KMS.
Nothing actually implements lut_3x1d fill_in() yet, that will come in a
later patch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds shader support for using a three-channel one-dimensional
look-up table for de/encoding input colors. This operation will be useful
for applying EOTF or its inverse, in other words, gamma curves. It will
also be useful in optimizing a following 3D LUT tap distribution once
support for 3D LUT is added.
Even though called three-channel and one-dimensional, it is actually
implemented as a one-channel two-dimensional texture with four rows.
Each row corresponds to a source color channel except the fourth one is
unused. The reason for having the fourth row is to get texture
coordinates in 1/8 steps instead of 1/6 steps. 1/6 may would not be
exact in floating- or fixed-point arithmetic and might perhaps risk
unintended results from bilinear texture filtering when we want linear
filtering only in x but not in y texture coordinates. I may be paranoid.
The LUT is applied on source colors after they have been converted to
straight RGB. It cannot be applied with pre-multiplied alpha. A LUT can
be used for both applying EOTF to go from source color space to blending
color space, and EOTF^-1 to go from blending space to output
(electrical) space. However, this type of LUT cannot do color space
conversions.
For now, this feature is hardcoded to off everywhere, to be enabled in
following patches.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Always when supported, make the fragment shader default floating point
precision high. The medium precision is roughly like half-floats, which
can be surprisingly bad. High precision does not reach even normal
32-bit float precision (by specification), but it's better. GL ES
implementations are allowed to exceed the minimum precision requirements
given in the specification.
This is an advance attempt to avoid nasty surprises from poor shader
precision.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add a new shader requirements bit input_is_premult which says whether
the texture sampling results in premultiplied alpha or not. Currently
this can be deduced fully from the shader texture variant, but in the
future there might a protocol extension to explicitly control it. Hence
the need for a new bit.
yuva2rgba() is changed to produce straight alpha always. This makes
sample_input_texture() sometimes produce straight or premultiplied
alpha. The input_is_premult bit needs to match sample_input_texture()
behavior. Doing this should save three multiplications in the shader for
straight alpha formats.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Leak found running drm-formats-test with ASan:
==58755==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487
#5 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67deca in subtract_arrays_modifier_invalid ../tests/drm-formats-test.c:613
#5 0x55723c67da3d in wrapsubtract_arrays_modifier_invalid ../tests/drm-formats-test.c:593
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67c9c0 in subtract_arrays_same_content ../tests/drm-formats-test.c:521
#5 0x55723c67c55b in wrapsubtract_arrays_same_content ../tests/drm-formats-test.c:504
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67d1b7 in subtract_arrays_exclusive_formats ../tests/drm-formats-test.c:552
#5 0x55723c67cb23 in wrapsubtract_arrays_exclusive_formats ../tests/drm-formats-test.c:529
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7fae744dbe3a in zalloc ../include/libweston/zalloc.h:38
#2 0x7fae744dbe4e in weston_drm_format_array_create ../libweston/drm-formats.c:44
#3 0x7fae744dd2a2 in weston_drm_format_array_subtract ../libweston/drm-formats.c:410
#4 0x55723c67d8d5 in subtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:584
#5 0x55723c67d31d in wrapsubtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:561
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 320 byte(s) in 5 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae74473c10 in wl_array_copy (/usr/lib/libwayland-client.so.0+0xac10)
#3 0x7fae744dbfe0 in add_format_and_modifiers ../libweston/drm-formats.c:108
#4 0x7fae744dd389 in weston_drm_format_array_subtract ../libweston/drm-formats.c:418
#5 0x55723c67d1b7 in subtract_arrays_exclusive_formats ../tests/drm-formats-test.c:552
#6 0x55723c67cb23 in wrapsubtract_arrays_exclusive_formats ../tests/drm-formats-test.c:529
#7 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#8 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#9 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#10 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#11 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#12 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#13 0x55723c680844 in main ../tests/weston-test-runner.c:661
#14 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#15 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 256 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dbfb7 in add_format_and_modifiers ../libweston/drm-formats.c:104
#4 0x7fae744dd389 in weston_drm_format_array_subtract ../libweston/drm-formats.c:418
#5 0x55723c67d1b7 in subtract_arrays_exclusive_formats ../tests/drm-formats-test.c:552
#6 0x55723c67cb23 in wrapsubtract_arrays_exclusive_formats ../tests/drm-formats-test.c:529
#7 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#8 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#9 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#10 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#11 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#12 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#13 0x55723c680844 in main ../tests/weston-test-runner.c:661
#14 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#15 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 256 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426
#4 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487
#5 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 128 byte(s) in 2 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae74473c10 in wl_array_copy (/usr/lib/libwayland-client.so.0+0xac10)
#3 0x7fae744dbfe0 in add_format_and_modifiers ../libweston/drm-formats.c:108
#4 0x7fae744dd389 in weston_drm_format_array_subtract ../libweston/drm-formats.c:418
#5 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487
#6 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467
#7 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#8 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#9 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#10 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#11 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#12 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#13 0x55723c680844 in main ../tests/weston-test-runner.c:661
#14 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#15 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 96 byte(s) in 3 object(s) allocated from:
#0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76)
#2 0x7fae744dd142 in modifiers_subtract ../libweston/drm-formats.c:384
#3 0x7fae744dd408 in weston_drm_format_array_subtract ../libweston/drm-formats.c:431
#4 0x55723c67bed5 in subtract_arrays ../tests/drm-formats-test.c:487
#5 0x55723c67b6bb in wrapsubtract_arrays ../tests/drm-formats-test.c:467
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658652 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x7fae74473b76 in wl_array_add (/usr/lib/libwayland-client.so.0+0xab76)
#2 0x7fae744dd142 in modifiers_subtract ../libweston/drm-formats.c:384
#3 0x7fae744dd408 in weston_drm_format_array_subtract ../libweston/drm-formats.c:431
#4 0x55723c67d8d5 in subtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:584
#5 0x55723c67d31d in wrapsubtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:561
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426
#4 0x55723c67d8d5 in subtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:584
#5 0x55723c67d31d in wrapsubtract_arrays_exclusive_modifiers ../tests/drm-formats-test.c:561
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426
#4 0x55723c67deca in subtract_arrays_modifier_invalid ../tests/drm-formats-test.c:613
#5 0x55723c67da3d in wrapsubtract_arrays_modifier_invalid ../tests/drm-formats-test.c:593
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fae74658279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fae74473bc3 in wl_array_add (/usr/lib/libwayland-client.so.0+0xabc3)
#2 0x7fae744dc19f in weston_drm_format_array_add_format ../libweston/drm-formats.c:166
#3 0x7fae744dd3de in weston_drm_format_array_subtract ../libweston/drm-formats.c:426
#4 0x55723c67c9c0 in subtract_arrays_same_content ../tests/drm-formats-test.c:521
#5 0x55723c67c55b in wrapsubtract_arrays_same_content ../tests/drm-formats-test.c:504
#6 0x55723c67e9a9 in run_test ../tests/weston-test-runner.c:162
#7 0x55723c67f0af in run_case ../tests/weston-test-runner.c:277
#8 0x55723c67ee48 in for_each_test_case ../tests/weston-test-runner.c:235
#9 0x55723c67f358 in testsuite_run ../tests/weston-test-runner.c:311
#10 0x55723c680381 in weston_test_harness_execute_standalone ../tests/weston-test-runner.c:572
#11 0x55723c6803b1 in fixture_setup_run_ ../tests/weston-test-runner.c:610
#12 0x55723c680844 in main ../tests/weston-test-runner.c:661
#13 0x7fae742c4b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#14 0x55723c67442d in _start (/home/lele/weston/build/tests/test-drm-formats+0x642d)
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The DRM backend uses changes in the cursor view memory address and
surface damage to detect when it needs to re-upload to a cursor plane
framebuffer.
However, when a cursor view is destroyed and then recreated, e.g., when
the pointer cursor surface is updated, the newly created view may have
the same memory address as the just destroyed one. If no new cursor
buffer is provided (because it was attached, committed and used
previously) when this address reuse occurs, then there also isn't any
updated surface damage and the backend doesn't update the cursor plane
framebuffer at all.
To fix this issue utilize the destroy signal to track when the cursor
view is destroyed, and clear the cached cursor_view value in drm_output.
After clearing the cached value, the next cursor view is always
considered new and thus uploaded to the plane properly.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
This creates the FP16 shadow framebuffer automatically if the color
transformation from blending space to output space is not identity and
the backend does not claim to implement it on the renderer's behalf.
That makes the weston_output_set_renderer_shadow_buffer() API and
use-renderer-shadow weston.ini option obsolete.
To still cater for the one test that needs to enable the shadow
framebuffer in spite of not needing it for color correct blending, the
quirk it uses now also forces the shadow.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Compile time constants play an important role in keeping the shader
programs fast. Introduce an informal annotation to mark compile time
constants to make the shader code easier to reason with.
This will make much more sense once functions with compile time constant
parameters are added.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Trying to support GL ES 2.0 + extensions along with GL ES 3.0 for better
control is becoming too complicated fast. In this patch you see the
GL_RGBA vs. GL_RBA16F and GL_HALF_FLOAT vs. GL_HALF_FLOAT_OES paths.
More such cases will come, e.g. GL_RED_EXT vs. GL_R32F.
Make things simpler and require GL ES 3.0 +
GL_EXT_color_buffer_half_float for all color management related
functionality. If one doesn't have GL ES 3.0, all you lose is color
management.
Also, all extensions needed by color transformation operations are
gathered under one boolean flag instead of having a flag per extension,
again for simplicity.
This makes the GL ES extension handling much easier.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This reverts commit 36d699a164.
A different way to fix this same issue is the previous commit
"gl-renderer: do not unbind the context on output destroy"
which is needed for other reasons.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If we make EGL_NO_CONTEXT current, all following GL calls are
no-ops. This will be a problem when gl-renderer introduces
gl_renderer_color_transform containing GL textures and needs to destroy
them when weston_color_transform is destroyed. Mesa would print the the
warning that glDeleteTextures is no-op.
To fix this, keep our GL context current when destroying a GL output.
In case EGL_KHR_surfaceless_context is not available, we must use
dummy_surface.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This creates the color-lcms plugin that in the future will be using
Little CMS as the color matching module, processing ICC profiles, and
producing HDR tone mappings.
Right now, this new plugin is functionally equivalent to the no-op color
manager, except it already links to lcms2 and checks that the renderer
supports color operations.
Color-lcms is a libweston plugin that is loaded with explicit
weston_compositor API. This does not currently allow loading alternative
color manager plugins. External color manager plugins might be
considered in the future when the libweston APIs around color management
stabilize.
This libweston plugin uses the same build option as the old cms-static
Weston plugins, as they both need lcms2. The minimum version for lcms2
was chosen by what Debian Buster provides today and for no other reason.
This plugin intends to support the Wayland CM&HDR protocol extension and
hence sets supports_client_protocol to true. This will expose the
protocol extension to clients when it gets implemented.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is needed when the compositor produces any content internally:
- the lines in triangle fan debug
- the censoring color fill (unmet HDCP requirements)
Solid color surfaces do not need this special-casing because
weston_surface is supposed to carry color space information, which will
get used in gl_shader_config_init_for_view().
This makes sure the internally produced graphics fit in, e.g on a
monitor in HDR mode.
For now, just ensure there is an identity transformation. Actual
implementations in GL-renderer will follow later.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is needed when drawing anything internal directly to an output,
like the borders/decorations in a nested compositor setup. This makes
the assumption that the internal stuff starts in sRGB, which should be
safe. As borders are never blended with other content, this should also
be sufficient.
This patch is a reminder that that path exists, rather than a real
implementation. To be implemented when someone needs it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the blending space to monitor space color transform. It needs to
be implemented in the renderers, unless a backend sets
from_blend_to_output_by_backend = true, in which case the backend does
it and the renderer does not.
The intention is that from_blend_to_output_by_backend can be toggled
frame by frame to allow backends to react to dynamic change of output
color profile.
For now, renderers just assert that they don't need to do anything for
output color transform.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
See: https://gitlab.freedesktop.org/wayland/weston/-/issues/467#note_814985
This starts building the framework required for implementing color
management.
The main new interface is struct weston_color_manager. This commit also
adds a no-op color manager implementation, which is used if no other
color manager is loaded. This no-op color manager simply provides
identity color transforms for everything, so that Weston keeps running
exactly like before.
weston_color_manager interface is incomplete and will be extended later.
Colorspace objects are not introduced in this commit. However, when
client content colorspace and output colorspace definitions are
combined, they will produce color transformations from client content to
output blending space and from output blending space to output space.
This commit introduces a placeholder struct for color transforms,
weston_color_transform. Objects of this type are expected to be heavy to
create and store, which is why they are designed to be shared as much as
possible, ideally making their instances unique. As color transform
description is intended to be generic in libweston core, renderers and
backends are expected to derive their own state for each transform
object as necessary. Creating and storing the derived state maybe be
expensive as well, more the reason to re-use these objects as much as
possible. E.g. GL-renderer might upload a 3D LUT into a texture and keep
the texture around. DRM-backend might create a KMS blob for a LUT and
keep that around.
As a color transform depends on both the surface and the output, a
transform object may need to be created for each unique pair of them.
Therefore color transforms are referenced from weston_paint_node. As
paint nodes exist for not just surface+output but surface+view+output
triplets, the code ensures that all paint nodes (having different view)
for the same surface+output have the same color transform state.
As a special case, if weston_color_transform is NULL, it means identity
transform. This short-circuits some checks and memory allocations, but
it does mean we use a separate member on weston_paint_node to know if
the color transform has been initialized or not.
Color transformations are pre-created at the weston_output
paint_node_z_order_list creation step. Currently the z order lists
contain all views globally, which means we populate color transforms we
may never need, e.g. a view is never shown on a particular output.
This problem should get fixed naturally when z order lists are
constructed "pruned" in the future: to contain only those paint nodes
that actually contribute to the output's image.
As nothing actually supports color transforms yet, both renderers and
the DRM-backend assert that they only get identity transforms. This
check has the side-effect that all surface-output pairs actually get a
weston_surface_color_transform_ref even though it points to NULL
weston_color_transform.
This design is inspired by Sebastian Wick's Weston color management
work.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A following patch will need the paint node in
gl_shader_config_init_for_view() for color transformations.
While passing the paint node through, rename the functions to be more
appropriate and get surface/view/output from the paint node.
This is a pure refactoring with no functional change.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A following patch will need the paint node in draw_view() for color
transformations.
While passing the paint node into draw_paint_node, also use the paint
node. This is a pure refactoring with no functional change.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When setting a cursor surface, use the surface dimensions, instead of the
weston_surface buffer reference, to check if the surface has any
content. A weston_surface without any buffer reference may in fact
have a buffer which was committed in a previous pointer entry, dropped
by weston_surface and now held only internally by the renderer.
Without this fix, when a pointer enters a surface, the cursor image is
not correctly updated if we set a cursor surface with an already
committed buffer from a previous pointer entry, without recommitting the
cursor buffer for the current entry. This can be seen, for example, in
the experimental Wine Wayland driver which handles the cursor in a way
that leads to the following scenario:
Setup: cursor_surface.attach(buffer) & cursor_surface.commit()
On first wl_pointer.enter: pointer.set_cursor(cursor_surface)
compositor/renderer redraws
wl_pointer.leave
On second wl_pointer.enter: pointer.set_cursor(cursor_surface)
When handling the second pointer.set_cursor() request the current code
doesn't find a buffer attached to the cursor_surface (only the renderer
now has a reference to it), so it doesn't update the respective view for
the cursor.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Remove all the backend code to support drivers without universal planes.
From[1]:
"The code needed to support kernels where DRM does not support uiniversal
planes makes the DRM-backend a little more complicated, because it needs
to create fake planes for primary and cursor. The lifetimes of the fake
planes does not match the lifetime of "proper" planes, which is surprising."
And since the universal planes left the experimetal flag in 2014[2] it is
safe to remove the support now.
[1] https://gitlab.freedesktop.org/wayland/weston/-/issues/427
[2] https://cgit.freedesktop.org/drm/drm-tip/commit/?id=c7dbc6c9ae5c3baa3be755a228a349374d043b5b
Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
Fix an issue where the keyboard leds will go out of sync when a new
keyboard is connected.
The issue can be easily reproduced by connecting two keyboards, enabling
caps lock, and reconnecting one of the keyboards. Without the patch the
leds on both keyboards will turn off while the actual caps lock state
will stay enabled.
Signed-off-by: Samu Nuutamo <samu.nuutamo@gmail.com>
Fixes a definitely lost:
== 56 bytes in 1 blocks are definitely lost in loss record 16 of 45
== at 0x48450F8: malloc (vg_replace_malloc.c:309)
== by 0x4B55E93: wl_event_loop_add_timer (event-loop.c:197)
== by 0x4126CF: weston_compositor_create (in /usr/local/bin/weston)
== by 0x409997: main (in /usr/local/bin/weston)
Signed-off-by: Lujin Wang <luwang@nvidia.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Layers did not have a fini sequence before, which means the compositor
layer list might have stale pointers temporarily when shutting down. A
bigger problem might be having views linger after the destruction of the
layer.
These problems were not observed yet, but if they exist, this patch
should help to find them and then fix them.
The check in weston_compositor_shutdown() is not an assert yet, because
it will trigger until all components call weston_layer_fini() correctly.
Some components do not even have a tear-down function to call it from at
all, like fullscreen-shell.
The same with the check in weston_layer_fini().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These are all the remaining places that still use the global view_list,
and cannot avoid it. Add a comment to explain why in each.
Now all places that use view_list have been audited for paint node
lists.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Iterate paint nodes instead of the global view list. Right now this does
not change behavior.
This is a step towards using per-output view lists that can then be
optimized for the output in libweston core.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Iterate paint nodes instead of the global view list. Right now this does
not change behavior.
This is a step towards using per-output view lists that can then be
optimized for the output in libweston core.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Iterate paint nodes instead of the global view list. Right now this does
not change behavior.
This is a step towards using per-output view lists that can then be
optimized for the output in libweston core.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Iterate paint nodes instead of the global view list. Right now this does
not change behavior.
This is a step towards using per-output view lists that can then be
optimized for the output in libweston core.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Iterate paint nodes instead of the global view list. Right now this does
not change behavior.
This is a step towards using per-output view lists that can then be
optimized for the output in libweston core.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch creates a per-output paint node list in the same z-order as
the global view_list in weston_compositor.
The next step is to switch output repaints and backends to use the
z-order list instead of view_list.
Having a per-output paint node list for repaints allows including only
those paint nodes that actually contribute to the output image, so that
completely occluded and out-of-screen views can be ignored in libweston
core already.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This new object is created for every surface-view-output triplet. As
there is always exactly one surface for a view and it does not change
during a view's lifetime, this is really for a view-output pair or a
surface-output pair.
The object is created on-demand as a part of preparing for an output
repaint, so it applies only to surfaces that are going through repaint.
A prerequisite for that is that the surface is mapped, which means it
has a mapped view.
When any one of surface or view gets destroyed or output gets disabled,
all related paint nodes are destroyed.
In future, paint node will be useful for caching surface-output or
view-output pair dependent data:
- damage regions for overlapping outputs
- color transformations
- backend-specific bookkeeping (e.g. DRM KMS plane assigments)
- per-output repaint lists
- surface geometry transformed into output space
Suggested by Daniel Stone in
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582#note_899406
PS. The call in weston_view_destroy() to
weston_compositor_build_view_list() might be so that if the view has
sub-surfaces, rebuilding the view list removes those those too and
automagically deletes their views.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use the real name of the seat instead of calling each seat 'default'. This makes
it easier to identify the current seat in a multi-seat environment.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
This change fixes the "touch-up" operation to clear "data_source"
by setting "seat" to NULL. This operation is done in the mouse button
release operation, but seems to have been forgotten in the "touch up"
case.
Forgetting this operation causes weston to send a "premature finish
request" error to the client which causes the client to exit.
This issue can be reproduced with the "weston-dnd" program by performing
a drag-and-drop operation with a touch input device. Once the drag
is released, the weston-dnd program will exit with an error.
Signed-off-by: Jonathan Marler <johnnymarler@gmail.com>
If sprites_are_broken, then we will only ever arrive in renderer_only
mode, so this case will be caught by the checks above.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Avoids an user-after-free when destroying the surface, like in the
following ASAN message:
==25180==ERROR: AddressSanitizer: heap-use-after-free on address 0x6060000589d8 at pc 0x7ff70a4f7102 bp 0x7fff8f7e13b0 sp 0x7fff8f7e13a8
READ of size 8 at 0x6060000589d8 thread T0
#0 0x7ff70a4f7101 in weston_schedule_surface_protection_update ../libweston/compositor.c:1163
#1 0x7ff70a4f743b in weston_surface_update_output_mask ../libweston/compositor.c:1212
#2 0x7ff70a4f7a47 in weston_surface_assign_output ../libweston/compositor.c:1298
#3 0x7ff70a4f7f44 in weston_view_assign_output ../libweston/compositor.c:1348
#4 0x7ff70a4fa12f in weston_view_update_transform ../libweston/compositor.c:1589
#5 0x7ff70a4ffc20 in view_list_add ../libweston/compositor.c:2657
#6 0x7ff70a5000ee in weston_compositor_build_view_list ../libweston/compositor.c:2688
#7 0x7ff70a4fd577 in weston_view_destroy ../libweston/compositor.c:2202
#8 0x7ff70a4fd7df in weston_surface_destroy ../libweston/compositor.c:2239
#9 0x7ff70a4fdbb0 in destroy_surface ../libweston/compositor.c:2285
#10 0x7ff70a4a2d3e in destroy_resource ../src/wayland-server.c:723
#11 0x7ff70a4a8940 in for_each_helper ../src/wayland-util.c:372
#12 0x7ff70a4a8e1f in wl_map_for_each ../src/wayland-util.c:385
#13 0x7ff70a4a3748 in wl_client_destroy ../src/wayland-server.c:882
#14 0x7ff6fe04e866 in shell_destroy ../desktop-shell/shell.c:5004
#15 0x7ff70a4ee923 in wl_signal_emit /home/mvlad/install-amd64/include/wayland-server-core.h:481
#16 0x7ff70a51598d in weston_compositor_destroy ../libweston/compositor.c:7903
#17 0x7ff70a903a58 in wet_main ../compositor/main.c:3493
#18 0x560de7b3b179 in main ../compositor/executable.c:33
#19 0x7ff70a73ecc9 in __libc_start_main ../csu/libc-start.c:308
#20 0x560de7b3b099 in _start (/home/mvlad/install-amd64/bin/weston+0x1099)
0x6060000589d8 is located 56 bytes inside of 64-byte region [0x6060000589a0,0x6060000589e0)
freed by thread T0 here:
#0 0x7ff70a9d3b6f in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xa9b6f)
#1 0x7ff70a5167d2 in cp_destroy_listener ../libweston/content-protection.c:193
#2 0x7ff70a4ee923 in wl_signal_emit /home/mvlad/install-amd64/include/wayland-server-core.h:481
#3 0x7ff70a51598d in weston_compositor_destroy ../libweston/compositor.c:7903
#4 0x7ff70a903a58 in wet_main ../compositor/main.c:3493
#5 0x560de7b3b179 in main ../compositor/executable.c:33
#6 0x7ff70a73ecc9 in __libc_start_main ../csu/libc-start.c:308
previously allocated by thread T0 here:
#0 0x7ff70a9d4037 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xaa037)
#1 0x7ff70a5160aa in zalloc ../include/libweston/zalloc.h:38
#2 0x7ff70a516cda in weston_compositor_enable_content_protection ../libweston/content-protection.c:329
#3 0x7ff7070247e0 in drm_backend_create ../libweston/backend-drm/drm.c:3180
#4 0x7ff707024cae in weston_backend_init ../libweston/backend-drm/drm.c:3250
#5 0x7ff70a515d02 in weston_compositor_load_backend ../libweston/compositor.c:7999
#6 0x7ff70a8fbcfb in load_drm_backend ../compositor/main.c:2614
#7 0x7ff70a900b46 in load_backend ../compositor/main.c:3103
#8 0x7ff70a902ecd in wet_main ../compositor/main.c:3380
#9 0x560de7b3b179 in main ../compositor/executable.c:33
#10 0x7ff70a73ecc9 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-use-after-free ../libweston/compositor.c:1163 in weston_schedule_surface_protection_update
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Weston internals and Wayland clients assume that output presentation
clock cannot go backwards. Therefore require unconditionally that KMS
uses the monotonic clock.
The kernel unconditionally supports DRM_CAP_TIMESTAMP_MONOTONIC. See:
commit 25e1a79874eb3821d93310c908cc0a81b47af060
Author: Arnd Bergmann <arnd@arndb.de>
Date: Wed Oct 11 17:20:13 2017 +0200
drm: vblank: remove drm_timestamp_monotonic parameter
That one removed the final possibility of DRM_CAP_TIMESTAMP_MONOTONIC
being false, by removing the module option. But even before that, all
drivers have been supporting monotonic, since
commit c61eef726a78ae77b6ce223d01ea2130f465fe5c
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Oct 23 18:53:26 2012 +0000
drm: add support for monotonic vblank timestamps
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This drops the software presentation clocks that could jump backwards.
See the previous commit "libweston: assert frame times never go
backwards" for the rationale.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Adding this check was prompted by
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/609
There is no reason to allow frame times jump backwards, and apparently
we already have code that makes that assumption.
DRM KMS uses CLOCK_MONOTONIC as the vblank and page flip timestamps,
which by definition cannot go backwards. Other backends call
weston_compositor_set_presentation_clock_software().
Frame times are also reported directly to Wayland clients via
presentation-time extension, and clients too will not expect that the
timestamp could go backwards.
So make sure time can never go backwards.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
As observed in #420 (Running Weston under Weston's kiosk shell with
multiple outputs causes the scrollback to go nuts), not
being able to cope with (a correct) resize of the parent surface would
cause the client weston instance to spin forever. If dispatching
failed, just exit.
Fixes#420
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As an in-flight resize call might cause a call to
wayland_output_destroy_shm_buffers() to go over a list of free_buffers
list. Just initialize the lists before attempting to create the parent
surface to avoid it.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
fb->format is *pixel_format_info, whereas fb->format->format is the
actual DRM/wl_shm format code we want to see here. Fix the drm_debug()
call accordingly.
Signed-off-by: Bastian Krause <bst@pengutronix.de>
In "backend-drm: simplify compile time array copy", ARRAY_COPY was
introduced to be used by the DRM-backend.
In this patch we expand its usage to other code where hardcoded arrays
are being copied.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In drm_fb_get_from_dmabuf() we have some compile time array copies, and
multiple static_assert() calls are needed (for safety). This makes the
code unpleasant to read.
Add ARRAY_COPY macro, to simplify the code.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
EGL implementations have no way to tell that implicit modifiers are not
supported. So Weston must consider that implicit modifiers are
supported. Always add DRM_FORMAT_MOD_INVALID to formats that we query
from EGL.
The implication is that clients using dmabuf extension may pick
DRM_FORMAT_MOD_INVALID to allocate their buffers, and so these buffers
will not be directly imported to KMS and placed in planes. See commit
"backend-drm: do not import dmabuf buffers with no modifiers to KMS" for
more details.
But we should not avoid advertising DRM_FORMAT_MOD_INVALID in the dmabuf
protocol just because we hope that the client don't choose it, it's not
our choice.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit "libweston: add struct weston_drm_format" struct
weston_drm_format and its helper functions were added to libweston.
The functions query_dmabuf_formats and query_dmabuf_modifiers are very
specific to GL-renderer and its internals. So instead of exposing them
in libweston, query and store DRM formats and modifiers internally in
GL-renderer. Also, add a vfunction to struct weston_renderer in order
to retrieve the formats.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit "backend-drm: do not import dmabuf buffers with no modifiers
to KMS" we've stopped to import dmabuf with no modifiers to KMS.
In this patch we document why we can still import wl_drm buffers with no
modifiers to KMS.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We can't tell the layout of a buffer that has been allocated with no
modifiers. Although usually drivers use linear layouts to allocate in
these cases, it is not a rule. It can use a tiling layout, for instance,
under the hood.
So it is not safe to import a buffer with no modifiers to KMS, as it
can't tell the buffer layout and this may result in garbage being
displayed. In this patch we start to require explicit modifiers to
import buffers to KMS.
In most cases things just work as expected, but just because both sides
(display and render driver) usually end up using the linear layout when
modifiers are not exposed. It also works on systems where the display
and render devices are tied (desktops with Intel or AMD, for instance),
as there's only one driver and it knows the layout of the buffer (no
need to guess).
But in SoC's where the display and render device are split, things can
go wrong. It is better to lose performance and not break things. To
solve the problem, drivers should be updated to expose modifiers (even
if only DRM_FORMAT_MOD_LINEAR), as the concept of implicit modifiers is
the root of the problem.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit "backend-drm: add DRM_FORMAT_MOD_INVALID to modifier sets when
no modifiers are supported" we've changed the code that iterates through
the IN_FORMATS blob property. Now it adds DRM_FORMAT_MOD_INVALID for
formats exposed without modifiers.
But the thing is that there shouldn't be formats in the IN_FORMATS blob
exposed without modifiers, as the blob has been added after the
introduction of the explicit modifiers API in the kernel. For now,
there's nothing in the kernel to ensure this correct behavior. So
instead of adding DRM_FORMAT_MOD_INVALID in this case, ignore these
formats, as userspace can't do much in this case.
In the future this may be fixed by the kernel. Or maybe the following MR
in libdrm, which adds an iterator API for the IN_FORMATS blob:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/146
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
From now on, when we can't know the modifiers supported for a certain
format, we add DRM_FORMAT_MOD_INVALID to its modifier set.
There is some parts where nothing is being added an others where
DRM_FORMAT_MOD_LINEAR is being added, so fix them.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In create_gbm_surface() we may allocate with no modifiers in the
following situations:
1. old GBM version, so HAVE_GBM_MODIFIERS is false;
2. the KMS driver does not support modifiers;
3. if allocating with modifiers failed, what can happen when the KMS
display device supports modifiers but the GBM driver does not, e.g.
the old i915 Mesa driver.
The comment was only stating the third situation, so add the other two.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The function drm_output_init_egl() is too big, so move the code to
create the gbm surface to a separate function: create_gbm_surface().
Also made some minor style changes to the code that has been moved, in
order to improve readability.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit "libweston: add struct weston_drm_format" struct
weston_drm_format and its helper functions were added to libweston.
Also, unit tests for this API have been added in commit "tests: add unit
tests for struct weston_drm_format".
Start to use this API in the DRM-backend, as it enhances the code by
avoiding repetition and ensuring correctness.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Co-authored-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Add struct weston_drm_format, which contains a DRM format and a list of
modifiers. The patch also adds struct weston_drm_format_array and some
helper functions to handle these two new structs: init/fini, find
elements, add elements, etc.
This will be useful in the next commits in which we add support to
dmabuf-hints. It also allows a cleanup in the DRM-backend, where we
currently have a similar struct in drm_plane but with no helper
functions, so the code to handle it is scattered throughout the
functions and there is a lot of repetition.
This patch is based on previous work of Scott Anderson (@ascent).
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In drm_output_prepare_plane_view() we iterate the list of planes and add
them as candidates to promote the view to one of them.
Cursor planes do not support buffers other than wl_shm (at least for
now). So when we have a dmabuf or an EGL buffer in the view, the
function drm_output_plane_cursor_has_valid_format() returns false and
the cursor plane is not added to the candidate list.
In this patch we move the responsibility of doing this from
drm_output_plane_cursor_has_valid_format() to
drm_output_prepare_plane_view() itself, as the incompatibility between
other types of buffers and cursor planes is different from the
incompatibility between formats. This makes the code easier to read
and also documents the current incompatibility between cursor planes
and buffers that are not created through wl_shm.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the absence of universal planes support,
drm_output_find_special_plane() sets the plane format to zero as a
placeholder. Then in drm_output_init_planes() it sets the format to
output->gbm_format.
As output->gbm_format is already set by the time we call
drm_output_find_special_plane(), simply set the plane format to it
directly in this function. This makes the code clearer, as there is no
reason to use the placeholder.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
get_vt is used to check if VTs are enabled, by verifying that a VT greater than
0 is returned.
libseat always implements switching, with switch to an active session
currently being a noop in all backends. libseat does not currently have
a get_vt implementation. Make get_vt errors more explicit, and allow VT
switching anyway if the error is ENOSYS.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
This adds support for libseat as a seat backend. libseat provides seatd,
(e)logind and direct seat backends as compile-time and runtime options.
The backend is currently disabled by default. It can be enabled through the
launcher-libseat option.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
In some situations, like positioning a sub-surface that exceeds the
output's dimensions we would adjust the plane state dimensions to some
lower values to that of the buffer. That would ultimately trip the cursor
update function because the buffer itself actually exceeds the maximum
size/dimension of the cursor.
The plane state destination co-ordinates is the area of the view which
is visible on the output, which in some situations, would actually be
smaller than the original buffer dimensions (making it so that it will
pass the cropping/scaling check), but depending on of
how large is the surface buffer, it would tripping the assert wrt to
cursor width/height dimensions.
This hasn't been seen so far due to the fact that until recently we had
a cursor surface that always reached the cursor plane and that was
already being set-up by default (with desktop-shell, which is no longer
the case), and also because kiosk-shell, which doesn't set-up a cursor
surface, was not available.
This adds a check to skip placing the view in the cursor plane if the
buffer dimensions exceed the cursor permitted width/height.
(Suggested-by Daniel Stone).
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
fixes issue #484 (race condition with message to/from weston launch)
The race condition occurs after weston sends the WESTON_LAUNCHER_OPEN
message to weston-launch. The race is between when weston-launch replies
with the fd handle versus weston-launch sending an activation message. If
weston-launch sends an activation message before sending the fd handle,
then weston will be in an invalid state.
To fix this, I modified the fd handle reply that weston-launch sends to
include a message id at the beginning, which I called
WESTON_LAUNCHER_OPEN_REPLY. Along with this, weston now inspects the
first part of any reply to determine whether it is an activation message
or a reply to the OPEN message. In the newly handled case that it's an
activation message, it tracks whether the latest result is a deactivate
message and stores it in a flag to be handled once the open function has
completed.
Signed-off-by: Jonathan Marler <johnnymarler@gmail.com>
Now that pieces of color management implementation start to land, the
fallback shader becomes even more special than before. It is the only
case where the compositor ignores color management.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The texture target can be uniquely inferred from the shader variant, so
do not store texture target separately.
Shortens the code a bit.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Replace the shader_requirements with just shader_variant. The variant is
the only thing gl_surface_state will actually carry. All the other
requirements fields are always unused.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch gathers all values to be loaded to shader uniforms into a new
struct gl_shader_config along with texture target and filter
information. Struct gl_shader becomes opaque outside of gl-shaders.c.
Everything that used or open-coded these are converted.
The aim is to make gl-renderer.c easier to read. Previously, uniform
values were loaded up in various places, texture units were set up in
one place, textures were bound into units in different places. Stuff was
all over the place.
Now, shader requirements and associated uniform data is stored in a
single struct. The data is loaded into a shader program in one function
only.
That makes it easy for things like maybe_censor_override() to replace
the whole config rather than poke only the shader requirements. This may
not look like much right now, but when color management adds more
uniforms and even hardcoded color need to go through the proper color
pipeline, doing things the old way would become intractable.
Similar simplification can be seen in draw_view(), where the RGBA->RGBX
override becomes more contained. There is no longer a need to "pre-load"
the shader used by triangle fan debug. Triangle fan debug no longer
needs to play tricks with saving and restoring the current shader.
The real benefit of this change will probably come when almost all
shader operations need to take color spaces into account. That means
filling in gl_shader_config parts based on a color transformation.
This is based on an idea Sebastian already used in his Weston color
management work.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Avoid looking up 'gr' from view->compositor by passing it explicitly
into the functions needing it.
Also fixes the whitespace in repaint_region() signature.
Clarifies code by removing local variables, but also future changes will
need 'gr' more.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A future change will call this function from draw_view(), so move it
upwards to avoid adding a function declaration.
No functional or even cosmetic change.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These functions are related to shaders, so they are more at home in
gl-shaders.c. gl-renderer.c is too long already.
This allows making a couple functions static while the moved functions
become non-static. Future changes turn some of these functions into
static again, with the ultimate goal of making struct gl_shader opaque.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Tearing down the drm-backend when there are no input devices, would call
for the gbm device destruction before compositor shutdown. The latter
would call into the renderer detroy function and assume that the
EGLDisplay, which was created using the before-mentioned gbm device, is
still available. This patch re-orders the gbm destruction after the
compositor shutdown when no one would make use of it.
Fixes: #314
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Daniel Stone <daniel.stone@collabora.com>
Everywhere else uses #ifdef, this used just #if. When the next commit
adds -Wundef to the compiler options, this #if here will start failing
as ENABLE_EGL is undefined.
It would be much better to use Meson's set10() for ENABLE_EGL and change
all #ifdef into #if, but I opted for the smaller change for now.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds a heuristic for freeing shader programs that have not been
needed for a while. The intention is to stop Weston accumulating shader
programs indefinitely, especially in the future when color management
will explode the number of possible different shader programs.
Shader programs that have not been used in the past minute are freed,
except always keep the ten most recently used shader programs anyway.
The former rule is to ensure we keep shader programs that are actively
used regardless of how many. The latter rule is to prevent freeing too
many shader programs after Weston has been idle for a long time and then
repaints just a small area. Many of the shader programs could still be
relevant even though not needed in the first repaint after idle.
The numbers ten and one minute in the above are arbitrary and not based
on anything.
These heuristics are simpler to implement than e.g. views taking
references on shader programs. Expiry by time allows shader programs to
survive a while even after their last user is gone, with the hope of
being re-used soon. Tracking actual use instead of references also
adapts to what is actually visible rather than what merely exists.
Keeping the shader list in most recently used order might also make
gl_renderer_get_program() more efficient on average.
last_repaint_start time is used for shader timestamp to avoid calling
clock_gettime() more often. Adding that variable is an ABI break, but
libweston major has already been bumped to 10 since last release.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is useful for seeing that the shader program garbage collection
works in a future patch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
One more thing is coming to need this, so add the compositor pointer and
migrate existing places to use it where it simplifies things.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
I have verified that the conversion here follows ITU-R BT.601 except for
the offsets 16/256 and 128/256 which should be 16/255 and 128/255
respectively.
I used to following octave script to verify this:
rf = 0.299;
gf = 0.587;
bf = 0.114;
crdiv = 1.402;
cbdiv = 1.772;
M = [ rf, gf, bf ;
-rf / cbdiv, -gf / cbdiv, (1 - bf) / cbdiv;
(1 - rf) / crdiv, -gf / crdiv, -bf / crdiv ];
YCbCr = [ 'Y'; 'Cb'; 'Cr' ];
RGB = [ 'R'; 'G'; 'B' ];
eq = [ ' '; '='; ' ' ];
l = [ ' [ '; ' [ '; ' [ ' ];
r = [ ' ] '; ' ] '; ' ] ' ];
mat = [
sprintf('%9f %9f %9f', M(1,:));
sprintf('%9f %9f %9f', M(2,:));
sprintf('%9f %9f %9f', M(3,:));
];
[ l YCbCr r eq l mat r l RGB r ]
R = inv(M);
mat = [
sprintf('%9f %9f %9f', R(1,:));
sprintf('%9f %9f %9f', R(2,:));
sprintf('%9f %9f %9f', R(3,:));
];
[ l RGB r eq l mat r l YCbCr r ]
[ R(:,1), R(:,2:3) .* (255/224) ]
The final matrix printed is what the shader uses down to +/- one digit,
so at least 7 correct decimals.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Sampling input texture has nothing to do with view alpha. This clarifies
the code structure.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reading the input texture is just one part of the future color pipeline,
so separate it into a function of its own. This makes it easier to add
more steps to the pipeline, and shows the green tint is separate as
well.
Making use of early returns, reducing the if-else ladder should help
with readability. Sharing the call to yuva2rgba() likewise.
Setting yuva.w = alpha is not shared though, in case support for AYUV
format might be added in the future.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Do not call texture2D() in the shader when we already have the result.
Simpler code, maybe even a little bit faster?
Suggested-by: Harish Krupo <harishkrupo@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These same magic constants were used in all cases, so move them into a
common place.
While we are touching all these lines, also change from the four floats
into a vec4. This allows further clean-up in the next patch.
This makes the code easier to read.
Behavior and results are unchanged.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Mathematically the result is the same, while multiplying RGB with alpha
is easier to understand as correct than the earlier form.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A more unique name is easier to grep for. Using 'color' as a local
variable might be useful in the future.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This support is added so that the XYUV shader variant can be tested with
wl_shm from the test suite.
Libwayland version requirement is bumped to get WL_SHM_FORMAT_XYUV8888.
Libwayland is bumped to 1.18 too in the CI image. libwayland-dev package
is dropped, because we build wayland anyway.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This header is for sharing fallback definitions for drm_fourcc.h. A new
test in tests/yuv-buffer-test.c is going to be needing XYUV8888 format,
and more new formats will be expected with HDR supports.
Share these fallback definitions in one place instead of copying them
all over.
All users of drm_fourcc.h are converted to include weston-drm-fourcc.h
instead for consistency: have the same definitions available everywhere.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
MOD_INVALID came with libdrm 2.4.83 and MOD_LINEAR came with libdrm
2.4.82. libweston unconditionally depends on libdrm >= 2.4.95, so the
fallback is not necessary.
Since linux-dmabuf.h itself has no use for these and also forgets to
include drm_fourcc.h, .c files including drm_fourcc.h after this header
would trigger compiler warnings.
linux-dmabuf.c does need these, so add the proper include.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
These were introduced in libdrm 2.4.68, commit
268ae7cae5afd76462c3ef14ed9021a2d40c2e57. Weston unconditionally
requires libdrm >= 2.4.95, so these fallback definitions are
unnecessary now.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Extend the existing output-damage test to test
blit_shadow_to_output() specifically. This function had problems
originally, so make sure they can't reappear.
The added quirk is explained in the test.
An additional check of the quirk in gl_renderer_output_create() ensures
that the shadow framebuffer is really used. The test could false-pass if
the shadow is not used.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Proper color management will need blending done with linear light pixel
values, that is, EOTF applied before blending, and then inverse-EOTF
applied for scanout after blending. The simplest way to set that up is
to use an intemediate framebuffer a.k.a shadow buffer containing the
composited image in linear light values, then blit from that to the
actual framebuffer.
This patch implements the shadow buffer, but the linear light
blending is left for another patch. This allows GL-renderer to turn
WESTON_CAP_COLOR_OPS on.
Half-float is chosen as the buffer format because linear light values
require more bits to encode with sufficient precision than the usual
non-linear pixel values.
v2: Use /* */ instead of // (Pekka)
Rename fbo and tex to shadow_{fbo,tex} (Pekka)
Check for OpenGLES capabilities before creating
shadow_{tex,fbo} (Pekka)
Signed-off-by: Harish Krupo <harishkrupo@gmail.com>
v3: Rebased.
Simplified GL version checks (Sebastian)
Apply changes from "libweston: add color ops cap and bool renderer
shadow buffer"
Renamed supports_half_float_texture to has_gl_half_float to
follow the existing naming pattern.
Introduce gl_renderer_create_shadow_16f().
Undo moving of glViewport() call.
Replace half_float_texture_enabled with shadow_exists().
Introduce struct gl_output_state_shadow.
Assert no resizing with shadow.
Fix triangle fan debug.
Rename repaint_from_texture() to blit_shadow_to_output().
Rewrite commit message because linear light blending is not
implemented in this patch.
Fix blit_shadow_to_output() for scaled/transformed outputs and
remove redundant code.
Fix has_gl_half_float determination.
v4: Disable blending in blit_shadow. (Daniel)
Port to gl_renderer_get_program().
Make a generic fbo-texture struct with parameterized format. (Daniel)
Change has_gl_half_float into gl_half_float_type.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Converting a region from global coordinates to output pixel coordinates
will become useful in GL-renderer soon, so move this function to be
shared. It is tricky to reinvent.
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>
This helps accounting how many shaders live in the cache, what the
shader source code is, and when shaders are compiled.
Signed-off-by: Harish Krupo <harishkrupo@gmail.com>
v2: Resolved rebase conflicts.
Put shader_scope in struct gl_renderer, remove struct
gl_shader_generator.
Wrote commit message.
Rebased for "gl-renderer: rewrite fragment shaders" which completely
changed how shader sources are generated.
Added cache statistics to debug output on subscribe.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Various functions leave the current active texture as whatever. The
functions touched in this commit forgot to reset the active texture to
slot 0 before binding their textures. If not explicitly unbound, this
could leave textures lingering in unused slots, perhaps. Not sure if
that could cause any harm, but for consistency's sake, always use slot 0
when not multitexturing.
Found by code inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If shader compiling on demand fails, then rather than using whatever
random shader happens to be current, use an explicit fallback shader
painting stuff brown.
The color is chosen dim enough to hopefully not cause problems even in
a HDR setting as it will be written verbatim into the fb/shadow.
This also prevents NULL dereference on shader->key.variant in
draw_view().
One way to test this shader is to hack fragment.glsl:
#if DEF_VARIANT == SHADER_VARIANT_EXTERNAL
#extension GL_OES_EGL_image_external : require
+#error haa haa
#endif
and then run e.g. weston-simple-dmabuf-v4l -f YUYV
with vivid kernel module loaded. This worked on Intel.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If we are trying to use a NULL shader, it is likely that the shader
compilation failed for some reason. Since we are trying this for a view,
the failure was probably triggered by a client. If there is a client,
get rid of it by sending it a protocol error. Hopefully the compositor
can then continue operation after a glitch on screen.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch modifies the shader generation code so that the shaders are
stitched together based on the requirement instead of creating them
during initialization. This is necessary for HDR use cases where each
surface would have different properties based on which different
de-gamma or tone mapping or gamma shaders are stitched together.
v2: Use /* */ instead of // (Pekka)
Move shader strings to gl-shaders.c file (Pekka)
Remove Makefile.am changes (Pekka)
Use a struct instead of uint32_t for storing requirements (Pekka)
Clean up shader list on destroy (Pekka)
Rename shader_release -> shader_destroy (Pekka)
Move shader creation/deletion into gl-shaders.c (Pekka)
Use create_shaders's multi string capbility instead of
concatenating (Pekka)
v3: Add length check when adding shader string (Pekka)
Signed-off-by: Harish Krupo <harishkrupo@gmail.com>
v4: Rebased, PROTECTION_MODE_ENFORCED converted.
Dropped unnecessary { }.
Ported setup_censor_overrides().
Split out moving code into gl-shaders.c.
Changed to follow "gl-renderer: rewrite fragment shaders",
no more shader source stitching.
Added SHADER_VARIANT_XYUV.
Const'fy function arguments.
Added gl_shader_requirements_cmp() and moved the early return in
use_gl_program().
Moved use_gl_program() before first use in file.
Split solid shader requirements by use case: requirements_censor and
requirements_triangle_fan.
Simplified fragment_debug_binding() since no need to force anything.
Ensure struct gl_shader_requirements has no padding. This allows us
to use normal C syntax instead of memset() and memcpy() when
initializing or assigning. See also:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2071
Make it also a bitfield to squeeze the size.
v5: Move wl_list_insert() into gl_shader_create() (Daniel)
Compare variant to explicit value. (Daniel)
Change functions to gl_renderer_get_program,
gl_renderer_use_program, and
gl_renderer_use_program_with_view_uniforms.
Use local variable instead of gr->current_shader. (Daniel)
Simplified gl_renderer_get_program.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Do not change in setup_censor_overrides() and then put back gs->shader
in draw_view() when the shader needs to be something else than what the
surface content calls for.
This makes the logic simpler, and makes following changes simpler as
well.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
To help debugging shader compilation errors, print the shader source the
way it was given to the GLSL compiler and with line numbers that match
the compiler error messages.
This is necessary because some snippets are added at runtime to the
beginning, the source is not only what is in the respective .glsl file.
I did look into using #line directives, but you cannot put source file
names to it, only "source string numbers" which must be an integer
expression. If we used #line, the reader would need to know that string
number 0 is the version, string 1 is the config and string number 2 is
fragment.glsl. I think that would have been too cumbersome.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The main goal of this patch is to improve the readability of how and
what fragment shaders are generated.
Instead of having C code that assembles each shader variant from literal
string snippets, create one big fragment shader source that has
everything in it. This relies on a GLSL compiler to optimize statically
false conditions and unused uniforms away.
Having all the fragment shader code in one file, uncluttered by C string
literal syntax, improves readability significantly. A disadvantage is
that the code is more verbose, but it allows comments much better.
The actual shader code is kept unchanged except:
- FRAGMENT_CONVERT_YUV macro is now a proper function
- GLSL version is explicitly set to 1.00 ES
- RGBA and EXTERNAL use the same path, the difference is how the sampler
is declared
Further shader code consolidation is possible, but is left for another
time.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch adds the tooling for incorporating files as C data, so that
files can be built into the binaries. The tool is in Python to avoid
adding extra dependencies like xxd.
xxd.py is copied from Mesa as-is, from commit
b729cd58d76f97f3fc04a67569535ee5ef2f5278 (master branch on 2021-01-26),
a.k.a 21.0-branchpoint-635-gb729cd58d76.
Moving the GLSL vertex shader into a separate file is not that
interesting, the purpose of this commit is to provide a simple
demonstration of the tooling. The real benefits come in a following
patch where the fragment shaders are re-written and externalized.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is purely moving code as is with no changes other than making the
three functions non-static.
Originally this was part of "gl-renderer: Requirement based shader
generation" by Harish Krupo, but that patch made also big changes to the
code at the same time. Patches are easier to review when code movement
is separate from behavioral changes, therefore I introduced this patch.
Cc: Harish Krupo <harishkrupo@gmail.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The main point here is to print "GL ES %d.%d" instead of "GL ES 2"
because GL-renderer can and will use GL ES 3 features when present.
Saying it's GL ES 2 renderer is not quite true.
To print that, I need to extract major, minor from gr->gl_version and
those didn't have ready made macros yet. While writing the extraction,
make all these trivial functions, so that the compiler might warn us if
one passes e.g. negative literal numbers to gr_gl_version(). Explicit
types help keeping the bit operations safe too.
The only purpose for GR_GL_VERSION_INVALID was to fall back to version
2.0. Moving the fallback and logging into get_gl_version() makes that
macro unnecessary.
Finally, just in case GL version string contained garbage, reject
negative version numbers.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This test ensures that client submitted damage goes to the screen
correctly, regardless of output scale or transform.
The added quirk is explained in the test that uses it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
For a pbuffer EGLSurface, assume that EGL swap behavior is "preserved"
which means buffer age is always 1 (after the very first
eglSwapBuffers()).
EGL pbuffers are always single-buffered.
Mesa EGL Surfaceless platform does not seem to expose EGL_EXT_buffer_age
that could have told us the same. Hence all repaints to pbuffer surfaces
used to need to repaint the whole output always. This patch makes
repainting only the latest damage possible.
Repainting only the latest damage is required for a future test on
output damage regions: "tests: add output damage test".
Technically, setting buffer_age to 1 is not correct before the very
first eglSwapBuffers(), but to keep the code simpler I chose to rely on
a newly enabled output always having full damage anyway.
Checking that EGL_SWAP_BEHAVIOR is EGL_BUFFER_PRESERVED would do too.
Unfortunately, Mesa seems to return EGL_BUFFER_DESTROYED, so I cannot
fail the headless-backend in that check. Even so, the output damage test
actually succeeds.
See also: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4278
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If full output damage is forced every time a screenshot is taken, the
test suite cannot take screenshots of damage as that would depend on
repainting only the damaged area.
Stop damaging the output and instead just schedule a repaint so the
screenshot can be taken. This is safe because:
- if any views were promoted to hw planes previously,
weston_output_disable_planes_incr() would force them to be demoted at
assing_planes() time causing damage via weston_view_move_to_plane()
- even when hardware primary plane has no damage, DRM-backend will not
skip calling to the renderer after commit
"drm-backend: do not skip renderer if capturing screen".
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The renderer must be called for any pending screen capture to complete.
Previously this was guaranteed by weston_screenshooter_shoot() forcing
full output damage, so damage was never empty. If the future,
screenshooting stops inflicting damage, and the damage on the primary
plane even after disabling hardware planes may be empty.
This patch ensures that screenshots do not get stuck until damage
occurs.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This prevents a segfault in libwayland-cursor when the parent compositor
doesn’t have any of the needed protocols implemented.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
This allows launcher-direct to run when seat0 has no TTYs
This checks for a proper /dev/tty0 device as /dev/tty0
does not get created by kernels compiled with CONFIG_VT=n
Add error logging in three different launcher backends:
launcher-logind, launcher-weston-launch, and launcher-direct
to indicate failures for easier debug
Signed-off-by: Anurup M <anurup.m@huawei.com>
Require GL_EXT_unpack_subimage unconditionally in GL-renderer. Without
this extension, it would take considerable effort in GL-renderer to
handle correctly images that contain row padding, either as a temporary
copy to remove padding or doing SubImage updates row by row.
I would guess that this path has gone long completely untested, and if
it was exercised, the rows never had padding thanks to 32-bit pixel
formats. Instead of writing tests to poke the corner cases and fixing
it, remove it.
This will make it easier to fix other problems in GL-renderer in this
area in the future - one less path to consider and many restrictions in
GL API gone.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Warn the user that this is not supposed to work. Developers who know
what they are doing know to ignore this message, others should think
twice.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If the launcher is told to use a non-default seat (not seat0), there
will not be a VT or tty to set up. VT/tty setup requires privileges.
This patch allows a non-root user to use launcher-direct, provided that
the seat is not the default. There is still the problem of opening DRM
and input devices, which is left for the user to solve.
This mode of operation is useful for developers who can set up a
secondary seat on their machine. You can run Weston/DRM from a terminal
window by pointing it to a non-default seat. You have to arrange a
DRM device by having an extra unused graphics card in the machine. You
also need dedicated input devices. Both the DRM device and the input
devices must be assigned to the secondary seat and device file
permissions adjusted so that they can be opened.
Doing so is an obvious security risk, as input could easily be
eavesdropped.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Some panels advertise both pointer/touch capabilities but without having
real capability of driving a cursor (they're basically touch panels) and
use USB as a communication tunnel to transfer/send out input events.
As we can't really tell if they're fake or not, only advertise to
clients pointer capabilities if we detect movement on the cursor/pointer.
We handle it at lower level as that allows to handle the case where
removal of a real pointer should also remove the cursor from being
displayed on the screen.
Signed-off-by: Marius Vlad <marius.vlad@collabora.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>
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>
gbm-drm.c includes gl-renderer.h. When EGL is enabled, that in turns
includes egl.h. As such, dependencies for drm should include EGL if
it is available.
This condition is modelled after a similar one in libweston/meson.build
Reported-by: Gary Bisson <gary.bisson@boundarydevices.com>
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Refik Tuzakli <tuzakli.refik@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Found mutable global variables with
$ grep -P '^static (?!const).*[=;]' -- compositor libweston shared
Mutable global or static variables make it harder to run several
compositor instances in the same process. That is what the test suite
would probably need to do to test wayland-backend.
This one variable does not need to be mutable.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Rework some functions in `drm.c` to reuse the `drmModeRes` and
reduce the usage of `drmModeGetResources` and `drmModeGetResources`.
Signed-off-by: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
96bef0517e "drm-backend: add support for
writeback connectors" started using DRM_MODE_CONNECTOR_WRITEBACK and
DRM_CLIENT_CAP_WRITEBACK_CONNECTORS. These were introduced in libdrm
2.4.95.
According to
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/311
Ubunut Xenial is the only mentioned distribution that does not provide a
libdrm new enough. I think that is fine to drop now, 2016 was a good
while ago.
Libdrm 2.4.95 also introduced DRM_CLIENT_CAP_ASPECT_RATIO,
DRM_MODE_PICTURE_ASPECT_64_27, DRM_MODE_PICTURE_ASPECT_256_135.
The fallback definitions for the above are dropped.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Properly release the seat on RDP disconnect. Using current master
branch which is commit d93c0f7059 ("backend-rdp: fix memory leak")
I was not able to reproduce the crash on reconnect as mentioned in the
current comment. Using Weston with rdp-backend directly as well as
using the screen-share plug-in allowed to reconnect just fine. Hence
release the Weston seat properly using weston_seat_release and free
the seat structure. This also avoids mouse pointers displayed for
every RDP connection.
Signed-off-by: Stefan Agner <stefan@agner.ch>
The stable FreeRDP 2.x branch has been released, so let's rely on that maintained
version and drop all the hacks for older versions. That makes the code and build
cleaner.
Signed-off-by: David Fort <contact@hardening-consulting.com>
Recognize writeback connectors and add 'struct drm_writeback'
objects in order to store them.
These objects are created and stored in a list by the time
that DRM-backend is initialized. This list is updated if a
writeback connector dynamically appears or is disconnected.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Instead of directly creating heads for the connectors in functions
drm_backend_create_heads() and drm_backend_update_connectors(),
add drm_backend_add_connector() that will handle this.
This split makes the code look better and will also make our lives
easier when we introduce writeback connectors.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Add helper function resources_has_connector(), what makes
the function drm_backend_update_connectors() look better.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
To deal with appearing/disappearing connectors we have the
function drm_backend_update_heads(). Rename it to
drm_backend_update_connectors(), as it is more in line with
what it does.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In case of success, drm_head_create() and drm_head_update_info()
take ownership of a connector. As this is an important
information, update the description of these functions
to include this.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The function drm_connector_assign_connector_info() should
not be calling functions to handle drm_head, as connectors
and heads are not the same thing after patch "drm-backend:
move connector data from struct drm_head to struct drm_connector".
Move drm_head specific calls to drm_head_update_info(). This
is more in line with the hierarchy of the objects and also
allow us to drop drm_head pointer from drm_connector.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Instead of calling drmModeGetConnector() in drm_head_create()
and drm_head_update_info(), it is better to call it in
drm_backend_create_heads() and drm_backend_update_heads().
Then we can pass the drmModeConnector object as parameter.
This does not change the behavior of the code, but help us
to avoid unnecessarily calling drmModeGetConnector().
Besides that, in the future we will have support for writeback
connectors. And so drm_backend_create_heads() will be reworked
to also populate a list of writeback connectors. To make this
work, we are going to need to know if a connector is of the
writeback type or not, to know if we should call drm_head_create()
or drm_writeback_create(). We can only tell the type of connector
if we have the drmModeConnector object.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Instead of calling drmModeObjectGetProperties() each time that we need
the connector properties, it is better to keep a reference for it in
struct drm_connector. This reference is only updated when is necessary.
E.g. hotplug events.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This is the first step in order to add support for writeback
connector in Weston. We don't want writeback connectors data
to be stored in 'struct drm_head' objects, as these objects are
used to output content and we should not use writeback connectors
for this purpose.
The writeback connectors will be stored in a new 'struct
drm_writeback', but the connector data is common between
'struct drm_head' and 'struct drm_writeback'.
So move connector data from 'struct drm_head' to 'struct
drm_connector'. This helps to avoid code duplication and makes
the code clearer.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In commit c1e89ba2 "compositor-drm: move connector fields into
drm_head" the function drm_head_assign_connector_info() was
introduced. By that time it was being used only at drm_head
creation, and not to handle connector changes.
In d2e6242e "compositor-drm: create heads for all connectors"
it started to be used also to handle connector changes. In
this scenario we replace old connector props with newer data.
Before doing this, free the old connector data to avoid memory
leak.
Note that as drm_property_info_free() is safe to be called on
a zero-initialized struct, we can call it even in the case where
the head is being created and there are no props yet.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Commit "drm-backend: move code to init/deinit planes to specific
functions" lost a chunk of drm_output_deinit() when moving code into
drm_output_deinit_planes(). Reinstate the missing chunk.
This fixes an endless loop over weston_compositor::plane_list when you
start with three monitors connected, unplug and re-plug one.
Fixes: 3be23eff99
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
After commit "drm-backend: move code to init/deinit planes to specific
functions" we have a specific function to init planes. As this function
does not set output->crtc, it should not set it to NULL in case of
failure. This is caller's responsibility.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There are some places where we can make some cosmetic changes
to make code simpler and easier to read. Make these cosmetic
changes. Note that they do not change the code behavior.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The code to init/deinit scanout and cursor planes was in
drm_output_init() and drm_output_deinit(). Move this code
to specific functions drm_output_init_planes() and
drm_output_deinit_planes(), as it makes the code clearer
and easier to maintain.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Now that we have a CRTC list in the DRM-backend, we can
iterate through it and look for the CRTCs that do not have
assigned outputs in order to find unused CRTCS.
So we can drop unused_crtcs from struct drm_backend and also
drop the functions drm_backend_update_unused_outputs() and
wl_array_remove_uint32().
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There are no 'struct drm_output' for CRTCs that are not active.
Also, CRTC data lives in 'struct drm_output'. This is causing
us some trouble, as the DRM-backend needs to program those
unnactive CRTCs to be off.
If the DRM-backend had the reference for every CRTC (being
active or not), it would make certain functions (e.g.
drm_pending_state_apply_atomic()) more simple and efficient.
Move CRTC data from 'struct drm_output' to 'struct drm_crtc',
as this is the first step to allow the DRM-backend to have
references for every CRTC.
Also, add list of CRTCs to DRM-backend object. Now the
DRM-backend is responsible for allocating/deallocating the CRTC
objects. The outputs will only reference, init and fini the CRTCs
in this list.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Try to make drm_output_state_propose a little more clear by reducing
divergence between plane and renderer modes towards the end, removing
a possibly-surprising conditional continue.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reduce the scope of surface_overlap to where it's actually used, which
is only in the per-view loop, where it gets initialised and destroyed
every time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Previously we assumed that cursor planes occluded nothing and would
always be blended, but overlay and scanout planes would always occlude
what's behind them. This is not actually true, as we can support alpha
blending on any kind of plane type now.
Remove the special case, which might hopefully fix some weird display
issues along the way. (Noticed by inspection.)
Signed-off-by: Daniel Stone <daniels@collabora.com>
We used to use planes_region for the output regions which were being
displayed on hardware planes; before we grew zpos awareness, we couldn't
have any planes overlapping with each other, since the ordering would be
undefined.
Since the zpos awareness though, this region is unused, so we can just
remove it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The opaque region is used to determine where the views underneath the current
view must be drawn. If the opaque is not clipped, then the area that is part of
the opaque region but not part of the scissor area is not drawn at all.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Subsurfaces inherit the scissor region from the parent surface. Currently
the region is updated at the end of weston_view_update_transform(). As a
result, the old region is used to clip the transform.boundingbox of the
subsurface.
Change the order to update the scissor region after the transform.matrix is
updated but before it is used.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
As from commit b7e5f10bf4, weston_view_is_opaque() is called from
debug_scene_graph_cb(), which on its own represents a (different)
scope. By default, we already have a subscriber for the 'log' scope,
which will cause a harmless, yet spurious, message.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Initially finish_frame() was never called in drm_output_update_complete() for
'dpms_off_pending = true'. This is wrong for repaint_status ==
REPAINT_AWAITING_COMPLETION and that was fixed in
68d49d772c ("compositor-drm: run finish_frame when
dpms is turned off in update_complete").
However finish_frame() may now be called for repaint_status !=
REPAINT_AWAITING_COMPLETION, which is not allowed and results in a failed
assertion.
Fix this by checking dpms and repaint_status unconditionally.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
It seem that we skipped to put back in TEXT mode the tty, in case a DRM
device node wasn't present at that time, or it isn't present at all. This
orders the destroy part correctly as to handle that case as well.
As a side effect, as the tty will still be set to GRAPHICS mode we will
require a manual change of the tty number, which might be not possible
on all systems. Properly putting back the tty to TEXT mode should avoid
that, and allows to re-use the same tty no in case the DRM device has
been created at a later point in time.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
In case of a crash tty remains in graphic mode. This change allows to restart weston without
taking care of the actual tty mode.
Signed-off-by: ahe <Andreas.Heynig@meetwise.com>
Allow to disable GBM modifiers at runtime using the environment variable
WESTON_DISABLE_GBM_MODIFIERS.
This can be useful for debugging or when modifiers cause issues, e.g. in
case modifiers use higher memory bandwidth and hence impose a lower
resolution limit as it is the case with Intel Kaby Lake graphics.
Related to: https://gitlab.freedesktop.org/wayland/weston/-/issues/404
Signed-off-by: Stefan Agner <stefan@agner.ch>
The pipewire plugin uses this API as well, not just the remoting plugin. So
enable it if either is enabled.
And disable pipewire in the no-gl-renderer CI build. The virtual outputs don't
work without it.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
If a surface is not visible, then is does not matter if the view is on multiple
outputs. It will be skipped anyways when the output is rendered.
So check first if the surface is acually visible on the output before doing any
checks that might force rendering. This avoids unnecessary rendering.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
When dissociating a universal plane from a crtc, we currently don't
reset the current state of the plane (plane->state_cur). When attempting
to use this plane in the future, we can run into invalid memory accesses
due to left over associations with potentially freed drm backend
objects. This commit resets the state of the scanout and cursor
universal planes associated with a crtc.
The following scenario exhibits the problem:
1. Start a (fullscreen) client that is suitable for and assigned to
the scanout plane. The plane's state_cur->output value is set.
2. Unplug the monitor: the scanout plane is "released" but still
maintains the state_cur->output association.
3. Replug the monitor: the plane is deemed unavailable due to an
existing, albeit invalid, state_cur->output value. Note the memory
errors trying to access the drm_output which was freed at step (2).
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
compositor_accumulate_damage() is called for each output during repaint.
The DRM backend will only set keep_buffer for the surfaces that are visible on
the current output. So a buffer_ref is released that may still be needed. When
the output that shows the surface is repainted, the buffer_ref is gone and the
surface cannot be put on a plane.
Ignore all surfaces that are not visible on the current output to avoid this.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Currently the debug output for 'drm-backend' can be confusing. In the output of
debug_scene_view_print() views may be listed as 'not opaque' but later, during
plane assignment, other views underneath such a view is reported as 'occluded on
our output'.
This happens because weston_view_is_opaque() has some extra checks to determine
if a view is fully opaque, such as 'is_opaque' provided by the renderer for
formats that have no alpha channel.
Use weston_view_is_opaque() in debug_scene_view_print() as well to get more
accurate results.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
There's a log that advertises support for universal planes. That
can make users think there's something wrong with Weston or their
systems when universal planes are not supported, but that's not
the case. Remove this log from the code.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The core Wayland protocol explicitly states that wl_keyboard.modifiers
must be send after wl_keyboard.enter.
This commit also changes the behavior of `seat_get_keyboard` to not
send `wl_keyboard.modifiers` in case where seat had pointer focus,
but not keyboard one.
Signed-off-by: Kirill Chibisov <contact@kchibisov.com>
Launcher-direct does not allow us to run using a different
seat from the default seat0. This happens because VTs are
only exposed to the default seat, and users that are on
non-default seat should not touch VTs.
Add check in launcher-direct to skip VT/tty management if user
is running on a non-default seat.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Surface roles are permanent, so it should not be cleaned up.
Fixes: #409
weston: ../libweston/compositor.c:4094: weston_surface_set_role: Assertion `role_name' failed.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
When there's neither configless nor surfaceless EGL extension
(i.e. not a Mesa driver), Weston falls back to a dummy pbuffer surface.
Weston attempts to find for that surface an EGL config but uses a NULL
array of pixel formats. This fails with the following messages:
EGL_KHR_surfaceless_context unavailable. Trying PbufferSurface
Found an EGLConfig matching { pbf; } but it is not usable because
neither EGL_KHR_no_config_context nor EGL_MESA_configless_context
are supported by EGL.
failed to choose EGL config for PbufferSurface
EGL error state: EGL_SUCCESS (0x3000)
Failed to initialise the GL renderer;
Signed-off-by: Tomek Bury <tomek.bury@broadcom.com>
This moves the creation of the blob to be earlier, to when the damage is
calculated. It replaces the damage tracked inside of the plane state
with the blob id itself.
This should stop creating new blob ids for TEST_ONLY commits, and them
being leaked in general, as the blob ids are now freed with the plane
state.
The FB_DAMAGE_CLIPS property is now always set if it's supported, and
will be 0 in the case that we have no damage information, which
signifies full damage to the kernel.
Signed-off-by: Scott Anderson <scott.anderson@collabora.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>
All timeline event timestamps are in CLOCK_MONOTONIC already. DRM KMS
timestamps are practically guaranteed to be CLOCK_MONOTONIC too, even though
presentation clock could theoretically be something else. For other backends,
the presentation clock is likely CLOCK_MONOTONIC_RAW due to
weston_compositor_set_presentation_clock_software().
This patch ensures that the recorded vblank timestamp is in CLOCK_MONOTONIC.
Otherwise interpreting the timeline traces might be difficult to do accurately,
since it would be hard to recover the relationship between the presentation
clock and timeline event timestamps.
The time conversion routine is the simplest possible, I don't think we need any
more accurate conversion for timeline purposes. Besides, DRM-backend is the
only backend where the timings actually matter, the other backends are
software-timed anyway.
Since the clock domain of the "vblank" attribute potentially changes, the
attribute is renamed. Wesgr never used this attribute.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Using the number of planes to determine if GL_TEXTURE_EXTERNAL_OES should be
used is incorrect with some modifiers: For example RGBA with a
I915_FORMAT_MOD_Y_TILED_CCS modifier has two planes.
Use eglQueryDmaBufModifiersEXT() to query if the current format/modifier only
supports GL_TEXTURE_EXTERNAL_OES.
Use the current code as fallback of modifiers are not supported.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
If a surface has subsurfaces then the surface itself is in the subsurface
list. To avoid printing it again there is a check to skip the child view,
if it is the same as the current view.
However, this fails when a surface with subsurfaces has two (or more) views:
The check to skip the parent fails for the other view and the two views are
printed again and again until a stack overflow occurs.
So instead check if the parent view of the subsurface view is the current
view. This way, any view that does not belong to a real subsurface is
skipped.
As a side effect, this ensures that each view of the subsurfaces is only
printed once at the correct place in the hierarchy.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Without universal plane, the weston crashes with null pointer access in
set_gbm_format function because that function called before output
enable function. By changing timing to set color format for primary
plane in this case, this issue fixes.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
pixman_renderer_output_create currently takes a flags enum bitmask for
its options. Switch this to using a structure, so we can introduce other
non-boolean options.
Signed-off-by: Daniel Stone <daniels@collabora.com>
gl_rendererer's output_pbuffer_create has a lot of arguments now. Add a
structure for the options to make it more clear what is what.
This is in preparation for adding bare-integer arguments which are ripe
for confusion when passing positional arguments.
Signed-off-by: Daniel Stone <daniels@collabora.com>
gl_rendererer's output_window_create has a lot of arguments now. Add a
structure for the options to make it more clear what is what.
This is in preparation for adding bare-integer arguments which are ripe
for confusion when passing positional arguments.
Signed-off-by: Daniel Stone <daniels@collabora.com>
gl_rendererer's output_create has a lot of arguments now. Add a
structure for the options to make it more clear what is what.
This is in preparation for adding bare-integer arguments which are ripe
for confusion when passing positional arguments.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The renderer buffer size is usually the same size as the current mode,
so we were taking the dimensions from the currently-set mode. However,
using current_mode is quite confusing in places when it comes to scale,
and it also hampers our ability to do mode switches, as well as to
introduce a future option which will let the renderer use a smaller
buffer than the output and display scaled.
Simply take the dimensions of the renderer's output buffer from the
buffer itself.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This condition inside drm_output_render() checks if we can reuse the
existing renderer buffer for the primary plane; this occurs in
mixed-mode composition where a client buffer promoted to a plane has
changed, but the primary plane is unchanged.
We accomplish this by checking if there is no damage on the
primary/renderer plane, and then if there is already a renderer buffer
active on the primary plane: in that case, we can reuse the buffer we
already have.
There was a further condition checking if the width and height were
identical. This was designed to prevent against issues on mode changes.
However, runtime mode changes are already quite broken, and a mode
change will also cause damage on the full plane. We can simply remove
this condition.
Signed-off-by: Daniel Stone <daniels@collabora.com>
In order to start the repaint loop, the Wayland backend tries to damage
the full SHM buffer, but doesn't actually damage the full area if we
have a frame.
Store the buffer's width and height alongside the buffer itself, so we
can damage the full area when required.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When weston-desktop-shell uses a solid color for the wallpaper, it creates a
1x1 buffer and uses wp_viewport to scale that up to fullscreen. It's a very
nice memory saving optimization.
If you also have output scale != buffer scale, it means pixman-renderer chooses
bilinear filter. Arguably pixman-renderer should choose bilinear filter also
when wp_viewport implies scaling, but it does not. As w-d-s always sets buffer
scale from output scale, triggering the bilinear filter needs some effort.
What happens when you sample with bilinear filter from a 1x1 buffer, stretching
it to cover a big area? Depends on the repeat mode. The default repeat mode is
NONE, which means that samples outside of the buffer come out as (0,0,0,0).
Bilinear filter makes it so that every sampling point on the 1x1 buffer except
the very center is actually a mixture of the pixel value and (0,0,0,0). The
resulting color is no longer opaque, but the renderer and damage tracking
assume it is. This leads to the issue 373.
Fix half of the issue by using repeat mode PAD which corresponds to OpenGL
CLAMP_TO_EDGE. GL-renderer already uses CLAMP_TO_EDGE always.
This is only a half-fix, because composite_clipped() cannot actually be fixed.
It relies on repeat mode NONE to work. It would need a whole different approach
to rendering potentially non-axis-aligned regions exactly like GL-renderer.
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/373
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The KMS 'panel orientation' property allows the driver to statically
declare a fixed rotation of an output device. Now that weston_head has a
transform member, plumb the KMS property through to weston_head so the
compositor can make a smarter choice out of the box.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
[daniels: Extracted from one of Lucas's patches]
Signed-off-by: Daniel Stone <daniels@collabora.com>
Like physical size, subpixel arrangement, etc, transform advises of a
physical transform of a head, if present.
This commit adds the transform member and setter to weston_head, however
it is currently unused.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
[daniels: Extracted from one of Lucas's patches.]
Signed-off-by: Daniel Stone <daniels@collabora.com>
b_lundef was overriden for the RDP backend since it triggered linking
errors due to functions that were defined in a missing dependency. This
issue was fixed, so the override is removed. The global project's
linker parameters are now applied to the RDP backend.
Signed-off-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
The RDP backend uses functions defined by the Windows Portable Runtime
library (WinPR). The library's code is contained within FreeRDP
repository, but it is packaged as its own library (seperate pkg-config
file).
WinPR is added as a dependency to the RDP backend. The version 2.0 is
choosen as the version to on since the backend depends on FreeRDP 2.0.
Signed-off-by: Guillaume Champagne <champagne.guillaume.c@gmail.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>
Clarifies which direction the transformation happens. All exported function
need documentation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is to put more of the EGL client extension handling in the same
place. This also adds a boolean to check if EGL_EXT_platform_base is
supported, similar to other extensions we check.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
EGL client extensions are not tied to the EGLDisplay we create, and have
an effect on how we create the EGLDisplay. Since we're using this to
look for EGL_EXT_platform_base, it makes more sense for this to be near
the start of the GL renderer initialization.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
Make stream_destroy() use weston_log_subscriber_release().
This avoids code duplication and allow us to destroy
weston_log_subscriber_get_only_subscription(), since it's
being used only in this case and it's internal.
Calls for weson_log_subscriber_release() leads to
weston_log_debug_wayland_to_destroy(), which should not
send an error event when the stream has already been closed.
Also, stream_destroy() shouldn't lead to an event error, as
it is a wl_resource destroy handler. So close the stream before
calling weston_log_subscriber_release() in stream_destroy()
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Both weston_log_scope_destroy() and weston_log_subscriber_release()
have calls for destroy_subscription(). We can move this call to
weston_log_subscription_destroy() without losing anything and
avoiding repetition.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The subscription is directly related to both the log scope and
the subscriber. It makes no sense to destroy one of them and
keep the subscriptions living.
We only had code to destroy subscription with
the destruction of log scopes. Add code to destroy
subscriptions with destruction of subscribers.
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>
weston_log_subscriber has a member named destroy. There are
other structs (weston_output, for instance) that have this
member, and by convention it is a pointer to a function
that destroys the struct.
In weston_log_subscriber it is being used to destroy
subscriptions of the debug protocol, and not the subscriber,
so this name is misleading. Rename it to destroy_subscription.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
weston_primary_flight_recorder_ring_buffer needs to be cleared on destruction
of the subscriber it was assigned from so that a compositor and be re-executed
in-process (static variables do not get re-initialized automatically).
This will be used by the test harness when it will execute wet_main() multiple
times in the same process. Otherwise it would hit the assert in
weston_log_subscriber_create_flight_rec().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If gl-renderer fails its initialisation, we return to compositor
teardown, which will try to free the renderer if ec->renderer was set.
This is unfortunate when we've already torn it down whilst failing
gl-renderer init, so just clear the renderer member so we don't try to
tear down twice.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Emil Velikov <emil.velikov@collabora.com>
When using weston-launch launcher deactivating the VT is sometimes
racy and leads to Weston still being displayed. The launcher-direct.c
backend makes sure that the session signal is emitted first, then DRM
master is dropped and finally the VT switch is acknowledged via
VT_RELDISP.
However, in the weston-launch case the session signal is emitted via
a socket message to the weston process, which might get handled a bit
later. This leads to dropping DRM master and acknowledging the VT
switch prematurely.
Add a socket message which allows weston to notify weston-launch that
the signal has been emitted and deactivating can be proceeded.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
On weston-launch exit we see errors such as:
failed to restore keyboard mode: Invalid argument
failed to set KD_TEXT mode on tty: Invalid argument
This has been resolved by making sure the tty file descriptor
does not get closed. However, the ioctrl's KDSKBMODE/KDSETMODE
and VT_SETMODE still fail with -EIO:
failed to restore keyboard mode: Input/output error
failed to set KD_TEXT mode on tty: Input/output error
It turns out the reason for this lies in some very particular
behavior of the kernel, the separation of weston-launch/weston
and the fact that we restore the tty only after the weston
process quits: When the controlling process for a TTY exits,
all open file descriptors for that TTY are put in a hung-up
state! For more details see this systemd-logind issue:
https://github.com/systemd/systemd/issues/989
We can work around by reopening the particular TTY. This allows
to properly restore the TTY settings such that a successive VT
switch will show text terminals fine again.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Since weston-launch is a setuid-root program we should be extra careful:
Check for a potential string trunction. Move the check in a separate
function and return with error in case trunction has happened.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Currently weston-launch does not activate the VT when opening the
terminal directly (e.g. using --tty=/dev/tty7). Weston takes full
control over the terminal by switching it to graphical mode etc.
However, the old VT stays active as can be seen when looking at
sysfs:
# cat /sys/class/tty/tty0/active
tty1
Always switch to the new VT to make sure the correct VT is active.
This aligns with how TTY setup is implemented in launcher-direct.c.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Add newline character at the end of the error message to make sure we
get a new line after this error has been printed.
Fixes: a1450a8a71 ("make error() portable")
Signed-off-by: Stefan Agner <stefan@agner.ch>
In case an user is given but no tty, the code opens tty0 to allocate a
new tty. With that ttynr is known.
In case a tty name is given the user must be given too. In this case
we later recover the ttynr by using stat on the file tty file descriptor
which allows as to find the ttynr by looking at the devices minor number.
However, the third case, when no user and no tty name is given, we do
not get the ttynr.
This hasn't been a problem in practise since ttynr has not been used.
However, it makes sense to get the ttynr always for consistency. Also
upcomming fixes will start to make use of ttynr.
Fixes: 636156d5f6 ("weston-launch: Don't start new session unless -u is given")
Signed-off-by: Stefan Agner <stefan@agner.ch>
The tty file descriptor is used in signal handling (when switching
VT via SIGUSR1/SIGUSR2 for the VT_RELDISP ioctrl) and in quit() when
weston-launch exits for the KDSKBMUTE/KDSKBMODE/KDSETMODE/VT_SETMODE
ioctrls.
This fixes VT switching when using weston-launch from a non-VT shell
(e.g. ssh or from within a container).
Signed-off-by: Stefan Agner <stefan@agner.ch>
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>
The function weston_log_ctx_compositor_destroy(), which destroys struct
weston_log_context, takes weston_compositor as argument. We may have a
weston_log_context unlinked from a weston_compositor and currently there
is no way to destroy it.
Add function weston_log_ctx_destroy(), what makes the destruction of
weston_log_context independent of weston_compositor.
With this change, one could destroy a weston_compositor and keep the
related weston_log_context (since now weston_log_context can be destroyed
without the need of a weston_compositor). But if weston_compositor gets
destroyed it's also necessary to destroy weston_log_context::global,
as the debug protocol depends on the compositor. So a listener has been
added to the destroy signal of weston_compositor.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Since weston_log_ctx_compositor_create() does not have any relation
with weston_compositor, rename it to weston_log_ctx_create().
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The function weston_log_ctx_compositor_setup() is being called only inside
weston_compositor_create() and it is so tiny that the code gets easier to
follow if it gets folded in weston_compositor_create().
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Commit "weston-log: add function to avoid direct
access to compositor members in non-core code" added the
function weston_compositor_add_log_scope mainly to allow
libweston users to avoid direct accessing core structs, as
weston_compositor.
Replace weston_log_context_add_log_scope usage by
weston_compositor_add_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Commit "weston-log: add function to avoid direct
access to compositor members in non-core code" added the
function weston_compositor_add_log_scope mainly to allow
libweston users to avoid direct accessing core structs, as
weston_compositor.
Replace weston_log_context_add_log_scope usage by
weston_compositor_add_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Commit "weston-log: add function to avoid direct
access to compositor members in non-core code" added the
function weston_compositor_add_log_scope mainly to allow
libweston users to avoid direct accessing core structs, as
weston_compositor.
Replace weston_log_context_add_log_scope usage by
weston_compositor_add_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
If we use the function weston_log_context_add_log_scope()
in non-core code, it's necessary to access
weston_compositor::weston_log_ctx.
This is not ideal, since the goal is to make core structs
(weston_compositor, weston_surface, weston_output, etc)
opaque.
Add function weston_compositor_add_log_scope(), so non-core
users are able to pass weston_compositor as argument instead
of weston_compositor::weston_log_ctx.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
There's a function named weston_compositor_add_log_scope()
but it doesn't take a struct weston_compositor argument.
Rename it to weston_log_ctx_add_log_scope(), as
the log_scope is being added to a log_context.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Fixes missing prototypes compilation warnings emitted when a function
is defined before its prototype is declared.
These warnings were introduced over time since the switch to meson
because the -Wmissing-protoypes was not included in the compilation
arguments.
Signed-off-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
weston_environment_get_fd was declared in weston-launch and implemented
in compositor.c. Since the function is not used elsewhere in the code,
it is replaced by a static function in launcher-weston-launch.c
Signed-off-by: Guillaume Champagne <champagne.guillaume.c@gmail.com>
Just a couple of places which shouldn't be possible, so initialized and
added assertions to make sure.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
