weston merge requestshttps://gitlab.freedesktop.org/wayland/weston/-/merge_requests2023-12-06T11:39:36Zhttps://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1291Allow overlapping outputs2023-12-06T11:39:36ZDerek ForemanAllow overlapping outputsTrack damage on paint nodes and clean up any place where one output consumes any kind of global state that would prevent other outputs from rendering properly if there was an overlap.
As a bonus, we can also put views on planes when the...Track damage on paint nodes and clean up any place where one output consumes any kind of global state that would prevent other outputs from rendering properly if there was an overlap.
As a bonus, we can also put views on planes when they're displayed on multiple outputs at the same time too.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1020New screenshooter protocol and implementation2023-11-23T09:29:13ZPekka Paalanenppaalanen@gmail.comNew screenshooter protocol and implementationThis MR contains a completely new Weston-specific screenshooting protocol designed to support:
- color management testing by adding the "blending" source
- KMS testing by adding the "writeback" source
- output decorations testing by addi...This MR contains a completely new Weston-specific screenshooting protocol designed to support:
- color management testing by adding the "blending" source
- KMS testing by adding the "writeback" source
- output decorations testing by adding the "full_framebuffer" source
- proper buffer size negotiation instead of guessing from wl_output
- compositor chosen pixel format, primarily for "blending" source
- proper indication of screenshot failure
- dmabuf target buffers, linear only
The new protocol extension should be good enough to make a public Weston extension with stability guarantees, and install the XML file.
This is not a 100% implementation of the protocol. The notable omissions are:
- support for dmabuf, even though the protocol would allow using them
- "writeback" source support in DRM-backend (see !458)
- "blending" source support in GL-renderer (I don't expect that to be a problem, but not needed yet)
I do implement:
- The full logic for the new output capture (screenshooting) protocol.
- Pixman-renderer supports both "framebuffer" and "blending" sources.
- GL-renderer supports "framebuffer" and "full-framebuffer" blending sources.
- The test suite client helpers are converted to the new protocol.
- The manual screenshooting helper client is converted to the new protocol.
The new compositor side logic is very different from the old one. With the old approach you registered a `frame_signal` listener on an output, and when you get called, you are allowed to call `weston_renderer::read_pixels` to get something in some orientation and layout.
In the new approach, we keep a list of pending capture tasks with each output. When a renderer (or backend) processes an output repaint, it checks for capture tasks of the appropriate pixel source, and performs those capture tasks on its own, writing into the referenced `weston_buffer`. The capture source providers (renderers and backends) decide in advance what size and pixel format the destination buffers must have. This might save the provider from format conversion, pushing that out of the compositor. It also allows using higher precision pixel formats.
The old screenshooting protocol and its implementation are removed. However, `weston_screenshooter_shoot()` API is still retained as deprecated because it has external users. I expect to remove it in a Weston release after the next one.
Unfortunately, this work does not completely replace the output frame signal and `weston_renderer::read_pixels` API. Screen-share plugin and the wcap recorder still need `read_pixels`. I would guess that screen-share would be far better off if it could use dmabuf and/or pipewire in the future. The current `read_pixels` path looks quite inefficient. It is also a good question if anyone would miss the wcap recorder (ad hoc run-length encoded software compression). Therefore it might be possible to remove the `read_pixels` API in the far future.
----
The real reason why I embarked on this task right now is that in the CM&HDR work I want to test the input-to-output category of color transformations. The only place where that category is used is output decorations in the Weston wayland-backend. I need a way to take screenshots of those decorations to check their colors. Quickly hacking something up in the old screenshooting protocol did not seem like a good idea.
Closes: #449https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1264pixman-renderer: Add to_pixman_renderbuffer helper2023-06-09T09:17:23ZPhilipp Zabelphilipp.zabel@gmail.compixman-renderer: Add to_pixman_renderbuffer helperAdd a `to_pixman_renderbuffer()` helper to consolidate the `container_of(renderbuffer, ...)` macro calls.Add a `to_pixman_renderbuffer()` helper to consolidate the `container_of(renderbuffer, ...)` macro calls.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1133pixman-renderer: hold a reference for renderbuffers on the output renderbuffe...2023-03-04T08:20:23ZPhilipp Zabelphilipp.zabel@gmail.compixman-renderer: hold a reference for renderbuffers on the output renderbuffer listBased on !1124. Now that `struct weston_renderbuffer` is refcounted, hold a reference for renderbuffers on the `pixman_output_state::renderbuffer_list`. This allows backends to destroy the renderer output state and release renderbuff...Based on !1124. Now that `struct weston_renderbuffer` is refcounted, hold a reference for renderbuffers on the `pixman_output_state::renderbuffer_list`. This allows backends to destroy the renderer output state and release renderbuffer references in any order without running into an `assert()`.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1136wayland, x11: pixman renderer fixes2023-02-03T16:01:03ZPhilipp Zabelphilipp.zabel@gmail.comwayland, x11: pixman renderer fixesAdd back the ability to start the x11 backend with the pixman renderer and fix crashes in the wayland and x11 backends when using the pixman renderer, which were introduced by recent changes.Add back the ability to start the x11 backend with the pixman renderer and fix crashes in the wayland and x11 backends when using the pixman renderer, which were introduced by recent changes.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1130pixman-renderer: use pixel_format_info instead of pixman_format_code_t2023-01-28T13:01:52ZPhilipp Zabelphilipp.zabel@gmail.compixman-renderer: use pixel_format_info instead of pixman_format_code_tUse `struct pixel_format_info` pointers instead of `pixman_format_code_t` values at the API surface for output and image creation. See #713 for details.Use `struct pixel_format_info` pointers instead of `pixman_format_code_t` values at the API surface for output and image creation. See #713 for details.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1131pixman-renderer: rename create_image_no_clear to create_image2023-01-26T13:41:36ZPhilipp Zabelphilipp.zabel@gmail.compixman-renderer: rename create_image_no_clear to create_imageGiven that `pixman_image_create_bits_no_clear()` is asked to allocate the buffer on its own, the `_no_clear` part is not important. Drop it. Suggested in #713.Given that `pixman_image_create_bits_no_clear()` is asked to allocate the buffer on its own, the `_no_clear` part is not important. Drop it. Suggested in #713.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1112pixman-renderer: formalize renderbuffers a bit2023-01-24T08:02:52ZPhilipp Zabelphilipp.zabel@gmail.compixman-renderer: formalize renderbuffers a bitThis implements the first (pixman) part of @daniels' suggestions in https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1106#note_1718649.
Add a `struct pixman_renderer_interface` and hang it off of `struct weston_renderer`. ...This implements the first (pixman) part of @daniels' suggestions in https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1106#note_1718649.
Add a `struct pixman_renderer_interface` and hang it off of `struct weston_renderer`. For starters, this interface is used to access pixman renderer output state creation/removal and to create/destroy `struct weston_renderbuffer`s, which for now just wrap a pixman_image_t with an added damage region for damage tracking. The current renderbuffer is passed as a new parameter to `repaint_output` instead of setting it with a custom function.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1064Store renderer type in struct weston_renderer to make it visible for potentia...2022-12-08T09:47:31ZPhilipp Zabelphilipp.zabel@gmail.comStore renderer type in struct weston_renderer to make it visible for potential secondary backendsMove the renderer type from `headless_backend` into `weston_renderer`. This will later allow secondary backends to determine the renderer type chosen by the primary backend.
These patches are split out from !578 and changed to store the...Move the renderer type from `headless_backend` into `weston_renderer`. This will later allow secondary backends to determine the renderer type chosen by the primary backend.
These patches are split out from !578 and changed to store the renderer type in `weston_renderer` instead of `weston_compositor`, to avoid making the `enum weston_renderer_type` public API.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/976Add weston_renderer::resize_output() API2022-09-23T12:45:39ZPekka Paalanenppaalanen@gmail.comAdd weston_renderer::resize_output() APIThis MR depends on !971 and !975.
Previously renderers were not told when the output (framebuffer they
need to draw) size changed. Renderers just pulled that information out
from `weston_output::current_mode` when they happened to need ...This MR depends on !971 and !975.
Previously renderers were not told when the output (framebuffer they
need to draw) size changed. Renderers just pulled that information out
from `weston_output::current_mode` when they happened to need it. This
makes some things awkward, like resizing the shadow or intermediate
buffers. In fact, Pixman-renderer does not even support resizing its
shadow buffer, nor does GL-renderer. DRM-backend has to destroy and
re-create the renderer output state anyway, but rdp, x11 and wayland
backends would be natural users of resizing API.
This MR adds the renderer render-target resizing API, making renderers explicitly aware of when the target size changes.
Since GL-renderer is needed to blit output decorations (used by wayland-backend alone, when an output window is floating), it is not enough to communicate only the framebuffer size but also the position and size of the composited area (excluding decorations).
Communicating both the fb size and area explicitly allows renderers to track these, which will be useful with a future screenshooting protocol designed for the Weston test suite. This will also allow to stop renderers from looking into `weston_output::current_mode` which is done in a follow-up MR for GL-renderer (!977), and here already for pixman-renderer.
Finally x11-backend uses the new resizing API to avoid destroying and re-creating the renderer output state, and with GL-renderer it means it does not need to destroy and re-create the EGLSurface. RDP-backend is switched to the new API as well.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/978compositor/main.c: use pixman renderer by default when gl-renderer not enabled2022-08-05T10:29:18ZThomas Petazzonicompositor/main.c: use pixman renderer by default when gl-renderer not enabledWhen the gl-renderer is not enabled, weston fails to start, as it
doesn't automatically fallback to the pixman renderer, which is
always enabled.
This commit changes the drm-backend to set by default the --use-pixman
option to true when...When the gl-renderer is not enabled, weston fails to start, as it
doesn't automatically fallback to the pixman renderer, which is
always enabled.
This commit changes the drm-backend to set by default the --use-pixman
option to true when the gl-renderer is disabled (BUILD_DRM_GBM is not
defined).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/969Little clean-ups on pixman, headless, wayland, x112022-07-29T08:57:27ZPekka Paalanenppaalanen@gmail.comLittle clean-ups on pixman, headless, wayland, x11While implementing output resizing API for renderers so that I could implement the new screenshooting protocol so that I could take screenshots of output decorations so that I could exercise `CMLCMS_CATEGORY_INPUT_TO_OUTPUT` type of colo...While implementing output resizing API for renderers so that I could implement the new screenshooting protocol so that I could take screenshots of output decorations so that I could exercise `CMLCMS_CATEGORY_INPUT_TO_OUTPUT` type of color transformations in CI, I decided to pick the simple preparation patches I had so far and get them landed to reduce the number of patches to follow. Here they are, a set of various little bits that are hopefully trivial.Pekka Paalanenppaalanen@gmail.comPekka Paalanenppaalanen@gmail.comhttps://gitlab.freedesktop.org/wayland/weston/-/merge_requests/958libweston: Remove runtime render switching2022-07-26T13:43:59ZMarius Vladlibweston: Remove runtime render switchingIt is only enabled by a debug key binding and which currently is not tested
at all, so let's remove it. This also removes it from the man page.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>It is only enabled by a debug key binding and which currently is not tested
at all, so let's remove it. This also removes it from the man page.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>Marius VladMarius Vladhttps://gitlab.freedesktop.org/wayland/weston/-/merge_requests/767Make weston_buffer useful [weston_buffer epic part 2]2022-06-09T12:51:42ZDaniel Stonedaniel@fooishbar.orgMake weston_buffer useful [weston_buffer epic part 2]_this MR is based on !766 which converts the shells to use the solid-colour view work in shell-utils_
weston_buffer, as it stands, is pretty useless. Which makes it difficult to implement a program whose primary purpose in life is to di..._this MR is based on !766 which converts the shells to use the solid-colour view work in shell-utils_
weston_buffer, as it stands, is pretty useless. Which makes it difficult to implement a program whose primary purpose in life is to display buffers.
When a `wl_buffer` is first seen, a `weston_buffer` will be materialised to wrap it, and then passed to the renderer. The renderer is responsible for interpreting the content of the buffer, with the `weston_buffer` being completely unaware of its content. Furthermore, as soon as a buffer release event is sent to the client, the `weston_buffer` is discarded; its state only lives in renderer-private state from then on. This is the reason why the scene-graph debug can't tell you anything about SHM buffers when using the GL renderer: the renderer has copied the content and released the buffer, so we can no longer access it.
This series rectifies this by:
- adding additional information fields to `weston_buffer` (type, dimensions, format, etc): the core fills these in for SHM and dmabuf buffers, with the GL renderer being called on if we have an opaque EGL buffer, i.e. from the private interface provided by `EGL_WL_bind_wayland_display`
- extending the `weston_buffer` lifetime to its last reference: buffer references are split into content references ('don't release the buffer back to the user as I may still source from it'), and object references ('I don't need the content, but I do need the metadata')
- adding a solid-colour buffer type: instead of creating a surface and telling the renderer that the surface should be solid, we provide a new solid-colour buffer type which should be attached to the surface
These changes make it possible to remove a lot of special-case handling (surface with no buffer attached, lookaside state storage, surface which is magically solid), and centralises `weston_buffer` as the place where we get our pixels from, available to all in the core rather than only in renderer-private structures.
pixman-renderer has only seen light rework during this series, with the focus being on gl-renderer (culminating in !768).https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/848pixman-renderer: Unref the pixman image when wl_shm_buffer is gone2022-04-29T09:15:23ZMarius Vladpixman-renderer: Unref the pixman image when wl_shm_buffer is goneThis is fix attempt as prompted by the discussions in #613
PS: This just calls the appropriate destroy handler, as a particular use case. Haven't really looked into
making this similar to what we do with the dmabuf path, as suggested b...This is fix attempt as prompted by the discussions in #613
PS: This just calls the appropriate destroy handler, as a particular use case. Haven't really looked into
making this similar to what we do with the dmabuf path, as suggested by @pq in #613.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/664pixman-renderer: track Pixman formats in pixel format table2021-09-15T12:05:38ZM. Stoecklpixman-renderer: track Pixman formats in pixel format tableInstead of using a hardcoded `switch` to convert wl_shm formats to Pixman formats, add the Pixman format codes to the pixel format table. This makes it easier to add support for more shm formats when using the Pixman renderer. (Supportin...Instead of using a hardcoded `switch` to convert wl_shm formats to Pixman formats, add the Pixman format codes to the pixel format table. This makes it easier to add support for more shm formats when using the Pixman renderer. (Supporting 10-bit shm buffer formats is also a small step towards letting the pixman renderer generate 10-bit deep output.)
I tested this with a variant of the `weston-simple-shm` client that supports multiple shm buffer formats; see the branch at https://gitlab.freedesktop.org/mstoeckl/weston/-/commits/simple-shm-10 .https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/612Introduce weston_paint_node2021-05-30T15:03:49ZPekka Paalanenppaalanen@gmail.comIntroduce weston_paint_nodeSee #494 for the motivation of this MR.
Color management work in !582 needed to handle state keyed by surface-output pairs, and originally built a private mechanism for it. Paint nodes replace that private mechanism.
Paint nodes are a ...See #494 for the motivation of this MR.
Color management work in !582 needed to handle state keyed by surface-output pairs, and originally built a private mechanism for it. Paint nodes replace that private mechanism.
Paint nodes are a libweston core mechanism for having state keyed by surface-view-output triplets. Since a view always has exactly one surface associated, it is really about view-output pairs that are going through repaints, since a view must be created and mapped before a paint node materializes. Likewise, if any of the surface, view, or output disappears, the corresponding paint nodes are torn down.
In future, paint node will be useful for caching surface-output or view-output pair dependent data:
- damage regions (make overlapping outputs work)
- color transformations
- backend-specific bookkeeping (e.g. DRM KMS plane assigments)
- per-output repaint lists
- surface geometry transformed into output space
First, this MR introduces the paint node data structure and creates them as part of `weston_compositor_build_view_list()`.
Second, a per-output z-ordered paint node list is introduced. It is identical to the current `weston_compositor::view_list`, but in the future it shall not contain nodes for views that are not relevant for the output, e.g. off-screen or completely occluded.
Third, everything related to output repaint that iterated through `weston_compositor::view_list` are converted to use the z-ordered paint node list. Other uses of `view_list` are commented on why they cannot use paint node lists.
This should set the stage far enough that !582 can make use of paint nodes, and all the follow-up work in #494 has a good basis to build on.
This is probably as far as I can go with this without needing to write more tests.Pekka Paalanenppaalanen@gmail.comPekka Paalanenppaalanen@gmail.comhttps://gitlab.freedesktop.org/wayland/weston/-/merge_requests/399Preparation for render-scale: rework renderer init API, small fixes2020-03-20T15:27:28ZDaniel Stonedaniel@fooishbar.orgPreparation for render-scale: rework renderer init API, small fixesThis MR has a few commits from !394 which are working towards supporting render-scale, but can be cleanly separated.
Most of it is replacing the renderer display/surface creation function arguments with option structures, making it easi...This MR has a few commits from !394 which are working towards supporting render-scale, but can be cleanly separated.
Most of it is replacing the renderer display/surface creation function arguments with option structures, making it easier to extend in future and reducing confusion when we have lots of arguments.
The two more substantial drm-backend commits let us support getting differently-sized renderer buffers, without providing any facility to make the buffers actually be any smaller.
The other two commits are trivial and have no functional effect.https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/398Improve how Pixman-renderer handles buffer edges2020-03-16T12:03:05ZPekka Paalanenppaalanen@gmail.comImprove how Pixman-renderer handles buffer edgesThe long story starts here: https://gitlab.freedesktop.org/wayland/weston/issues/373#note_433470
From the commit message:
When weston-desktop-shell uses a solid color for the wallpaper, it creates a
1x1 buffer and uses wp_viewp...The long story starts here: https://gitlab.freedesktop.org/wayland/weston/issues/373#note_433470
From the commit message:
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.
This MR also contains a new test to ensure this case keeps on working, and some test helper refactoring to share more code.
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/373https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/204Drop pixman_blt calls2019-08-16T07:53:09ZStefan AgnerDrop pixman_blt callsCurrently we use `pixman_blt` to copy damaged region to shared outputs. Unfortunately `pixman_blt` is not guaranteed to be implemented and may return false. The caller is expected to implement a fallback in that case.
As discussed in ...Currently we use `pixman_blt` to copy damaged region to shared outputs. Unfortunately `pixman_blt` is not guaranteed to be implemented and may return false. The caller is expected to implement a fallback in that case.
As discussed in !195 we should rather drop pixman_blt instead of implementing a fallback for it. This merge requests replaced `pixman_blt` with `pixman_image_composite32`. It replaced !195.7.0.0