wayland issueshttps://gitlab.freedesktop.org/wayland/wayland/-/issues2024-03-29T07:04:09Zhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/237Mapping a lot of windows at once using wl_shm gets Xwayland killed2024-03-29T07:04:09ZOlivier FourdanMapping a lot of windows at once using wl_shm gets Xwayland killed## Description
When Xwayland cannot use glamor and GBM (typically when GL is implemented in software with LLVM as when running in a virtual machine), it falls back to `wl_shm` to pass its buffers around.
In that case, if the X11 client...## Description
When Xwayland cannot use glamor and GBM (typically when GL is implemented in software with LLVM as when running in a virtual machine), it falls back to `wl_shm` to pass its buffers around.
In that case, if the X11 clients creates a whole lot of X11 windows at once, flooding the Wayland compositor as in xorg/xserver#1222, Wayland will abort taking down `Xwayland` with the following error:
`request could not be marshaled: can't send file descriptor`
This message originates from [`wl_connection_put_fd()`](https://gitlab.freedesktop.org/wayland/wayland/-/blob/1.16/src/connection.c#L432-435) because [`wl_connection_flush()`](https://gitlab.freedesktop.org/wayland/wayland/-/blob/1.16/src/connection.c#L314-320) returned `-1` as it hits the error case with `errno` being `EAGAIN` (typically the Wayland compositor cannot cope and the socket got full).
Trying to reconnect (as with xorg/xserver!756) will flood the Wayland compositor even more so this is unlikely to help in that particular case.
After some discussions on irc on #wayland with @emersion, @jadahl and @DemiMarie, Jonas suggested a possible solution for now would be to have an unbound output buffer for Wayland clients (which is different from #159) as the needs for clients are different from the ones for the server, it is not the same issue.
FWIW, I tried @mstoeckl's https://gitlab.freedesktop.org/mstoeckl/wayland/-/commits/variable-connection branch but to no avail, it still fails with `EGAIN` in `sendmsg()` called from `wl_connection_flush()` so maybe that branch doesn't account for all cases.https://gitlab.freedesktop.org/wayland/wayland/-/issues/317cursor: Theme that inherits itself causes infinite recursion2024-03-28T12:51:34ZNicolas Fellacursor: Theme that inherits itself causes infinite recursionThis was originally reported as https://bugs.kde.org/show_bug.cgi?id=457926
While of course nonsensical it is possible to write an xcursor theme that inherits itself, either directly or indirectly
This will cause infinite recursion whe...This was originally reported as https://bugs.kde.org/show_bug.cgi?id=457926
While of course nonsensical it is possible to write an xcursor theme that inherits itself, either directly or indirectly
This will cause infinite recursion when loading the theme via libwayland-cursor
A sample file is mentioned in the original report.
Backtrace from an affected application:
```
#0 __GI___libc_read (nbytes=4096, buf=0x17d2bf0, fd=29) at ../sysdeps/unix/sysv/linux/read.c:26
#1 __GI___libc_read (fd=29, buf=0x17d2bf0, nbytes=4096) at ../sysdeps/unix/sysv/linux/read.c:24
#2 0x00007f75baa5c5b8 in _IO_new_file_seekoff (fp=0x155a000, offset=28, dir=<optimized out>, mode=<optimized out>) at fileops.c:1015
#3 0x00007f75baa59523 in __GI_fseek (fp=0x155a000, offset=28, whence=0) at fseek.c:36
#4 0x00007f75b78e2486 in _XcursorSeekToToc (toc=<optimized out>, fileHeader=0x16f4470, file=0x7ffe83376ef0) at ../cursor/xcursor.c:375
#5 _XcursorFileReadChunkHeader (chunkHeader=0x7ffe83376ee0, toc=<optimized out>, fileHeader=0x16f4470, file=0x7ffe83376ef0) at ../cursor/xcursor.c:388
#6 _XcursorReadImage (toc=<optimized out>, fileHeader=0x16f4470, file=0x7ffe83376ef0) at ../cursor/xcursor.c:478
#7 XcursorXcFileLoadImages (size=24, file=0x7ffe83376ef0) at ../cursor/xcursor.c:555
#8 XcursorFileLoadImages (size=24, file=0x155a000) at ../cursor/xcursor.c:609
#9 load_all_cursors_from_dir (load_callback=0x7f75b78e1bf0 <load_callback>, user_data=0x12db8c0, size=24, path=0x16f3b30 "/home/nico/.icons/VS5/cursors/") at ../cursor/xcursor.c:932
#10 xcursor_load_theme (theme=theme@entry=0x17cab00 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:989
#11 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17caa70 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#12 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca9e0 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#13 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca950 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#14 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca8c0 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#15 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca830 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#16 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca7a0 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#17 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca710 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#18 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca680 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#19 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca5f0 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#20 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca560 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
#21 0x00007f75b78e268d in xcursor_load_theme (theme=theme@entry=0x17ca4d0 "VS5", size=size@entry=24, user_data=user_data@entry=0x12db8c0, load_callback=0x7f75b78e1bf0 <load_callback>) at ../cursor/xcursor.c:1006
```
Observed with wayland 1.20.0 on Fedora 36https://gitlab.freedesktop.org/wayland/wayland/-/issues/4Add sanity checks for libwayland-client users2024-03-28T09:19:01ZBugzilla Migration UserAdd sanity checks for libwayland-client users## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#50)](https://phabricator.freedesktop.org/T50)**
## Description
We have quite many assumptions for libwayland-client users:
- whe...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#50)](https://phabricator.freedesktop.org/T50)**
## Description
We have quite many assumptions for libwayland-client users:
- when a wl_event_queue is destroyed, we assume (or do we?) there are no objects on it
- what happens if you destroy a wl_event_queue that has queued events?
- Or move an object to a different queue while old queue has events?
- when a wl_display is destroyed, all objects, event queues etc. referencing it have already been destroyed
- the argument objects of a request come from the same wl_display as the object itself
- when you pass in two things, like wl_display and wl_event_queue, to a function as arguments, make sure they are referring to the same wl_display beneath
The checks should be as light-weight as possible. If a thing does not already have a list of all other things referencing it, we don't want to add a list just for the checking, I assume. Although, that probably would ease debugging... OTOH, Valgrind should be able to give the same information. Counters should be enough, preferably protected by existing mutexes that are already taken on that code path anyway.
The reaction to a detected error should be abort(). Using an object from a wrong wl_display is a bug right at that point. Destroying a thing that is still being used - you cannot pick between not destroying it and destroying it anyway, so better just stop right there.
These sanity checks should be accompanied by tests that trigger them.https://gitlab.freedesktop.org/wayland/wayland/-/issues/3Document Wayland XML language2024-03-28T09:19:01ZBugzilla Migration UserDocument Wayland XML language## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#49)](https://phabricator.freedesktop.org/T49)**
## Description
Currently the specification of the Wayland XML language for protoco...## Submitted by Pekka Paalanen `@pq`
Assigned to **Pekka Paalanen `@pq`**
**[Link to original bug (#49)](https://phabricator.freedesktop.org/T49)**
## Description
Currently the specification of the Wayland XML language for protocol specifications is "what wayland-scanner does".
What that really is should be documented properly. Especially the newly proposed attributes for enums require documentation on what they really mean.
Once there is documentation, one could think about adding wayland-scanner tests as another Task.https://gitlab.freedesktop.org/wayland/wayland/-/issues/2Add surface filters to input interfaces (wl_pointer, wl_keyboard, wl_touch)2024-03-28T09:19:01ZBugzilla Migration UserAdd surface filters to input interfaces (wl_pointer, wl_keyboard, wl_touch)## Submitted by Daniel Stone `@daniels`
Assigned to **Daniel Stone `@daniels`**
**[Link to original bug (#10)](https://phabricator.freedesktop.org/T10)**
## Description
All input interfaces (pointer/keyboard/touch) created by a pa...## Submitted by Daniel Stone `@daniels`
Assigned to **Daniel Stone `@daniels`**
**[Link to original bug (#10)](https://phabricator.freedesktop.org/T10)**
## Description
All input interfaces (pointer/keyboard/touch) created by a particular client are currently active for all surfaces created by that client. This is undesirable if different components of the client are creating and handling different surfaces, e.g. a web browser which embeds media, or anything embedding GL.
We could fix this by adding a surface filter to a newer version of the input interfaces, which will only send events to those objects for specified surfaces.Daniel Stonedaniel@fooishbar.orgDaniel Stonedaniel@fooishbar.orghttps://gitlab.freedesktop.org/wayland/wayland/-/issues/1wl_seat::get_* requests are racy2024-03-28T09:19:01ZBugzilla Migration Userwl_seat::get_* requests are racy## Submitted by Daniel Stone `@daniels`
Assigned to **Daniel Stone `@daniels`**
**[Link to original bug (#9)](https://phabricator.freedesktop.org/T9)**
## Description
The get_pointer, get_keyboard and get_touch methods of wl_seat ...## Submitted by Daniel Stone `@daniels`
Assigned to **Daniel Stone `@daniels`**
**[Link to original bug (#9)](https://phabricator.freedesktop.org/T9)**
## Description
The get_pointer, get_keyboard and get_touch methods of wl_seat contain a fundamental race:
- client binds to wl_seat
- compositor sends wl_seat::capabilities(KEYBOARD)
- keyboard is unplugged, compositor destroys seat->keyboard
- client calls wl_seat::get_keyboard()
- oops ...
Instead of having the advertise/get methods, we should instead just send the objects directly to the clients with a new_id event, and let the clients destroy them if they don't want them. This would also require a destroy request from the client.Daniel Stonedaniel@fooishbar.orgDaniel Stonedaniel@fooishbar.orghttps://gitlab.freedesktop.org/wayland/wayland/-/issues/159Blocked clients that received too many events get destroyed even though the W...2024-03-26T14:27:06ZmagiblotBlocked clients that received too many events get destroyed even though the Wayland connection is not broken
This problem is reproducible in every DE I tried: GNOME, Plasma, weston. The most common situation where this happens is in applications blocked due to disk I/O. As can be seen in https://bugreports.qt.io/browse/QTBUG-66997 and https://...
This problem is reproducible in every DE I tried: GNOME, Plasma, weston. The most common situation where this happens is in applications blocked due to disk I/O. As can be seen in https://bugreports.qt.io/browse/QTBUG-66997 and https://bugs.kde.org/show_bug.cgi?id=392376, developers have assumed it's the application's fault for doing blocking tasks in the main GUI thread.
However, the issue can be reproduced by simply following these steps:
1. Open a Wayland application from a terminal.
2. Suspend it with Ctrl+Z.
3. Move the mouse over the application's window for a few seconds.
4. Resume the application with 'fg' and witness how it dies.
Note: this seems to happen less often in GNOME. If you cannot reproduce at the first attempt, try Kwin or weston instead.
Obviously, it wouldn't make any sense if Wayland didn't allow suspending or debugging applications. So I began to debug what was happening in libwayland and observed the following. This is with the `weston-evendemo` client on GNOME:
1. Client resumes execution after being blocked.
2. Client receives events from the server and dispatches them (`handle_display_data`: https://gitlab.freedesktop.org/wayland/weston/-/blob/bac1a7a71f5d49451ad5c6655ef4e79334ba9c38/clients/window.c#L6201).
3. Client flushes the connection (`display_run`: https://gitlab.freedesktop.org/wayland/weston/-/blob/bac1a7a71f5d49451ad5c6655ef4e79334ba9c38/clients/window.c#L6509)
4. Server receives the events and begins processing them (`wl_client_connection_data`: https://gitlab.freedesktop.org/wayland/wayland/-/blob/cc8b6aa3d937dda055cb25fdbec55d0afb6be2a0/src/wayland-server.c#L323)
5. At some point, the server finds an error and destroys the client. Only then the client's window is closed (that is, if the client never flushes its data, it is also never destroyed).
6. Client notices an error in epoll_wait (`EPOLLHUP`) and exits.
Other applications may detect the error in a different way. Qt, for example, keeps reading from the socket until `recvmsg` returns the error `Connection reset by peer` (104). libwayland handles this error in `read_events` (https://gitlab.freedesktop.org/wayland/wayland/-/blob/cc8b6aa3d937dda055cb25fdbec55d0afb6be2a0/src/wayland-client.c#L1482). Then Qt aborts in https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylanddisplay.cpp?id=00390ccf893aa02c8f51e0887624455c7e8d111d#n177.
A debug plan for this issue can be:
1. Start a Wayland session. There, open a terminal and run `weston-eventdemo`.
2. Suspend `weston-eventdemo` and hover the mouse over it for a few seconds.
3. Switch to another tty/DE or a remote shell.
4. Attach a debugger on the compositor. Set breakpoints on `wl_resource_post_error_vargs` and `destroy_client_with_error`. Let it continue.
5. Attach a debugger on `weston-eventdemo`. Set a breakpoint on `handle_display_data` if you wish to inspect how it processes the received events. Otherwise, just let it continue. The compositor should hit a breakpoint after `weson-eventdemo` performs `wl_display_flush`. Make sure the breakpoint is hit because of `weson-eventdemo` and not another client.
What happens next varies among compositors:
* In GNOME, the breakpoint is hit at `wl_resource_post_error_vargs` with `msg="invalid object %u"`.
* In weston and Kwin, the breakpoint is hit at `destroy_client_with_error`. If you repeat the experiment with a breakpoint set on `wl_client_connection_data`, you'll notice that `client->error` is already set (that is, even before the client's data is read). Then, you can do the following:
1. `set client->error=0` to dismiss the error flag.
2. `watch -l client->error` to break when the error is detected next time for this client.
3. Delete the breakpoint on `wl_client_connection_data`, let the compositor continue and detach the debugger on `weston-eventdemo`.
4. Switch back to the DE, suspend `weston-eventdemo` again from the terminal and hover the mouse over it. The breakpoint will be hit while you do this, so be sure to have a remote shell from where you can run `sudo chvt <tty>`, or run `sudo sleep 10 && sudo chvt <tty>` before switching to the DE.
5. In kwin, the breakpoint is hit at:
```cc
#0 handle_array (resource=resource@entry=0x559670da6a00, opcode=opcode@entry=2, args=args@entry=0x7ffded0f0640, send_func=0x7f157422d050 <wl_closure_send>) at ../wayland-1.18.0/src/wayland-server.c:231
#1 0x00007f157422779c in wl_resource_post_event_array (resource=resource@entry=0x559670da6a00, opcode=opcode@entry=2, args=args@entry=0x7ffded0f0640) at ../wayland-1.18.0/src/wayland-server.c:238
#2 0x00007f1574227891 in wl_resource_post_event (resource=0x559670da6a00, opcode=2) at ../wayland-1.18.0/src/wayland-server.c:253
#3 0x00007f1577630770 in () at /usr/lib/libKF5WaylandServer.so.5
#4 0x00007f1576ad2cde in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffded0f0960, r=0x55966fe499d0, this=0x559670c6c240) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#5 doActivate<false>(QObject*, int, void**) (sender=0x55966fd5f990, signal_index=8, argv=0x7ffded0f0960) at kernel/qobject.cpp:3870
#6 0x00007f1577600866 in KWayland::Server::SeatInterface::pointerPosChanged(QPointF const&) () at /usr/lib/libKF5WaylandServer.so.5
```
Because `send_func` fails. `send_func` is actually `wl_closure_send`; further inspection reveals that the error originates from `sendmsg` failing with `Resource temporally unavailable (11)`. Disabling the error setting after `send_func` (or conditioning it to `errno != EAGAIN`) seems to fix the issue, but is not necessarily a good solution. Another way would be unsetting `client->error` in `wl_client_connection_data`. In the end, if the client is able to message the server normally, I guess it doesn't deserve being destroyed? (I say this without having any knowledge about the protocol or libwayland's invariants).
This is all I could figure out. I hope it's useful.
Thank you very much!https://gitlab.freedesktop.org/wayland/wayland/-/issues/450Wayland + Nvidia Laptop RTX 4050 flickering2024-03-18T18:47:22ZplaygamesgoWayland + Nvidia Laptop RTX 4050 flickeringXwayland apps have flickering issues with Nvidia drives, same issue on driver versions 550, 545, 535, and 525. Arch with Plamsa 6, Hyprland. Ubuntu with Plasma 5 and Gnome. Kubuntu, Manjaro, with Plasma. But for some strange reason, when...Xwayland apps have flickering issues with Nvidia drives, same issue on driver versions 550, 545, 535, and 525. Arch with Plamsa 6, Hyprland. Ubuntu with Plasma 5 and Gnome. Kubuntu, Manjaro, with Plasma. But for some strange reason, when obs is enabled, flickering issues are gone.
No such problem on X11. Same problem with firefox with disabled wayland (Manual disabled wayland for testing), vesktop, [steam](https://drive.google.com/file/d/1A4MHfxWOl7OhVTtuNPE3mXJRtq0f6RP8/view?usp=sharing), javafx apps.https://gitlab.freedesktop.org/wayland/wayland/-/issues/449Make it explicit that `read` cannot be used with keymap file descriptors.2024-03-15T11:17:00ZJulian OrthMake it explicit that `read` cannot be used with keymap file descriptors.This is true at least for compositors using memfds where multiple clients might receive the same file description. I'm not aware of any clients trying to do this but it seems possible that someone might assume that this works.
Something...This is true at least for compositors using memfds where multiple clients might receive the same file description. I'm not aware of any clients trying to do this but it seems possible that someone might assume that this works.
Something like
>It is not guaranteed that this file descriptor can be used for any operations other than mmap(2). Clients should not use read(2) to read the keymap.
might be useful.https://gitlab.freedesktop.org/wayland/wayland/-/issues/89Add a way to deprecate part of a protocol2024-03-12T13:22:58ZSimon Sercontact@emersion.frAdd a way to deprecate part of a protocolSometimes it's desirable to deprecate part of a protocol as they evolve:
- `wl_shell` in `wayland` is deprecated with a plaintext note
- `format` in `wp_linux_dmabuf_unstable_v1` will probably get deprecated too
However there's no way ...Sometimes it's desirable to deprecate part of a protocol as they evolve:
- `wl_shell` in `wayland` is deprecated with a plaintext note
- `format` in `wp_linux_dmabuf_unstable_v1` will probably get deprecated too
However there's no way to explicitly mark an interface, event or request as deprecated via an XML attribute. Having such an attribute could be useful for both code generators and documentation generators.https://gitlab.freedesktop.org/wayland/wayland/-/issues/448libwayland static builds aren't well supported2024-03-12T10:16:25ZDerek Foremanlibwayland static builds aren't well supportedThis came up with https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1472 which hilights the fact that libwayland-cursor when built statically collides with other software (libdecor, libweston) that has os_create_anonymous_fi...This came up with https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1472 which hilights the fact that libwayland-cursor when built statically collides with other software (libdecor, libweston) that has os_create_anonymous_file.
My initial suggestion to just burn down static libraries entirely and change all our lib builds to shared was not met with mirth: !372
The problems I see so far are:
- Our test suite doesn't pass when only static libraries are built (fix in !373)
- Our CI doesn't perform static library builds
- Our libraries use symbol names like `os_create_anonymous_file` that collide with other libs.
There is some humour in the fact that `os_create_anonymous_file` is copied from weston(a88a4386), and this issue arose because it then collided with weston. We probably should prefix every non-static function with something distinct to these libraries.
This problem has only been noticed with libwayland-cursor so far, but all of libwayland probably needs an audit for Bad symbol names, as we have at least a `get_next_argument` in `wayland-private.h` that could cause a static library use a surprise.
Perhaps surprisingly, there doesn't seem to be a problem when `libwayland-server.a` and `libwayland-client.a` are used at the same time.
tl;dr: We probably need to:
- fix the test suite (land !373)
- Enable static builds in the test suite
- Audit all the symbols that end up in .a files to make sure they have a wl_mumble_ prefix
It would also be nice to add some kind of automated test that ensures that no .a file is produced with unprefixed symbols, but I'm not sure that's possible...https://gitlab.freedesktop.org/wayland/wayland/-/issues/447Request for clarication, sync mode wl_subsurfaces2024-03-12T09:46:59ZyshuiRequest for clarication, sync mode wl_subsurfacesThe behavior of sync mode `wl_subsurface`s is not clearly defined in some corner cases. This is briefly discussed in #324 as well, but I don't want to lump all subsurface related questions in one issue.
> In synchronized mode, wl_surfac...The behavior of sync mode `wl_subsurface`s is not clearly defined in some corner cases. This is briefly discussed in #324 as well, but I don't want to lump all subsurface related questions in one issue.
> In synchronized mode, wl_surface.commit on a sub-surface will accumulate the committed state in a cache, but the state will not be applied and hence will not change the compositor output. **The cached state is applied to the sub-surface immediately after the parent surface's state is applied.**
It's not immediately clear when the parent surface's state will be applied, if the parent surface is also in sync mode. Consider this surface tree:
`root -> P -> C`
Both `P` and `C` are sync, `root` is desync. Consider these sequence of operations:
```
# start: P has state_P1, C has state_C1
C.change_state() -> C has state_C1, and pending state state_C2
C.commit() -> C has state_C1, cached state state_C2
P.commit() -> what states does C have now?
C.change_state() -> C has ?, cached state ?, and pending state state_C3
C.commit() -> C has ?, cached state state_C3??
root.commit() -> what state does C have now? state_C2 or state_C3?
```
One way to interpret the spec is that, `P.commit()` should accept the cached state of `C` into its own cached state. Which means the blanks should be filled in like this:
```
# start: P has state_P1, C has state_C1
C.change_state() -> C has state_C1, and pending state state_C2
C.commit() -> C has state_C1, cached state state_C2
P.commit() -> C has state_C1, cached state state_C2
C.change_state() -> C has state_C1, cached state_C2, and pending state state_C3
C.commit() -> C has state_C1, cached state state_C3
root.commit() -> C has state_C2, cached state state_C3
```
But if we take the spec more literally, `root.commit()` is where `P`'s state is applied, which means `C` should take on its cached state at _that_ moment, i.e. `state_C3` instead of `state_C2`.
Or perhaps `P.commit()` should be considered where `P`'s state is applied? (Because its pending state is _applied_ to its cached state)
Which one is correct?https://gitlab.freedesktop.org/wayland/wayland/-/issues/324Clarify on sub-surface `place_above`/`place_below`2024-03-10T09:58:38ZyshuiClarify on sub-surface `place_above`/`place_below`Quote:
> This state includes the sub-surface position relative to the parent surface (wl_subsurface.set_position), and the stacking order of the parent and its sub-surfaces (wl_subsurface.place_above and .place_below).
I read this as e...Quote:
> This state includes the sub-surface position relative to the parent surface (wl_subsurface.set_position), and the stacking order of the parent and its sub-surfaces (wl_subsurface.place_above and .place_below).
I read this as each surface has its own stack, which consists of itself and its immediate child sub-surfaces, is that correct? I find this ambiguous because the wording "parent and its sub-surfaces" can also mean "parent and all of its descendant", i.e. including grand-children, etc.
Also as a corollary, `.place_above` and `.place_below` moves the surface and its stack as a whole, is that right? Because otherwise the stacks can interleave which would break the assumption above.
(Example:
```
A
/ \
B C
|
D
```
initial stacking top to bottom: C, BD, A.
Call .place_above(C) on B, is the resulting stack:
1. BD, C, A; or
2. B, C, D, A?
)https://gitlab.freedesktop.org/wayland/wayland/-/issues/446Color format documentation2024-03-05T13:42:26ZJulian OrthColor format documentationAIUI, all client buffers must use SRGB with pre-multiplied alpha. A few questions:
- Is this documented anywhere in more detail?
- When a client has a straight linear RGB image, do they first convert the color channels to SRGB and then ...AIUI, all client buffers must use SRGB with pre-multiplied alpha. A few questions:
- Is this documented anywhere in more detail?
- When a client has a straight linear RGB image, do they first convert the color channels to SRGB and then pre-multiply or do they first pre-multiply and then convert the color channels to SRGB?
- Is there any way to do correct blending of these textures "in hardware", i.e., not manually in a shader? I tried to use VK_FORMAT_B8G8R8A8_SRGB but it seems that this format is not compatible with what KMS/clients expect. Is there a format that is compatible with this usecase or would this require a new extension?https://gitlab.freedesktop.org/wayland/wayland/-/issues/445Unable to achieve 240hz on my montior2024-02-24T09:17:22ZsjhaleprogrammerUnable to achieve 240hz on my montiorI've tried 3 different wayland compositors
Mutter,kwin, hyprland wlr
I have a display port 1.2 port that runs to a usb4 docking station with a displayport 1.4 port
On windows I'm able to achieve 240hz no problems
On wayland I can't g...I've tried 3 different wayland compositors
Mutter,kwin, hyprland wlr
I have a display port 1.2 port that runs to a usb4 docking station with a displayport 1.4 port
On windows I'm able to achieve 240hz no problems
On wayland I can't get 240hz and can only get 165hz
When switching to 240hz my screen goes black it reverts to the previous resolutionhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/233Reference wayland-server and standard desktop APIs2024-02-22T19:11:30ZArtem S. TashkinovReference wayland-server and standard desktop APIs1. As it currently stands all the Wayland compositors must implement (some of which are yet to be standardized):
* Screen recording and casting, remote desktop (VNC/RDP/etc.) and management (AnyDesk/TeamViewer/etc.)
* Querying of...1. As it currently stands all the Wayland compositors must implement (some of which are yet to be standardized):
* Screen recording and casting, remote desktop (VNC/RDP/etc.) and management (AnyDesk/TeamViewer/etc.)
* Querying of the mouse position, keyboard layout and LED state (CAPS/SCROLL/NUM), active window position or name, moving windows (`xdotool`, `wmctrl`)
* Global shortcuts
* System tray
* Input Method support/editor (IME)
* Graphical settings management (i.e. tools like `xranrd`)
* Fast user switching/multiple graphical sessions - with Wayland it becomes unclear whether it's the login manager or compositor task
* Session configuration including but not limited to 1) input devices 2) monitors configuration including refresh rate / resolution / scaling / rotation and power saving 3) global shortcuts
* HDR/deep color support
* VRR (variable refresh rate); the tear protocol for minimum latency in games
* Disabling input devices (`xinput` alternative)
* Absolute positioning for windows ([issue](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/72))
* Crash resistance (a Wayland compositor going down means all your apps crashing)
* Sending input to multiple applications at once
* Accessibility features
All these features and APIs are re-implemented again and again by all the Wayland compositors. The existing libraries e.g. `wlroots` or `libweston` only help so much. Why are we talking about such an extreme amount of duplication of work and code, and a ton of effort required to debug and make these features work reliably?
This all sounds like too high of a price to pay for ostensibly improved security guaranteed by Wayland. Not a single person however has provided a single proof of X.org's "insecurity" ever having been abused to gain unauthorized access to the user account. To abuse X.org's insecurity model you first need to be able to run applications within the user session and at least Linux users normally don't run random applications from the net.
2. As it currently stands the Wayland compositor cannot be reloaded or replaced on the fly without taking down all the running graphical applications. Qt has fixed the issue internally but every toolkit must implement it as well. Some applications, e.g. mpv, don't use any major toolkits such as GTK or Qt which means `mpv` will not survive a Wayland compositor crash, so not only toolkits must be compositor crash tolerant, everything running under Wayland must be as well. Would be great if the feature was in the protocol itself instead of delegating it to toolkits.
3. As it currently stands minor WMs and DEs do not even intend to support Wayland given the sheer complexity of writing all the code required to support the above features. You **do not** expect JWM, TWM, XDM or even IceWM developers to implement all the featured outlined in ^1.
4. Well-established competing desktop OS'es work exactly this way: a single display server and single window manager. In Linux there's a need for multiple window managers but a single reference Wayland server is still highly desired.
I wonder if Wayland developers could maybe consider writing a **reference Wayland server** which provided all these features and APIs and only required WMs and DEs to provide very simple window managers which drew window decorations and managed application windows, instead of implementing an entire display server along the way.https://gitlab.freedesktop.org/wayland/wayland/-/issues/444Cursor updates during drag and drop2024-02-21T08:38:47ZVlad ZahorodniiCursor updates during drag and dropAs agreed upon at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/wikis/meetings#2023-08-16-toplevel_drag, the compositor should send a `wl_pointer.leave` event to the source client, and `wl_data_device.enter` to the destinati...As agreed upon at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/wikis/meetings#2023-08-16-toplevel_drag, the compositor should send a `wl_pointer.leave` event to the source client, and `wl_data_device.enter` to the destination client.
However, this introduces issues with cursor updates. Many clients want to update the cursor during drag and drop. If the compositor sends a `wl_pointer.leave` event, `wl_pointer.set_cursor` requests will be ignored.
How much this issue is noticeable depends on the compositor. For example, kwin is going to reset the cursor image after sending `wl_pointer.leave` event, so the cursor is going to have the default cursor shape. Compositors that based their data device implementation on weston's one are less likely to be affected because
- they don't reset the cursor image after sending `wl_pointer.leave`
- and many clients set the same cursor surface but keep attaching new buffers instead, so it's possible to update the cursor even after sending `wl_pointer.leave`
With the `cursor-shape-v1` protocol, updating the cursor surface in such fashion will not be possible.
The data device interface needs either some clarifications or new requests to help with cursor updates. Whether the compositor can guess the right cursor shape is not clear because the visuals depend on what is being dragged, for example it can be a closed hand or pointing arrow (to indicate an insertion point, etc).https://gitlab.freedesktop.org/wayland/wayland/-/issues/439wl_surface::set_cursor with singleton cursor surface2024-02-21T07:06:14ZJulian Orthwl_surface::set_cursor with singleton cursor surfaceChromium uses the following code for setting the cursor:
```c
wl_surface_damage(pointer_surface_.get(), 0, 0, buffer_width, buffer_height);
// Note: should the offset be non-zero, use wl_surface_offset() to set it.
wl_surface_atta...Chromium uses the following code for setting the cursor:
```c
wl_surface_damage(pointer_surface_.get(), 0, 0, buffer_width, buffer_height);
// Note: should the offset be non-zero, use wl_surface_offset() to set it.
wl_surface_attach(pointer_surface_.get(), buffer, 0, 0);
wl_surface_commit(pointer_surface_.get());
wl_pointer_set_cursor(pointer_->wl_object(), pointer_enter_serial->value,
pointer_surface_.get(), hotspot_x_dip, hotspot_y_dip);
```
`pointer_surface_` is a singleton. There is only ever one such surface. If `pointer_enter_serial` is not the last enter serial sent to the application, then the spec requires that the call is ignored. However, it is unclear to me how to handle this correctly in the compositor.
Consider the case where `pointer_surface_` is _already_ the current cursor surface. Then the `commit` call will change the surface but not update the hotspot. If the compositor ignores the `set_cursor` call, then the hotspot will be incorrect.
Maybe the requirement that serial be the last enter serial should be removed? The other requirement, "The cursor actually changes only if the pointer focus for this device is one of the requesting client's surfaces or the surface parameter is the current pointer surface", seems sufficient.https://gitlab.freedesktop.org/wayland/wayland/-/issues/443Does our code suck or is there something we're not seeing? (Lutris, high DPI ...2024-02-19T13:12:39ZMathieu ComandonDoes our code suck or is there something we're not seeing? (Lutris, high DPI mouse)I maintain Lutris, which is written in Python and uses PyGObject. I have also recently switched to Wayland permanently and purchased a high DPI Razer gaming mouse. With those 2 factors combined, I started experiencing frequent crashes in...I maintain Lutris, which is written in Python and uses PyGObject. I have also recently switched to Wayland permanently and purchased a high DPI Razer gaming mouse. With those 2 factors combined, I started experiencing frequent crashes in Lutris while handling my library of ~1400 games.
After investigation, the cause of those crashes became pretty clear. Any blocking task run in the main thread could cause the application to crash. Not moving the mouse at all would prevent a crash. Moving the mouse really fast during a background operation would guarantee a crash.
From there on, our last release was mostly about finding those blocking operations and send them in a separate thread. This would prevent crashes on Wayland but it became apparent that we had a lot to deal with and Lutris 0.5.16 was shipped with a lot of possible causes of crashes.
During the development of the last release, there were some disagreements within the team. While I believed we should find and fix blocking operations, with the benefits of having a more responsive UI, Daniel argued that it is maybe not our responsibility to fix those crashes and catching all possible causes of crashes is a daunting task (it really is). After all, our UI was running fine on Xorg, without crashes.
It's also harder to get repros on those crashes, it's all a combo of using a high DPI mouse, a rather large Lutris library, some games on HDD which have a tendency to put themselves to sleep and running Wayland.
While I'm all for improving our codebase, I find this may be unwanted behavior and might get fixed in the future.
But with the existing installation base of Wayland in its current state, what's the best way to mitigate our crashes? I've been hesitant to use async / await, is this a possible solution?https://gitlab.freedesktop.org/wayland/wayland/-/issues/442Re-docking sub-windows isn't possible in Wayland, and switching from X11 to W...2024-02-15T20:19:21ZGhostCoder22Re-docking sub-windows isn't possible in Wayland, and switching from X11 to Wayland causes black screen due to SDDMI'm a relatively new Linux user having just switched from Windows 22H2 over to Fedora 39 KDE Desktop spin several months ago. My chosen Graphics Platform is Wayland. My problem is, Calibre's E-book Editor has the GUI option of undocking ...I'm a relatively new Linux user having just switched from Windows 22H2 over to Fedora 39 KDE Desktop spin several months ago. My chosen Graphics Platform is Wayland. My problem is, Calibre's E-book Editor has the GUI option of undocking two sub-window panes (which I accidentally did while exploring the application) and I cannot figure out how to re-dock them within Wayland. I tried switching to X11 to re-dock the undocked sub-windows, and even though I was successful in redocking the undocked sub-windows, they re-undock themselves after switching back to Wayland.
**About switching back and forth to and from Wayland and X11, there exists yet another problem:** _Even though I'm able to successfully switching from Wayland to X11, switching from X11 back to Wayland however requires a reboot otherwise the set SDDM causes the screen to go completely black which then requires me to force me to shutdown my laptop in order to reboot it._
Please fix these two issues. Thank you for your time.
As of this writing, my current system specs is as follows:
- Operating System: **Fedora Linux 39**
- KDE Plasma Version: **5.27.10**
- KDE Frameworks Version: **5.113.0**
- Qt Version: **5.15.12**
- Kernel Version: **6.7.4-200.fc39.x86_64 (64-bit)**
- Graphics Platform: **Wayland**
- Processors: **4 × Intel® Core™ i3-7100U CPU @ 2.40GHz**
- Memory: **15.4 GiB of RAM**
- Graphics Processor: **Mesa Intel® HD Graphics 620**
- Mesa version: **23.3.5**
I'm unable to find out what's the installed Wayland version is, unfortunately.