weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2023-04-17T14:17:43Zhttps://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/371Fix Cairo vs. wl_shm pixel formats on big-endian2023-04-12T09:00:00ZPekka Paalanenppaalanen@gmail.comFix Cairo vs. wl_shm pixel formats on big-endianBackground: wayland/wayland#11
Weston clients, that use Cairo for drawing, use the Cairo ARGB format. They ~~translate~~ map this format unconditionally to `WL_SHM_FORMAT_ARGB8888` which is correct on little-endian machines.
That is wr...Background: wayland/wayland#11
Weston clients, that use Cairo for drawing, use the Cairo ARGB format. They ~~translate~~ map this format unconditionally to `WL_SHM_FORMAT_ARGB8888` which is correct on little-endian machines.
That is wrong on big-endian machines. On big-endian machines, the Cairo ARGB format corresponds to `WL_SHM_FORMAT_BGRA8888` instead.
If Weston running on big-endian machine does not support `WL_SHM_FORMAT_BGRA8888`, then that support will need to be added.https://gitlab.freedesktop.org/wayland/weston/-/issues/334Improve weston_surface and weston_view identification for debugging2023-04-11T17:25:32ZPekka Paalanenppaalanen@gmail.comImprove weston_surface and weston_view identification for debuggingWhen debug prints need to identify a `weston_surface` or a `weston_view`, they print the raw pointer with `%p`. 64-bit pointers are hard to read for humans, and even harder to compare for correlating debug messages. These pointers should...When debug prints need to identify a `weston_surface` or a `weston_view`, they print the raw pointer with `%p`. 64-bit pointers are hard to read for humans, and even harder to compare for correlating debug messages. These pointers should be replaced with more human-friendly IDs.
Add a `uint32_t` counter in `struct weston_compositor` for generating such IDs, store them in `weston_surface` and `weston_view`, and use them in debug prints.
Pointer values may get re-used if the struct is freed and then another is allocated at the same address. OTOH, `uint32_t` may wrap around, but I suspect that is rare enough to not be a concern. If it proves to be a concern, we can easily upgrade to 64-bit, but then again the point of having it for human-readability is lost anyway.
Also better ideas for making it easier to identify surfaces and views are welcome. Note, that Wayland protocol object IDs are not unique in a `weston_compositor`, they are only unique for a client and they get aggressively re-used.
We could also consider a string naming scheme, e.g. `<client-id>:<item-id>:<protocol-object-id>` where client-id would be zero for items that were not associated with any client when allocated, item-id would come from a per-client counter, and protocol-object-id comes from the corresponding Wayland protocol object ID if there is any (e.g. `wl_surface` ID for `weston_surface` and `weston_view`). This would be different from the description string we already have for `weston_surface`. This could be stored as a string in the item.https://gitlab.freedesktop.org/wayland/weston/-/issues/735weston-terminal doesn't display correct Chinese characters with font alias2023-04-09T05:37:05ZYang Hongweston-terminal doesn't display correct Chinese characters with font aliasweston-terminal doesn't display Chinese characters with font alias (monospace), but other application like pango-view,foot could works.
I uses weston 11.0.1 in Archlinux with WSL2
```
[terminal]
font=monospace
font-size=14
```
![weston-...weston-terminal doesn't display Chinese characters with font alias (monospace), but other application like pango-view,foot could works.
I uses weston 11.0.1 in Archlinux with WSL2
```
[terminal]
font=monospace
font-size=14
```
![weston-terminal](/uploads/a6ea0285dccfc3dcb5af117d4a66cb01/weston-terminal.png)
![pango](/uploads/f1ba6f097847604a256006d64dcbb3a3/pango.png)
![wsl](/uploads/f9b387a58a24b787efe08ebc8e7b0b79/wsl.png)
![weston](/uploads/5247f514e478f38856c8f2a3e3feacb8/weston.png)https://gitlab.freedesktop.org/wayland/weston/-/issues/641[Request] Add other indicators other than clock / date & launcher on panel.2023-04-05T17:48:49Zlidg nulinux[Request] Add other indicators other than clock / date & launcher on panel.It will be great to see a feature when we can add something other than clock /date & launcher, for example, passing bash script output to panel. It's just a request and I'm happy to wait. Thanks.It will be great to see a feature when we can add something other than clock /date & launcher, for example, passing bash script output to panel. It's just a request and I'm happy to wait. 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/733lost panel on second/other output on desktop-shell2023-03-31T10:59:49ZMarius Vladlost panel on second/other output on desktop-shelld611ab24fd0004fb seems to have caused this and we no longer show the panel
on the second output with that one.
/cc @derekfd611ab24fd0004fb seems to have caused this and we no longer show the panel
on the second output with that one.
/cc @derekfhttps://gitlab.freedesktop.org/wayland/weston/-/issues/61weston windows don't regain focus after returning to tty2023-03-23T16:46:24ZBugzilla Migration Userweston windows don't regain focus after returning to tty## Submitted by Andrew Engelbrecht
Assigned to **Wayland bug list**
**[Link to original bug (#87752)](https://bugs.freedesktop.org/show_bug.cgi?id=87752)**
## Description
after switching from weston's tty to another, then returnin...## Submitted by Andrew Engelbrecht
Assigned to **Wayland bug list**
**[Link to original bug (#87752)](https://bugs.freedesktop.org/show_bug.cgi?id=87752)**
## Description
after switching from weston's tty to another, then returning to weston, the front window didn't regain keyboard focus. i noticed this with a weston terminal and a full screen window ("flare", under sdl2). clicking into the window brings back the focus.
it might be nice if the front-most window regains focus upon returning to that tty.https://gitlab.freedesktop.org/wayland/weston/-/issues/207Kick hotkeys on release, not press2023-03-02T08:24:49ZMaxim KhokhryakovKick hotkeys on release, not pressI use `keymap_options=grp:lctrl_lshift_toggle` for layout switching.
But Weston handle key bindings on press and not release, so I can't use ctrl-shift-tab in Firefox
or ctrl-shift-c for copy terminal output.
The Xorg has the same bug, ...I use `keymap_options=grp:lctrl_lshift_toggle` for layout switching.
But Weston handle key bindings on press and not release, so I can't use ctrl-shift-tab in Firefox
or ctrl-shift-c for copy terminal output.
The Xorg has the same bug, described here: https://bugzilla.freedesktop.org/show_bug.cgi?id=865https://gitlab.freedesktop.org/wayland/weston/-/issues/728GL-renderer forgets to destroy GL context2023-03-01T12:28:37ZPekka Paalanenppaalanen@gmail.comGL-renderer forgets to destroy GL contextGL-renderer forgets to destroy the GL context explicitly with `eglDestroyContext()`.
It does call `eglTerminate()` and `eglReleaseThread()`. According to EGL 1.5, this *should* release everything, and I don't recall seeing ASan complain...GL-renderer forgets to destroy the GL context explicitly with `eglDestroyContext()`.
It does call `eglTerminate()` and `eglReleaseThread()`. According to EGL 1.5, this *should* release everything, and I don't recall seeing ASan complaining here, so this is probably not a leak fix. That is probably why I never noticed until pointed out in https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/297#note_1799799.https://gitlab.freedesktop.org/wayland/weston/-/issues/724Enhancement: add pid-file option to weston.ini2023-02-24T14:47:36ZfingolfinEnhancement: add pid-file option to weston.iniNow weston can watch the process in order to end with it. But there is now way to indicate to Weston what process needs to be watched. I suggest adding an option `pid-file` to the section `[autolaunch]` of `weston.ini`.Now weston can watch the process in order to end with it. But there is now way to indicate to Weston what process needs to be watched. I suggest adding an option `pid-file` to the section `[autolaunch]` of `weston.ini`.https://gitlab.freedesktop.org/wayland/weston/-/issues/723keymap_options problem2023-02-24T14:31:47Zfingolfinkeymap_options problemWhen I set `keymap_options=grp:caps_switch`, it does not work: neither switching the keymap layout, nor the usual action of Caps Lock. Tried both desktop and kiosk shells.
There is no problem with other `keymap_options`. Now I use `keym...When I set `keymap_options=grp:caps_switch`, it does not work: neither switching the keymap layout, nor the usual action of Caps Lock. Tried both desktop and kiosk shells.
There is no problem with other `keymap_options`. Now I use `keymap_options=grp:shifts_toggle` and this works fine.
* OS: Gentoo
* Weston: 10.0.0
* Wayland: 1.21
* Wayland-protocols: 1.27https://gitlab.freedesktop.org/wayland/weston/-/issues/714GL-Renderer: The render-frame is damaged and 'weston-flower' can show a damag...2023-02-24T01:12:14ZSkyGL-Renderer: The render-frame is damaged and 'weston-flower' can show a damaged flower on the screen### Background info
I try to port weston-10 to a new device. old work is in issue-648(https://gitlab.freedesktop.org/wayland/weston/-/issues/684) on other device.
### Problem
When I use gl-renderer, I find that render-frame is damaged a...### Background info
I try to port weston-10 to a new device. old work is in issue-648(https://gitlab.freedesktop.org/wayland/weston/-/issues/684) on other device.
### Problem
When I use gl-renderer, I find that render-frame is damaged and 'weston-flower' can show a damaged flower on the screen.(see left region on my-post-image ).
When I use pixman-renderer, the all thing is work well.(see right region on my-post-image )
![无标题](/uploads/d82b4e1f6122903e6b53506a66e66111/无标题.png)
### More info
1. I test drmModeAtomicCommit(DRM_MODE_ATOMIC_ALLOW_MODESET|DRM_MODE_PAGE_FLIP_EVENT) and drmHandleEvent() work well.
2. I test modetest will work well.
3. I test 'https://github.com/ds-hwang/gbm_es2_demo' will work well.
4. The weston's log is same in issues-648.
5. The new linux-kernel is 5.4, old-kernel is 4.x(in issue-648).
### Question
1. What is the prossible problems?
2. Can you give me some ideas? I can try to do more test.https://gitlab.freedesktop.org/wayland/weston/-/issues/718Pointer clamping is incorrect at edges2023-02-15T15:02:28ZDerek ForemanPointer clamping is incorrect at edgesOur pointer clamping code behaves in an odd non-decreasing fashion.
For a full explanation, see https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1159#note_1770745Our pointer clamping code behaves in an odd non-decreasing fashion.
For a full explanation, see https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1159#note_1770745https://gitlab.freedesktop.org/wayland/weston/-/issues/717Change application focus2023-02-15T11:55:35ZRaul MunozChange application focusHi, I was looking at the Weston clients' examples and maybe there is an example there that does what I want.
Is there a way to launch an "app" that brings a specific process to the front?
For example, Imagine I have chrome and Weston t...Hi, I was looking at the Weston clients' examples and maybe there is an example there that does what I want.
Is there a way to launch an "app" that brings a specific process to the front?
For example, Imagine I have chrome and Weston terminal. (And maybe more apps)
Weston Terminal is in the Front. If I do SUPER+TAB I can see Chrome. Is there an app that always brings to the front the app I want?
Thanks againhttps://gitlab.freedesktop.org/wayland/weston/-/issues/357Should we keep doing stable releases?2023-02-13T11:39:13ZDaniel Stonedaniel@fooishbar.orgShould we keep doing stable releases?@evelikov pointed out that he thought some things should be tagged some way for a stable release; the reply to that was that we didn't know whether or not we were doing stable releases.
We didn't do any stable releases in 7.x; I think t...@evelikov pointed out that he thought some things should be tagged some way for a stable release; the reply to that was that we didn't know whether or not we were doing stable releases.
We didn't do any stable releases in 7.x; I think the only one we've ever done in the modern era has been 6.0.1. Looking at who picked up 6.0.1, it seems to have been adopted by (in order of visible search results) OpenEmbedded/Yocto/Poky, Fedora, Debian, Ubuntu, VoidLinux, Chromium, Gentoo, ClearLinux, Kaos, Kali, Buildroot, Arch, Exherbo, ptxdist, and openSUSE. That seems like a pretty successful hit rate to me, to the point where I can't really think who would've been shipping Weston but skipped 6.0.0.
6.0.1 contained a bunch of Meson and other build fixes, as well as some other random bugfixes. Those all looked like they were pretty good to have cherry-picked.
Some fixes that we could've had in a 7.0.1 would've been 620f68dc4f72, 5c5f0272d9fa, 95efe82982a6, 267b16e8f441, 3c3fb1cc3c30, ad0fe6bf9600, 3cfd297f2cce, 70e63564153f, 88c8f69a2f95, 5a0706b23898, 58e99de1a842, e5e8188aa592, d2b9b5d1ccff, and 5caef6d355f8 - those would've made for a pretty nice stable release I think, rather than telling people to wait for the next major release which comes with its own problems.
Should we do a stable release again for 8.0.1? If so, should we schedule it (2 weeks after major? 4?) or just do it opportunistically?https://gitlab.freedesktop.org/wayland/weston/-/issues/711Clipboard doesn't appear to working when using in-tandem with the screen-shar...2023-02-06T15:01:33ZMarius VladClipboard doesn't appear to working when using in-tandem with the screen-share modulePresumably we get two clipboards, one for the client and one for the RDP back-end. While copy/paste works
with the RDP back-end, when doing screen-share that doesn't appear to be case.
Using a different client (rather than fullscreen-s...Presumably we get two clipboards, one for the client and one for the RDP back-end. While copy/paste works
with the RDP back-end, when doing screen-share that doesn't appear to be case.
Using a different client (rather than fullscreen-shell) would also need implementing clipboard or have a way
to have multiple back-end and pass data from one head to another *without* any intermediary client?https://gitlab.freedesktop.org/wayland/weston/-/issues/706feature : render-gl support using frame buffer object to achieve off-screen ...2023-01-31T09:56:02Zhaorui wangfeature : render-gl support using frame buffer object to achieve off-screen renderUp to now, `render-gl` depend `GBM` native window system to achieve off-screen render, using default framebuffer pBuffer.
Using this method, it forces using `GBM` when off-screen render.
According to `Framebuffers and Framebuffer Objec...Up to now, `render-gl` depend `GBM` native window system to achieve off-screen render, using default framebuffer pBuffer.
Using this method, it forces using `GBM` when off-screen render.
According to `Framebuffers and Framebuffer Objects (Chapter 9)` in `es_spec_3.2`, we can create a frame buffer and a texture, attching the texture to the frame buffer. And then render to texture and using `ReadPixels` to get the render data.
> I tried and succeeded.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/705Document how to create a AF_VSOCK and pass it to weston rdp2023-01-13T10:32:04ZGianluca S.Document how to create a AF_VSOCK and pass it to weston rdpA PR added allowed to specifying a listener fd on the command line https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/839, but documentation is missing.
I suggest to add a short documentation on this topic:
- Is it possible ...A PR added allowed to specifying a listener fd on the command line https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/839, but documentation is missing.
I suggest to add a short documentation on this topic:
- Is it possible to create a socket with socat and pass it to weston?
- OR Do we have to create the socket in a parent process (in C) as [Microsoft WSL does](https://github.com/microsoft/wslg/blob/main/WSLGd/main.cpp#L292)?
- How to connect from Windows rdp