Commits on Source (23)
-
Michael Tretter authored
In commit d8e09afc ("tests: Convert ivi-shell-app-test.c to use `weston_ini_setup`") the reference weston.ini for the ivi-shell was removed, because it is not required by the test anymore. The reference weston.ini still has value as an example for the ivi-shell and how the ivi-shell-user-interface has to be configured. Retrieving this information from the test case is not intuitive. Furthermore, the file is still referenced by the ivi-shell/README, and the configuration_data for generating the file was not fully removed. Bring back the reference weston.ini for the ivi-shell and, while at it, cleanup the configuration_data() to define only keys that are actually used in weston.ivi.in. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de>
-
Alexandros Frantzis authored
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>
-
Alexandros Frantzis authored
Store the pointer serial for events that provide one, so that it can be used by tests to send requests that require it (e.g., setting the cursor surface). Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@collabora.com>
-
Alexandros Frantzis authored
Add a regression test to verify that the cursor image is correctly updated when setting a cursor surface with an already committed buffer from a previous pointer entry, without recommitting a cursor buffer for the current entry. Signed-off-by:
Alexandros Frantzis <alexandros.frantzis@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>
-
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>
-
See: #467 (comment 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>
-
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>
-
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 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 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 new option allows loading the color-lcms plugin. Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com>
-
This is a trivial smoke test to ensure that the color-lcms plugin is loadable. Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
This reverts commit 36d699a1. 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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
This reverts commit 81ef6d0a. This also removes a bit from "tests: ensure color-lcms plugin loads". Use of the shadow buffer is determined automatically based on color transformations by the previous commit "gl-renderer: use shadow framebuffer automatically". Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com>
-
Pekka Paalanen authored
This is no longer used. This was originally added in b5265af6. Signed-off-by:
Pekka Paalanen <pekka.paalanen@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>
-
Reported by ASan. Direct leak of 1468 byte(s) in 48 object(s) allocated from: #0 0x7f20d7ae0330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x7f20d76894b7 in _IO_vasprintf /build/glibc-vjB4T1/glibc-2.28/libio/vasprintf.c:73 #2 0x7f20d7a66827 in __interceptor_vasprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6f827) #3 0x7f20d7a66f76 in asprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6ff76) #4 0x5598e3fbcdfc in buffer_transform ../../git/weston/tests/buffer-transforms-test.c:122 #5 0x5598e3fc9add in run_test ../../git/weston/tests/weston-test-runner.c:162 #6 0x5598e3fca17e in run_case ../../git/weston/tests/weston-test-runner.c:277 #7 0x5598e3fc9f24 in for_each_test_case ../../git/weston/tests/weston-test-runner.c:235 #8 0x5598e3fca406 in testsuite_run ../../git/weston/tests/weston-test-runner.c:311 #9 0x7f20d3523b6b in client_thread_routine ../../git/weston/tests/weston-test.c:479 #10 0x7f20d75e8fa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486 #11 0x7f20d770a4ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce) Direct leak of 978 byte(s) in 42 object(s) allocated from: #0 0x7f26fed07330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x7f26fe8b04b7 in _IO_vasprintf /build/glibc-vjB4T1/glibc-2.28/libio/vasprintf.c:73 #2 0x7f26fec8d827 in __interceptor_vasprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6f827) #3 0x7f26fec8df76 in asprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6ff76) #4 0x55989ba8c2bc in output_damage ../../git/weston/tests/output-damage-test.c:201 #5 0x55989ba8c0cb in wrapoutput_damage ../../git/weston/tests/output-damage-test.c:176 #6 0x55989ba99131 in run_test ../../git/weston/tests/weston-test-runner.c:162 #7 0x55989ba997d2 in run_case ../../git/weston/tests/weston-test-runner.c:277 #8 0x55989ba99578 in for_each_test_case ../../git/weston/tests/weston-test-runner.c:235 #9 0x55989ba99a5a in testsuite_run ../../git/weston/tests/weston-test-runner.c:311 #10 0x7f26fa57ab6b in client_thread_routine ../../git/weston/tests/weston-test.c:479 #11 0x7f26fe80ffa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486 #12 0x7f26fe9314ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce) Direct leak of 1696 byte(s) in 56 object(s) allocated from: #0 0x7f077107f330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x7f0770c284b7 in _IO_vasprintf /build/glibc-vjB4T1/glibc-2.28/libio/vasprintf.c:73 #2 0x7f0771005827 in __interceptor_vasprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6f827) #3 0x7f0771005f76 in asprintf (/lib/x86_64-linux-gnu/libasan.so.5+0x6ff76) #4 0x563e6ae36dfc in output_transform ../../git/weston/tests/output-transforms-test.c:122 #5 0x563e6ae43add in run_test ../../git/weston/tests/weston-test-runner.c:162 #6 0x563e6ae4417e in run_case ../../git/weston/tests/weston-test-runner.c:277 #7 0x563e6ae43f24 in for_each_test_case ../../git/weston/tests/weston-test-runner.c:235 #8 0x563e6ae44406 in testsuite_run ../../git/weston/tests/weston-test-runner.c:311 #9 0x7f076ca26b6b in client_thread_routine ../../git/weston/tests/weston-test.c:479 #10 0x7f0770b87fa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486 #11 0x7f0770ca94ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce) Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com>
-
Fixes all ASan reported leaks for this test. If frame_callback_wait_nofail() returns before the callback is handled, the callback is not destroyed automatically. This happens on a protocol error. This test intentionally triggers a protocol error. Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com>
Showing
- compositor/main.c 8 additions, 32 deletionscompositor/main.c
- include/libweston/libweston.h 10 additions, 6 deletionsinclude/libweston/libweston.h
- ivi-shell/meson.build 6 additions, 3 deletionsivi-shell/meson.build
- ivi-shell/weston.ini.in 98 additions, 0 deletionsivi-shell/weston.ini.in
- libweston/backend-drm/drm-internal.h 4 additions, 0 deletionslibweston/backend-drm/drm-internal.h
- libweston/backend-drm/drm.c 2 additions, 0 deletionslibweston/backend-drm/drm.c
- libweston/backend-drm/kms.c 2 additions, 2 deletionslibweston/backend-drm/kms.c
- libweston/backend-drm/state-propose.c 52 additions, 2 deletionslibweston/backend-drm/state-propose.c
- libweston/color-lcms/color-lcms.c 130 additions, 0 deletionslibweston/color-lcms/color-lcms.c
- libweston/color-lcms/color-lcms.h 44 additions, 0 deletionslibweston/color-lcms/color-lcms.h
- libweston/color-lcms/meson.build 29 additions, 0 deletionslibweston/color-lcms/meson.build
- libweston/color-noop.c 144 additions, 0 deletionslibweston/color-noop.c
- libweston/color.c 151 additions, 0 deletionslibweston/color.c
- libweston/color.h 242 additions, 0 deletionslibweston/color.h
- libweston/compositor.c 111 additions, 33 deletionslibweston/compositor.c
- libweston/input.c 1 addition, 1 deletionlibweston/input.c
- libweston/libweston-internal.h 4 additions, 1 deletionlibweston/libweston-internal.h
- libweston/meson.build 3 additions, 0 deletionslibweston/meson.build
- libweston/pixman-renderer.c 18 additions, 9 deletionslibweston/pixman-renderer.c
- libweston/renderer-gl/fragment.glsl 5 additions, 2 deletionslibweston/renderer-gl/fragment.glsl
ivi-shell/weston.ini.in
0 → 100644
libweston/color-lcms/color-lcms.c
0 → 100644
libweston/color-lcms/color-lcms.h
0 → 100644
libweston/color-lcms/meson.build
0 → 100644
libweston/color-noop.c
0 → 100644
libweston/color.c
0 → 100644
libweston/color.h
0 → 100644