weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2020-09-11T20:32:11Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/253Screen share not working if pixman does not provide pixman_blt2020-09-11T20:32:11ZStefan AgnerScreen share not working if pixman does not provide pixman_bltIn case pixman has been compiled without any accelerated blitting function, `pixman_blt` will return false. In this case copying the pixel data will not occurs and the shared screen remains black.
I noticed this on Weston 6.0.0 compiled...In case pixman has been compiled without any accelerated blitting function, `pixman_blt` will return false. In this case copying the pixel data will not occurs and the shared screen remains black.
I noticed this on Weston 6.0.0 compiled for Arm aarch64 with latest pixman (0.38.4). Currently pixman does not provide a implementation for pixman_blt when compiling for aarch64. In that case the shared screen (via RDP in my case) remained black on the remote end.
According to @siamashka a user of `pixman_blt` should expect that `pixman_blt` returns false and implement a fallback mechanism in this case. See also this mailing list discussion:
https://lists.freedesktop.org/archives/pixman/2013-December/003135.html7.0.0Stefan AgnerStefan Agnerhttps://gitlab.freedesktop.org/wayland/weston/-/issues/739Test-failures on big-endian architectures2023-04-17T14:17:43Zmatoro1Test-failures on big-endian architecturesHi, I am observing a specific subset of tests which fail with assertion failures on all big-endian architectures. There are additional failures on some specific architectures, but all big-endian arches have this subset of failures in co...Hi, I am observing a specific subset of tests which fail with assertion failures on all big-endian architectures. There are additional failures on some specific architectures, but all big-endian arches have this subset of failures in common:
```
Summary of Failures:
5/41 alpha-blending ERROR 3.10s killed by signal 6 SIGABRT
6/41 buffer-transforms ERROR 3.79s killed by signal 6 SIGABRT
13/41 output-transforms ERROR 0.19s killed by signal 6 SIGABRT
15/41 internal-screenshot ERROR 0.57s killed by signal 6 SIGABRT
16/41 output-damage ERROR 0.37s killed by signal 6 SIGABRT
18/41 pointer-shot ERROR 0.28s killed by signal 6 SIGABRT
19/41 single-pixel-buffer ERROR 0.21s killed by signal 6 SIGABRT
27/41 viewporter-shot ERROR 0.24s killed by signal 6 SIGABRT
32/41 yuv-buffer ERROR 0.59s killed by signal 6 SIGABRT
39/41 subsurface-shot ERROR 1.98s killed by signal 6 SIGABRT
40/41 color-icc-output ERROR 0.67s killed by signal 6 SIGABRT
Ok: 29
Expected Fail: 0
Fail: 11
Unexpected Pass: 0
Skipped: 1
Timeout: 0
```
I confirmed this on ppc64 BE and mips64 BE, both had identical failures, here is a sample log from the former: [testlog.txt](/uploads/ebdd9d34fb6fdf4a042b09a6fa409c72/testlog.txt)
This can be cross-referenced with Debian CI. Although note that Debian has 11.0.0 in experimental, and it is showing a segfault in the `xwayland` test that I do not see, so feel free to ignore that one.
s390x: https://buildd.debian.org/status/fetch.php?pkg=weston&arch=s390x&ver=11.0.0-2&stamp=1674156095&raw=1
```
Summary of Failures:
2/45 alpha-blending ERROR 0.05s killed by signal 6 SIGABRT
4/45 buffer-transforms ERROR 0.07s killed by signal 6 SIGABRT
10/45 internal-screenshot ERROR 0.07s killed by signal 6 SIGABRT
14/45 output-damage ERROR 0.09s killed by signal 6 SIGABRT
15/45 output-transforms ERROR 0.06s killed by signal 6 SIGABRT
18/45 pointer-shot ERROR 0.06s killed by signal 6 SIGABRT
23/45 single-pixel-buffer ERROR 0.06s killed by signal 6 SIGABRT
24/45 subsurface-shot ERROR 0.35s killed by signal 6 SIGABRT
30/45 viewporter-shot ERROR 0.06s killed by signal 6 SIGABRT
31/45 yuv-buffer ERROR 0.18s killed by signal 6 SIGABRT
35/45 color-icc-output ERROR 0.36s killed by signal 6 SIGABRT
38/45 xwayland ERROR 0.02s killed by signal 11 SIGSEGV
Ok: 32
Expected Fail: 0
Fail: 12
Unexpected Pass: 0
Skipped: 1
Timeout: 0
```
hppa: https://buildd.debian.org/status/fetch.php?pkg=weston&arch=hppa&ver=11.0.0-2&stamp=1674158398&raw=1
```
Summary of Failures:
2/45 alpha-blending ERROR 0.70s killed by signal 6 SIGABRT
6/45 buffer-transforms ERROR 1.36s killed by signal 6 SIGABRT
11/45 internal-screenshot ERROR 1.71s killed by signal 6 SIGABRT
14/45 output-transforms ERROR 0.82s killed by signal 6 SIGABRT
17/45 output-damage ERROR 1.67s killed by signal 6 SIGABRT
21/45 pointer-shot ERROR 1.91s killed by signal 6 SIGABRT
23/45 single-pixel-buffer ERROR 1.75s killed by signal 6 SIGABRT
28/45 viewporter-shot ERROR 1.38s killed by signal 6 SIGABRT
29/45 subsurface-shot ERROR 4.85s killed by signal 6 SIGABRT
35/45 yuv-buffer ERROR 8.95s killed by signal 6 SIGABRT
36/45 color-icc-output ERROR 7.72s killed by signal 6 SIGABRT
38/45 xwayland ERROR 0.90s killed by signal 11 SIGSEGV
Ok: 32
Expected Fail: 0
Fail: 12
Unexpected Pass: 0
Skipped: 1
Timeout: 0
```
powerpc: https://buildd.debian.org/status/fetch.php?pkg=weston&arch=powerpc&ver=11.0.0-2&stamp=1674157443&raw=1
```
Summary of Failures:
5/45 alpha-blending ERROR 0.06s killed by signal 6 SIGABRT
6/45 buffer-transforms ERROR 0.07s killed by signal 6 SIGABRT
10/45 internal-screenshot ERROR 0.20s killed by signal 6 SIGABRT
13/45 output-damage ERROR 0.20s killed by signal 6 SIGABRT
14/45 output-transforms ERROR 0.19s killed by signal 6 SIGABRT
16/45 pointer-shot ERROR 0.18s killed by signal 6 SIGABRT
19/45 single-pixel-buffer ERROR 0.18s killed by signal 6 SIGABRT
25/45 viewporter-shot ERROR 0.14s killed by signal 6 SIGABRT
29/45 xwayland ERROR 0.08s killed by signal 11 SIGSEGV
34/45 yuv-buffer ERROR 0.17s killed by signal 6 SIGABRT
41/45 subsurface-shot ERROR 0.37s killed by signal 6 SIGABRT
43/45 color-icc-output ERROR 0.57s killed by signal 6 SIGABRT
Ok: 17
Expected Fail: 0
Fail: 12
Unexpected Pass: 0
Skipped: 16
Timeout: 0
```
sparc64: https://buildd.debian.org/status/fetch.php?pkg=weston&arch=sparc64&ver=11.0.0-2&stamp=1674157483&raw=1
```
Summary of Failures:
4/45 alpha-blending ERROR 0.10s killed by signal 6 SIGABRT
5/45 buffer-transforms ERROR 0.11s killed by signal 6 SIGABRT
7/45 color-manager ERROR 0.30s killed by signal 10 SIGBUS
11/45 internal-screenshot ERROR 0.50s killed by signal 6 SIGABRT
14/45 output-damage ERROR 0.46s killed by signal 6 SIGABRT
15/45 output-transforms ERROR 0.45s killed by signal 6 SIGABRT
17/45 pointer-shot ERROR 0.42s killed by signal 6 SIGABRT
20/45 single-pixel-buffer ERROR 0.39s killed by signal 6 SIGABRT
26/45 viewporter-shot ERROR 0.29s killed by signal 6 SIGABRT
30/45 xwayland ERROR 0.20s killed by signal 11 SIGSEGV
34/45 color-metadata-parsing ERROR 0.25s killed by signal 10 SIGBUS
35/45 yuv-buffer ERROR 0.37s killed by signal 10 SIGBUS
41/45 subsurface-shot ERROR 0.50s killed by signal 6 SIGABRT
42/45 color-icc-output ERROR 0.31s killed by signal 10 SIGBUS
Ok: 13
Expected Fail: 0
Fail: 14
Unexpected Pass: 0
Skipped: 18
Timeout: 0
```
As you can see we have a specific subset of 11 tests that fail on all big-endian platforms (none of these tests have assertion failures on LE platforms, including ppc64le where all tests pass for me). sparc has additional issues (the SIGBUS tests) due to its strict alignment requirements, but is otherwise identical to all other BE platforms.
Is there any way these assertion failures could be looked at for users of BE platforms? Thanks!https://gitlab.freedesktop.org/wayland/weston/-/issues/734Test ORIGIN_BOTTOM_LEFT buffer composition2023-04-05T12:27:24ZPekka Paalanenppaalanen@gmail.comTest ORIGIN_BOTTOM_LEFT buffer compositionI don't think we have any test in the test suite that would reliably exercise `ORIGIN_BOTTOM_LEFT` buffers. We should have one that applies to both GL and Pixman renderers.
Only dmabuf buffers could end up with `ORIGIN_BOTTOM_LEFT` via ...I don't think we have any test in the test suite that would reliably exercise `ORIGIN_BOTTOM_LEFT` buffers. We should have one that applies to both GL and Pixman renderers.
Only dmabuf buffers could end up with `ORIGIN_BOTTOM_LEFT` via `ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT`, and people have been keen on deleting any use of that flag. Only `simple-dmabuf-v4l` might use it if the V4L2 device indicates so. But dmabuf does not apply with Pixman renderer.
With `wl_shm`, we have no protocol to indicate bottom-left origin, so a test will need to quirk that somehow.
Pixman-renderer never even checks `buffer_origin`, but it has not needed to, because it cannot get bottom-left origin buffers.
Neither does DRM-backend check `buffer_origin` when driving KMS, and theoretically that is a reachable bug.
GL-renderer has code to handle `buffer_origin`.https://gitlab.freedesktop.org/wayland/weston/-/issues/713Use `const struct pixel_format_info *` instead of plain DRM or Pixman format ...2023-01-27T09:08:53ZPekka Paalanenppaalanen@gmail.comUse `const struct pixel_format_info *` instead of plain DRM or Pixman format codesCurrently we have:
```c
struct pixman_renderer_output_options {
/** Composite into a shadow buffer, copying to the hardware buffer */
bool use_shadow;
/** Initial framebuffer size */
struct weston_size fb_size;
/** Initial DRM pixel...Currently we have:
```c
struct pixman_renderer_output_options {
/** Composite into a shadow buffer, copying to the hardware buffer */
bool use_shadow;
/** Initial framebuffer size */
struct weston_size fb_size;
/** Initial DRM pixel format */
uint32_t drm_format;
};
```
The `uint32_t drm_format` field should be changed into `const struct pixel_format_info *fb_pfmt`. DRM formats are not native to Pixman renderer.
I am trying to standardize everything in the compositor to use `const struct pixel_format_info *` as much as possible, because it helps debugging (easy to get the name of the format), it ensures that we actually have a pixel format info for any format we happen use, and it is API-agnostic in that it can provide DRM, Pixman, or OpenGL format codes as needed.
Likewise `weston_output_update_capture_info()` should be reverted to take `const struct pixel_format_info *`.
There is now a problem in the `struct pixman_renderer_interface`: a backend needs to pass a DRM format in `pixman_renderer_output_options` which gets used *only* for `weston_output_update_capture_info()`. The API to actually create pixman `weston_renderbuffers` takes a `pixman_format_code_t` instead. There is no connection between these two while they are still required to match.
The `weston_renderbuffer` APIs should take `const struct pixel_format_info *` as well.
Maybe changing pixel formats needs to be forbidden:
- have the initial pixel format in output-create-options
- allocate renderbuffers for a specific output which determines the size and format:
- `create_image_from_ptr()` asserts that the given size and format matches the recorded size and format
- `create_image()` has no size and format arguments at all
Changing pixel formats is so uncommon that one might as well just tear down the whole renderer-output and create a new one.
There already is the assumption that all renderbuffers allocated for a certain output will be used with that output only, because of the new damage tracking that replaced the extra-hw-damage. I think it's a good direction, it just needs to be taken further.
This way the capture-info management will fit the architecture well rather than being something you need to remember to update on the side. That's what the resize API was created for.
How would that sound?
cc @daniels @pH5
Btw. `pixman_renderer_interface::create_image_no_clear` could be called just `create_image`. The "no clear" has no meaning when there is no existing pointer being passed in. The implementation just uses `pixman_image_create_bits_no_clear()` to avoid memsetting the memory to zero. Alternatively, `pixman_renderer_interface::create_image_no_clear` could be simply deleted if passing a NULL pointer to `create_image_from_ptr` does the equivalent. But then all callers need to pass in correct size and format.https://gitlab.freedesktop.org/wayland/weston/-/issues/685Use matrix analysis for filtering decisions in the pixman renderer2023-01-11T23:28:30ZDerek ForemanUse matrix analysis for filtering decisions in the pixman renderer!1015 intends to provide this for the gl renderer, but ignore the similar code paths in the pixman renderer. This requires a little more effort because `repaint_region()` in `pixman-renderer.c` isn't passed the paint node.
See https://g...!1015 intends to provide this for the gl renderer, but ignore the similar code paths in the pixman renderer. This requires a little more effort because `repaint_region()` in `pixman-renderer.c` isn't passed the paint node.
See https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1015#note_1617225 for a good description of what this entails.https://gitlab.freedesktop.org/wayland/weston/-/issues/613pixman-render: Keeping a weston_buffer ref alive with the underlying shm buff...2022-04-29T09:15:21ZMarius Vladpixman-render: Keeping a weston_buffer ref alive with the underlying shm buffer gone (on fade out views)With patch "weston_buffer: Hold lifetime for resource/backend usage" (7e90433079e08aafd560810817e60c46485a4bd2) `weston_buffer_destroy_handler()` which now marks `buffer->shm_buffer = NULL`, causes a side-effect
in `repaint_region()`.
...With patch "weston_buffer: Hold lifetime for resource/backend usage" (7e90433079e08aafd560810817e60c46485a4bd2) `weston_buffer_destroy_handler()` which now marks `buffer->shm_buffer = NULL`, causes a side-effect
in `repaint_region()`.
As the reference is still alive, but with its shm_buffer long gone, it will obviously fail. It doesn't appear
to be sufficient to add an additional check when accessing the shm_buffer. As the shm_buffer is no longer
available, it would fail at the next composite_* function. So ignoring the output repaint altogether seem to help,
but wonder if this is really a correct fix.
Something like the following:
```
diff --git a/libweston/pixman-renderer.c b/libweston/pixman-renderer.c
index 636d9d91..b7f54ac0 100644
--- a/libweston/pixman-renderer.c
+++ b/libweston/pixman-renderer.c
@@ -335,6 +335,9 @@ repaint_region(struct weston_view *ev, struct weston_output *output,
pixman_image_t *mask_image;
pixman_color_t mask = { 0, };
+ if (ps->buffer_ref.buffer && !ps->buffer_ref.buffer->shm_buffer)
+ return;
+
```
Haven't observed this with `close-animation=none` which might reveal why the reference is still alive but its buffer gone.https://gitlab.freedesktop.org/wayland/weston/-/issues/504Views which cannot be painted by the renderer2021-06-07T13:25:37ZDaniel Stonedaniel@fooishbar.orgViews which cannot be painted by the rendererThe following discussion from !582 should be addressed:
- [ ] @daniels started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582#note_937979): (+8 comments)
> Hmmmm. My first thought was: every pain...The following discussion from !582 should be addressed:
- [ ] @daniels started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/582#note_937979): (+8 comments)
> Hmmmm. My first thought was: every paint node should have a valid transform ensured when adding it to the z-order list, so this should be an assert. But I guess this can fail for legitimate reasons in future when we have more complex CM, so it shouldn't be an assert. But in that case, shouldn't we paint some kind of solid colour rather than just punching through to potentially garbage? Same for gl-renderer.https://gitlab.freedesktop.org/wayland/weston/-/issues/373Client buffer scaling is broken with Pixman renderer2020-03-16T12:00:55ZDaniel Stonedaniel@fooishbar.orgClient buffer scaling is broken with Pixman rendererWhen displaying client surfaces whose scale factor does not match the native scale factor, Pixman renders everything (at least alpha-blended views ... ?) very badly. It seems like either view damage from moves is not properly processed, ...When displaying client surfaces whose scale factor does not match the native scale factor, Pixman renders everything (at least alpha-blended views ... ?) very badly. It seems like either view damage from moves is not properly processed, or blending is just outright broken.
The attached screenshot is the result of hacking `libweston/compositor.c` to always send `wl_output.scale(1)` to clients instead of the real scale factor, and starting the DRM backend with `scale == 2` for the outputs. The same effect could be achieved by ignoring the scale event in `clients/window.c`.
![wayland-screenshot-2020-03-09_15-53-50](/uploads/8ef45b6c2c4b5f82969b048760a84acc/wayland-screenshot-2020-03-09_15-53-50.png)
I suppose this means there are no tests for `surface->scale != output->scale` paths.https://gitlab.freedesktop.org/wayland/weston/-/issues/256Clean up use of frame_signal2019-11-28T13:12:48ZDaniel Stonedaniel@fooishbar.orgClean up use of frame_signalCurrently `frame_signal` is emitted from the renderers themselves, immediately after they repaint. I cannot see any reason why the signal should not just be emitted from the core `weston_output_repaint()` instead. Doing this would appear...Currently `frame_signal` is emitted from the renderers themselves, immediately after they repaint. I cannot see any reason why the signal should not just be emitted from the core `weston_output_repaint()` instead. Doing this would appear to have no effect on existing users.
The frame signal also passes the `weston_output` as its data to the listeners. All current users can easily get the output anyway: their listener pointer lies in an output-specific structure, with many already using `container_of` to get the output and ignoring the data. If we passed the repaint region as the data instead, this would mean we could eliminate the `output->previous_damage` member completely.
The DRM backend's VA-API recorder also hooks into the frame signal, presumably as it's been cargo-culted from the screenshooter. There's no real reason it needs to do this, when it could just have a direct callback from `drm_output_repaint()`. But this is more a matter of taste than the previous two, which I think are clearly good improvements.https://gitlab.freedesktop.org/wayland/weston/-/issues/254Screen share and screen shooter output somewhat scrambled when using pixman2019-06-16T17:23:19ZStefan AgnerScreen share and screen shooter output somewhat scrambled when using pixmanWhen using pixman with Wayland backend the output seems somewhat scrambled when using screen share (via RDP) and screen shooter.
![wayland-screenshot-2019-06-16_19-18-24](/uploads/c783533950e63f34842b22f8830855f6/wayland-screenshot-2019...When using pixman with Wayland backend the output seems somewhat scrambled when using screen share (via RDP) and screen shooter.
![wayland-screenshot-2019-06-16_19-18-24](/uploads/c783533950e63f34842b22f8830855f6/wayland-screenshot-2019-06-16_19-18-24.png)
![Screenshot_from_2019-06-16_18-25-01](/uploads/3fac4fbbc29720d8c70bf6a52bfbfa39/Screenshot_from_2019-06-16_18-25-01.png)
I first thought its only master which is affected, but it turned out that `--use-pixman` got only fixed after 6.0.0 release.https://gitlab.freedesktop.org/wayland/weston/-/issues/244libweston/DRM renderless (planes only) compositing mode2024-02-23T17:29:42ZPekka Paalanenppaalanen@gmail.comlibweston/DRM renderless (planes only) compositing modeThis is an idea suggestion and I have no personal interest in it for now. I just recalled some IRC discussions from months back.
Particularly on closed embedded systems (TVs, set-top-boxes, special video equipment, ...) the whole system...This is an idea suggestion and I have no personal interest in it for now. I just recalled some IRC discussions from months back.
Particularly on closed embedded systems (TVs, set-top-boxes, special video equipment, ...) the whole system from hardware to software may be designed so that all compositing needs should be satisfied by the display hardware, making renderers useless. That is, when things actually work as designed. It will allow to cut costs in hardware e.g. by choosing a very cheap and slow GPU, while still being able to push full framerate 4K whatever video through by using dedicated display hardware features.
To help people develop and push such systems in the wild, libweston/DRM could do a few things:
- Whenever libweston falls back to the renderer at all, make it print the reasons why it did so. This should likely just re-use the framework developed for solving #144.
- Make `zwp_linux_dmabuf` implementation (the check hook) verify that the created buffer at least has some chances of being scanout-able. Importing as a DRM FB would be the most reliable check, but if that is somehow not acceptable, then the very least the dmabuf format and modifier should be checked against the KMS supported formats and `IN_MODIFIERS`. If there it seems impossible to scan out the dmabuf directly, reject it, so the client can try something else. This might be crucial since normally client side doesn't really care and relies on luck for scanout-ability.
- The GL-renderer tint mode could be activated to show which parts are render-composited on screen.
- Make Pixman-renderer not reject dmabufs when renderless compositing mode is set. This will allow the system designer to avoid OpenGL completely. All dmabufs should be CPU-mmappable nowadays, so Pixman-renderer could support them instead of just not rendering.Marius VladMarius Vladhttps://gitlab.freedesktop.org/wayland/weston/-/issues/220Add global region -> output region helper to libweston2020-06-03T11:45:11ZDaniel Stonedaniel@fooishbar.orgAdd global region -> output region helper to libwestonThe following discussion from !17 should be addressed:
- [ ] @daniels started a [discussion](https://gitlab.freedesktop.org/wayland/weston/merge_requests/17#note_30357): (+1 comment)
> @pq @sardemff7 Do these branches look right? ...The following discussion from !17 should be addressed:
- [ ] @daniels started a [discussion](https://gitlab.freedesktop.org/wayland/weston/merge_requests/17#note_30357): (+1 comment)
> @pq @sardemff7 Do these branches look right? Does `output->base.matrix` contain the complete transform when zoom is active?https://gitlab.freedesktop.org/wayland/weston/-/issues/166Convert renderer debug bindings into debug scopes2018-11-30T15:14:46ZPekka Paalanenppaalanen@gmail.comConvert renderer debug bindings into debug scopesWeston has some debug key bindings in the renderers that toggle certain rendering debugging modes, including the triangle fan to see the primitive edges and the green tint to identify composite bypass. Activating these via the keyboard c...Weston has some debug key bindings in the renderers that toggle certain rendering debugging modes, including the triangle fan to see the primitive edges and the green tint to identify composite bypass. Activating these via the keyboard combination is slightly awkward.
We could add a debug scope for each toggle. As long as the debug scope has subscribers, keep the debug function on. That way one could use `weston-debug` to enable these modes, and quitting it will restore to normal.Marius VladMarius Vladhttps://gitlab.freedesktop.org/wayland/weston/-/issues/148Make unhandled buffer type a disconnecting error2018-11-02T14:36:12ZPekka Paalanenppaalanen@gmail.comMake unhandled buffer type a disconnecting errorCurrently `gl_renderer_attach()` simply logs a message `unhandled buffer type!` when it cannot use the provided buffer in compositing. This leads to a silent failure where the window is not updated or does not appear.
Instead, send a fa...Currently `gl_renderer_attach()` simply logs a message `unhandled buffer type!` when it cannot use the provided buffer in compositing. This leads to a silent failure where the window is not updated or does not appear.
Instead, send a fatal protocol error to the client with an explanation. Do this also in pixman renderer.
Prompted by #141.https://gitlab.freedesktop.org/wayland/weston/-/issues/27Enable pixman-based rendering from config-file option2019-01-31T09:04:10ZThomas ZimmermannEnable pixman-based rendering from config-file optionPixman-based rendering can be enabled on the command-line using '--use-pixman'. An equivalent option should be available in the configure file (i.e., weston.ini).Pixman-based rendering can be enabled on the command-line using '--use-pixman'. An equivalent option should be available in the configure file (i.e., weston.ini).