weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2023-07-24T08:47:16Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/780Toytoolkit window minimum size no longer respected2023-07-24T08:47:16ZPekka Paalanenppaalanen@gmail.comToytoolkit window minimum size no longer respectedThe following discussion from !1298 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1298#note_2006556):
> This MR broke the window minimum size constraints. I am...The following discussion from !1298 should be addressed:
- [ ] @pq started a [discussion](https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1298#note_2006556):
> This MR broke the window minimum size constraints. I am now able to interactively resize a window smaller than its smallest allowed size, which breaks e.g. decorations drawing. Reverting this patch fixes the problem.https://gitlab.freedesktop.org/wayland/weston/-/issues/4Check toytoolkit shm space reservation.2023-07-04T15:34:32ZBugzilla Migration UserCheck toytoolkit shm space reservation.## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#20)](https://phabricator.freedesktop.org/T20)**
## Description
In window.c, display_create_shm_surface() uses data_length_for_shm_...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#20)](https://phabricator.freedesktop.org/T20)**
## Description
In window.c, display_create_shm_surface() uses data_length_for_shm_surface() to compute the pool size. However, that hardcodes RGBA32 pixel format, even if we were going to use RGB565.
Review the code, and fix the overallocation if it indeed happens.https://gitlab.freedesktop.org/wayland/weston/-/issues/46Stop using cairo-egl in demo apps2022-07-21T14:35:25ZBugzilla Migration UserStop using cairo-egl in demo apps## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#83878)](https://bugs.freedesktop.org/show_bug.cgi?id=83878)**
## Description
Currently, the toytoolkit uses cairo-egl if it is available, wh...## Submitted by Pekka Paalanen
Assigned to **Wayland bug list**
**[Link to original bug (#83878)](https://bugs.freedesktop.org/show_bug.cgi?id=83878)**
## Description
Currently, the toytoolkit uses cairo-egl if it is available, which means it will create an OpenGL or GLES context for Cairo drawing. This is wasteful, and at least I recommend people to build Weston with --with-cairo=image anyway.
However, we have a few demos, that depend on cairo-gl or cairo-glesv2, and at least one demo, which cannot run with cairo-gl because it directly uses GLESv2. (Linking both GL and GLES into the same process is a bad idea.)
The demo apps that currently require cairo-egl (that is, cairo-gl or cairo-glesv2), should be modified to not rely on Cairo for GL(ES).
A demo app, that used GL or GLES for rendering, should get the decorations from toytoolkit as images, upload them to GL textures, and compose them into the window. Obviously this is code that can be shared between many demo apps, but it should not be in toytoolkit (window.c). It needs to be separate, so that the toytoolkit does not pull in any EGL or GL libraries. Choosing the flavor of GL must be up to the app.
Once this works correctly, using --with-cairo=image will not exclude any demo apps from the build like it does now.
This would be a good project for someone new to get familiar with the demo code.https://gitlab.freedesktop.org/wayland/weston/-/issues/611weston-simple-dmabuf-feedback crashes on KDE2022-05-23T13:25:02ZRobert Maderweston-simple-dmabuf-feedback crashes on KDEOn recent Kwin 5.24 `weston-simple-dmabuf-feedback` crashes with the following error:
```
error: INITIAL_BUFFER_FORMAT not supported by the hardware
```
[Here](https://gitlab.freedesktop.org/wayland/weston/-/blob/6129cbd8806e0c6fffcf597...On recent Kwin 5.24 `weston-simple-dmabuf-feedback` crashes with the following error:
```
error: INITIAL_BUFFER_FORMAT not supported by the hardware
```
[Here](https://gitlab.freedesktop.org/wayland/weston/-/blob/6129cbd8806e0c6fffcf59767150f12700881fad/clients/simple-dmabuf-feedback.c#L1160) we assume that the first non-scanout tranche includes `DRM_FORMAT_XRGB8888`. However Kwin orders formats into several tranches like this:
```
compositor sent main_device event for dma-buf feedback - /dev/dri/renderD128
├──────target_device for tranche - /dev/dri/renderD128
│ └scanout tranche? no
│ ├────────tranche format/modifier pair - format ABGR2101010, modifier AMD_GFX10_RBPLUS,GFX9_64K_R_X,PIPE_XOR_BITS=4,PACKERS=3 (0x200000018801b03)
│ ├────────...
│ └end of tranche
├──────target_device for tranche - /dev/dri/renderD128
│ └scanout tranche? no
│ ├────────tranche format/modifier pair - format ABGR8888, modifier AMD_GFX10_RBPLUS,GFX9_64K_R_X,PIPE_XOR_BITS=4,PACKERS=3 (0x200000018801b03)
│ ├────────...
│ └end of tranche
├──────target_device for tranche - /dev/dri/renderD128
│ └scanout tranche? no
│ ├────────tranche format/modifier pair - format XBGR16161616F, modifier AMD_GFX10_RBPLUS,GFX9_64K_R_X,PIPE_XOR_BITS=4,PACKERS=3 (0x200000018801b03)
│ ├────────...
│ └end of tranche
└end of dma-buf feedback
```
That is in accordance with the spec and thus should be supported.Robert MaderRobert Maderhttps://gitlab.freedesktop.org/wayland/weston/-/issues/576Required order when emitting globals2022-01-07T20:16:13ZJulian OrthRequired order when emitting globalsWhen globals are emitted from a registry, is there a required order in which they are emitted? I could not find anything like that in the spec but the weston example clients segfault when a wl_seat is emitted before a wl_compositor.When globals are emitted from a registry, is there a required order in which they are emitted? I could not find anything like that in the spec but the weston example clients segfault when a wl_seat is emitted before a wl_compositor.https://gitlab.freedesktop.org/wayland/weston/-/issues/119Update the example clients to support the stable version of xdg_shell2021-10-14T16:40:06ZeyelashUpdate the example clients to support the stable version of xdg_shellI am trying to update a simple wayland compositor that I wrote to the stable version of xdg_shell and it would be great to have some simple clients to test against.I am trying to update a simple wayland compositor that I wrote to the stable version of xdg_shell and it would be great to have some simple clients to test against.https://gitlab.freedesktop.org/wayland/weston/-/issues/325Remove unused function window_set_preferred_format()2019-12-11T19:30:32ZLeandro RibeiroRemove unused function window_set_preferred_format()In `clients/window.c` and the corresponding `.h` we have the function `window_set_preferred_format()`, which is not being used. Instead, we have this: `window->preferred_format = foo`.
I don't think it's necessary to have this function,...In `clients/window.c` and the corresponding `.h` we have the function `window_set_preferred_format()`, which is not being used. Instead, we have this: `window->preferred_format = foo`.
I don't think it's necessary to have this function, because this kind of assignment is being made only once and it's already pretty clear.https://gitlab.freedesktop.org/wayland/weston/-/issues/201toytoolkit assumes wl_seat-s are announced after the wl_data_device_manager2019-06-19T07:49:15ZSergey Bugaevtoytoolkit assumes wl_seat-s are announced after the wl_data_device_manager[`registry_handle_global()`](https://gitlab.freedesktop.org/wayland/weston/blob/master/clients/window.c#L5900) handles `wl_seat`s and the `wl_data_device_manager` like this:
```c
} else if (strcmp(interface, "wl_seat") == 0) {
disp...[`registry_handle_global()`](https://gitlab.freedesktop.org/wayland/weston/blob/master/clients/window.c#L5900) handles `wl_seat`s and the `wl_data_device_manager` like this:
```c
} else if (strcmp(interface, "wl_seat") == 0) {
display_add_input(d, id, version);
} else /*...*/ if (strcmp(interface, "wl_data_device_manager") == 0) {
d->data_device_manager_version = MIN(version, 3);
d->data_device_manager =
wl_registry_bind(registry, id,
&wl_data_device_manager_interface,
d->data_device_manager_version);
}
```
while [`display_add_input()`](https://gitlab.freedesktop.org/wayland/weston/blob/master/clients/window.c#L5792) does this:
```c
if (d->data_device_manager) {
input->data_device =
wl_data_device_manager_get_data_device(d->data_device_manager,
input->seat);
wl_data_device_add_listener(input->data_device,
&data_device_listener,
input);
}
```
So, in case the registry happens to announce `wl_data_device_manager` _after_ a `wl_seat`, that seat ends up unable to copy/paste/drag-n-drop.
Weston does this:
```bash
$ weston-info | egrep 'data|seat'
interface: 'wl_data_device_manager', version: 3, name: 8
interface: 'wl_seat', version: 5, name: 10
```
and Mutter this:
```bash
$ weston-info | egrep 'data|seat'
interface: 'wl_data_device_manager', version: 3, name: 7
interface: 'wl_seat', version: 5, name: 16
name: seat0
```
which is probably why this bug has gone unnoticed :smiley:https://gitlab.freedesktop.org/wayland/weston/-/issues/202weston-terminal crashes on wl_data_source.action2019-04-20T10:58:05ZSergey Bugaevweston-terminal crashes on wl_data_source.actiontoytoolkit binds `wl_data_device_manager` v3, yet weston-terminal [doesn't set up](https://gitlab.freedesktop.org/wayland/weston/blob/master/clients/terminal.c#L2210) a handler for `wl_data_source.action`:
```c
static const struct wl_da...toytoolkit binds `wl_data_device_manager` v3, yet weston-terminal [doesn't set up](https://gitlab.freedesktop.org/wayland/weston/blob/master/clients/terminal.c#L2210) a handler for `wl_data_source.action`:
```c
static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
data_source_cancelled
};
```
which results in a crash:
```
[3771621.417] wl_data_device@12.data_offer(new id wl_data_offer@1797229232)
[3771621.448] wl_data_offer@4278190080.offer("text/plain;charset=utf-8")
[3771621.455] wl_data_source@25.action(0)
listener function for opcode 5 of wl_data_source is NULL
```https://gitlab.freedesktop.org/wayland/weston/-/issues/42SIGSEGV in widget_destroy: Touch events during widget destroy cause weston-te...2018-06-30T10:49:16ZBugzilla Migration UserSIGSEGV in widget_destroy: Touch events during widget destroy cause weston-terminal crash## Submitted by Anu Reddy
Assigned to **Wayland bug list**
**[Link to original bug (#83113)](https://bugs.freedesktop.org/show_bug.cgi?id=83113)**
## Description
Created attachment 105303
gdb-backtrace
Steps to reproduce:
1. Laun...## Submitted by Anu Reddy
Assigned to **Wayland bug list**
**[Link to original bug (#83113)](https://bugs.freedesktop.org/show_bug.cgi?id=83113)**
## Description
Created attachment 105303
gdb-backtrace
Steps to reproduce:
1. Launch weston
2. Run weston-terminal
3. Right-click on weston-terminal (menu/widget activated)
4. Touch the terminal's black surface with two fingers
6. Now, remove fingers from terminal's black surface
5. observe that terminal is destroyed with segmentation fault
Software stack:
wayland (HEAD) remotes/origin/HEAD-0-g6d0f298
drm (HEAD) heads/master-16-gd686160
mesa (HEAD) remotes/origin/10.2-0-gd82ca4e
libva (HEAD) libva-1.3.1-0-g053f70f
intel-driver (HEAD) 1.3.1-0-ga720bc8
cairo (HEAD) heads/1.12-0-g59e2a93
libinput (HEAD) heads/master-163-gbb10ec8
weston (HEAD) remotes/origin/master-0-g652c794
**Attachment 105303**, "gdb-backtrace":
[gdb_backtrace.log](/uploads/49dbe8afd0e653028067f1cca49b8f8e/gdb_backtrace.log)