weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2024-03-12T10:14:20Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/884Cannot link to Wayland Cursor statically2024-03-12T10:14:20ZJordan WilliamsCannot link to Wayland Cursor staticallyWeston's clients can only be built against the Wayland Cursor library when it is built as a shared library. When attempting to link against a static version of Wayland, there are duplicate symbols due to the symbol `os_create_anonymous_f...Weston's clients can only be built against the Wayland Cursor library when it is built as a shared library. When attempting to link against a static version of Wayland, there are duplicate symbols due to the symbol `os_create_anonymous_file` from the `os-compatibility.c` file. This file does in fact, appear to be used directly in the Wayland source code as part of Wayland Cursor as seen [here](https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/cursor/os-compatibility.h?ref_type=heads). I hit this same issue in libdecor previously, as described in [this issue](https://gitlab.freedesktop.org/libdecor/libdecor/-/issues/66).
This can probably just be fixed by renaming the symbol to avoid the conflict.
The build failure follows below for reference.
```
[272/379] Linking target clients/weston-simple-egl
FAILED: clients/weston-simple-egl
gcc -o clients/weston-simple-egl clients/weston-simple-egl.p/meson-generated_.._.._protocol_fractional-scale-v1-protocol.c.o clients/weston-simple-egl.p/meson-generated_.._.._protocol_tearing-control-v1-protocol.c.o clients/weston-simple-egl.p/meson-generated_.._.._protocol_viewporter-protocol.c.o clients/weston-simple-egl.p/meson-generated_.._.._protocol_xdg-shell-protocol.c.o clients/weston-simple-egl.p/meson-generated_.._.._protocol_ivi-application-protocol.c.o clients/weston-simple-egl.p/simple-egl.c.o clients/weston-simple-egl.p/.._shared_matrix.c.o -Wl,--as-needed -Wl,--no-undefined -fuse-ld=lld -Wl,-rpath,/home/jordan/.conan2/p/b/libgl3ac61fc112c8e/p/lib -Wl,-rpath-link,/home/jordan/.conan2/p/b/libgl3ac61fc112c8e/p/lib -Wl,--start-group shared/libshared.a -lm /home/jordan/.conan2/p/b/wayla86eca9b4f04c0/p/lib/libwayland-client.a -lpthread -lrt /home/jordan/.conan2/p/b/libffd42f788d90937/p/lib/libffi.a /home/jordan/.conan2/p/b/wayla86eca9b4f04c0/p/lib/libwayland-server.a /home/jordan/.conan2/p/b/pixma4271311a66625/p/lib/libpixman-1.a /home/jordan/.conan2/p/b/xkbco529ba226868c9/p/lib/libxkbcommon.a /home/jordan/.conan2/p/b/libgl3ac61fc112c8e/p/lib/libEGL.so /home/jordan/.conan2/p/b/libgl3ac61fc112c8e/p/lib/libGLdispatch.so -ldl /usr/lib64/libX11.so /home/jordan/.conan2/p/b/wayla86eca9b4f04c0/p/lib/libwayland-egl.a /home/jordan/.conan2/p/b/libgl3ac61fc112c8e/p/lib/libGLESv2.so /home/jordan/.conan2/p/b/wayla86eca9b4f04c0/p/lib/libwayland-cursor.a -Wl,--end-group
ld.lld: error: duplicate symbol: os_create_anonymous_file
>>> defined at os-compatibility.c:179 (../src/shared/os-compatibility.c:179)
>>> libshared.a.p/os-compatibility.c.o:(os_create_anonymous_file) in archive shared/libshared.a
>>> defined at os-compatibility.c:119 (../src/cursor/os-compatibility.c:119)
>>> os-compatibility.c.o:(.text+0x37) in archive /home/jordan/.conan2/p/b/wayla86eca9b4f04c0/p/lib/libwayland-cursor.a
collect2: error: ld returned 1 exit status
[291/379] Compiling C object clients/weston-editor.p/editor.c.o
ninja: build stopped: subcommand failed.
```https://gitlab.freedesktop.org/wayland/weston/-/issues/872Memory leaks in weston-simple-im2024-01-31T10:13:11ZWismillMemory leaks in weston-simple-imThere are memory leaks in `clients/simple-im.c`. Using `valgrind --leak-check=full` I get the following:
```
==31113== Memcheck, a memory error detector
==31113== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==31113==...There are memory leaks in `clients/simple-im.c`. Using `valgrind --leak-check=full` I get the following:
```
==31113== Memcheck, a memory error detector
==31113== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==31113== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==31113== Command: ./clients/weston-simple-im
==31113== Parent PID: 31112
==31113==
==31113==
==31113== HEAP SUMMARY:
==31113== in use at exit: 177,621 bytes in 1,865 blocks
==31113== total heap usage: 16,290 allocs, 14,425 frees, 762,183 bytes allocated
==31113==
==31113== 17,168 (376 direct, 16,792 indirect) bytes in 1 blocks are definitely lost in loss record 39 of 42
==31113== at 0x484A7BF: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==31113== by 0x487E01E: wl_display_connect_to_fd (in /usr/lib64/libwayland-client.so.0.22.0)
==31113== by 0x487E29C: wl_display_connect (in /usr/lib64/libwayland-client.so.0.22.0)
==31113== by 0x402284: main (simple-im.c:492)
==31113==
==31113== 160,453 (136 direct, 160,317 indirect) bytes in 1 blocks are definitely lost in loss record 42 of 42
==31113== at 0x484A7BF: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==31113== by 0x48A4BB7: xkb_state_new (in /usr/lib64/libxkbcommon.so.0.0.0)
==31113== by 0x40198C: input_method_keyboard_keymap (simple-im.c:206)
==31113== by 0x4AD8961: ??? (in /usr/lib64/libffi.so.8.1.2)
==31113== by 0x4AD52DE: ??? (in /usr/lib64/libffi.so.8.1.2)
==31113== by 0x4AD7F25: ffi_call (in /usr/lib64/libffi.so.8.1.2)
==31113== by 0x487AA22: ??? (in /usr/lib64/libwayland-client.so.0.22.0)
==31113== by 0x487B202: ??? (in /usr/lib64/libwayland-client.so.0.22.0)
==31113== by 0x487B493: wl_display_dispatch_queue_pending (in /usr/lib64/libwayland-client.so.0.22.0)
==31113== by 0x40238A: main (simple-im.c:518)
==31113==
==31113== LEAK SUMMARY:
==31113== definitely lost: 512 bytes in 2 blocks
==31113== indirectly lost: 177,109 bytes in 1,863 blocks
==31113== possibly lost: 0 bytes in 0 blocks
==31113== still reachable: 0 bytes in 0 blocks
==31113== suppressed: 0 bytes in 0 blocks
==31113==
==31113== For lists of detected and suppressed errors, rerun with: -s
==31113== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
```https://gitlab.freedesktop.org/wayland/weston/-/issues/783clients/stacking various improvements2023-07-25T07:08:23ZMarius Vladclients/stacking various improvements> A potential further follow-up from this would be improving the stacking client to allow a new window (similar to 'n') to create a new non-fullscreen window that also explicitly calls set_parent(nil).
The last part would probably need a...> A potential further follow-up from this would be improving the stacking client to allow a new window (similar to 'n') to create a new non-fullscreen window that also explicitly calls set_parent(nil).
The last part would probably need a toytoolkit adjustment as this is skipped entirely if the last parent match current one (which would be true in case of NULL -- or by default). With that I'd like to match what the gtk client is doing with the ability to turn on or off gtk_window_set_transient_for(). It seems that we have some unhandled corner cases.
Obviously also include your changes as well. Probably better to just add a couple of additional keys to do these.
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1261#note_1949810https://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/8Toytoolkit could use a fallback cursor2023-07-04T15:34:32ZBugzilla Migration UserToytoolkit could use a fallback cursor## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#7343)](https://phabricator.freedesktop.org/T7343)**
## Description
If toytoolkit tries to load a cursor that does not exist, it wi...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#7343)](https://phabricator.freedesktop.org/T7343)**
## Description
If toytoolkit tries to load a cursor that does not exist, it will complain and presumably continue with no image for that cursor. This likely leads to the cursor disappearing when attempting to use a cursor not found. It would be much better, if in addition to complaining, toytoolkit would fall back to a cursor that is obviously wrong.
This issue was encountered with the Weston DND demo, when no real cursor theme was available, and the new dnd cursors are not found in libwayland-cursor.
Should the fallback cursor be provided by toytoolkit itself, or by libwayland-cursor default cursors, or by picking some default cursor already provided by libwayland-cursor?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/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/601Split up clients/ into their own repository2022-08-10T07:25:22ZMarius VladSplit up clients/ into their own repositoryAs the $subj says, this issue is about taking out clients/ directory out of weston and move them into their own repository.
Would like to get some feedback on what other people think about that. Presumably this would be called wayland-...As the $subj says, this issue is about taking out clients/ directory out of weston and move them into their own repository.
Would like to get some feedback on what other people think about that. Presumably this would be called wayland-clients, or wayland-demo-clients, somewhere along those lines.
simple-clients we currently have would probably make the gist of it, but probably also some of the demo clients. In weston, we'll just have desktop-shell client, ivi one, and the screenshooter (IDK maybe a few more?). I guess also that some the clients might need a bit of work to deal with compositors not implementing certain protocols, but I see it the other way around as well, people adding protocols in clients such that it supports those extensions.
One of the issue people pointed was that clients/ would depend on libweston, and that's a fact that we have today (well not directly obviously, but in the meson build part), so I had a stab at it trying build only simple-clients out of clients/ directory. See https://gitlab.freedesktop.org/mvlad/weston/-/commits/wip/mvlad/only-clients-build for an example. Note that was just a hack but it is technically possible if we decide this is not really helpful and potentially go on this route, which was the initial thing I tried.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/441The ball in weston-simple-damage leaves a trail after itself2022-01-13T22:20:18ZVlad ZahorodniiThe ball in weston-simple-damage leaves a trail after itselfIf weston-simple-damage runs with weston, the ball leaves a trail after itself. This bug can be also reproduced with kwin. It doesn't matter if transformed buffers are provided.If weston-simple-damage runs with weston, the ball leaves a trail after itself. This bug can be also reproduced with kwin. It doesn't matter if transformed buffers are provided.https://gitlab.freedesktop.org/wayland/weston/-/issues/566Demote weston-terminal to a demo or remove it2022-01-10T20:59:57ZSimon Sercontact@emersion.frDemote weston-terminal to a demo or remove itI'm not sure it's a good idea for the Weston project to maintain a fully-fledged terminal emulator. I think it would be better to keep it as a demo instead. That way users can lower their expectations in terms of support and feature requ...I'm not sure it's a good idea for the Weston project to maintain a fully-fledged terminal emulator. I think it would be better to keep it as a demo instead. That way users can lower their expectations in terms of support and feature requests.
Potential action items:
- Clearly label it as a demo in the README
- Move it from the Meson option `tools` to `demo-clients`
- Don't install it by defaulthttps://gitlab.freedesktop.org/wayland/weston/-/issues/559Missing mouse support in weston-terminal2022-01-10T20:27:51ZDemi Marie Obenourdemiobenour@gmail.comMissing mouse support in weston-terminalweston-terminal doesn’t have mouse support.weston-terminal doesn’t have mouse support.https://gitlab.freedesktop.org/wayland/weston/-/issues/558Missing escape sequences in weston-terminal2022-01-10T20:27:49ZDemi Marie Obenourdemiobenour@gmail.comMissing escape sequences in weston-terminalweston-terminal is missing support for some escape sequences used by Vim.weston-terminal is missing support for some escape sequences used by Vim.https://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/280toytoolkit’s keyboard_repeat_func() is producing unusable timestamps2019-10-17T11:42:40ZLink Mauvetoytoolkit’s keyboard_repeat_func() is producing unusable timestampsWhen using `window_set_key_handler()`, pressed and released events work as expected, but the timerfd-driven key repeats, generated from the `keyboard_repeat_func()` callback, all share the pressed event’s timestamp `input->repeat_time`.
...When using `window_set_key_handler()`, pressed and released events work as expected, but the timerfd-driven key repeats, generated from the `keyboard_repeat_func()` callback, all share the pressed event’s timestamp `input->repeat_time`.
This prevents the timestamp from being used in any usable fashion.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
```