wayland issueshttps://gitlab.freedesktop.org/wayland/wayland/-/issues2023-02-16T11:12:13Zhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/350Clarify interactions between wl_surface.leave and wl_output destruction2023-02-16T11:12:13ZSimon Sercontact@emersion.frClarify interactions between wl_surface.leave and wl_output destructionIn this situation:
- Client creates and maps a `wl_surface`
- Compositor sends `wl_surface.enter` with an output
- Compositor removes the `wl_output` global
Currently wlroots doesn't send `wl_surface.leave` events. Some other composito...In this situation:
- Client creates and maps a `wl_surface`
- Compositor sends `wl_surface.enter` with an output
- Compositor removes the `wl_output` global
Currently wlroots doesn't send `wl_surface.leave` events. Some other compositors do (Mutter, KWin). This surprises some client authors: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3559.
We should document whether this is something clients need to handle.https://gitlab.freedesktop.org/wayland/wayland/-/issues/349Wayland server hangs with endless repeated `failed to accept: Bad file descri...2023-02-02T14:08:49ZTwaik YontWayland server hangs with endless repeated `failed to accept: Bad file descriptor` message.Hi. I am pretty sure problem is somewhere [here](https://gitlab.freedesktop.org/wayland/wayland/-/blob/83e9c9e117acdf104a9d33838d99a4025a647dfe/src/wayland-server.c#L1536-1554). For some reason socket is not abandoned when `EABDF` error ...Hi. I am pretty sure problem is somewhere [here](https://gitlab.freedesktop.org/wayland/wayland/-/blob/83e9c9e117acdf104a9d33838d99a4025a647dfe/src/wayland-server.c#L1536-1554). For some reason socket is not abandoned when `EABDF` error is received, it simply returns 1 to recheck faulty socket. And this endless loop is a reason of server hanging with `failed to accept: Bad file descriptor` message in stderr... When I am trying to connect to this faulty socket with Xwayland I am getting this...
```
[747907.273] -> wl_display@1.get_registry(new id wl_registry@2)
[747907.317] -> wl_display@1.sync(new id wl_callback@3)
^Ccould not connect to wayland server
(EE)
Fatal server error:
(EE) Couldn't add screen
(EE)
```
Thank you guys, you are best.https://gitlab.freedesktop.org/wayland/wayland/-/issues/348Differences in axis values between compositors2023-01-25T16:30:04ZXaver HuglDifferences in axis values between compositorsSome compositors send an axis value of 10 (Mutter, Weston) per discrete step due to historical reasons and others send the scroll value from libinput (KWin, Sway), which is usually (or always?) 15. Partially because of this, many if not ...Some compositors send an axis value of 10 (Mutter, Weston) per discrete step due to historical reasons and others send the scroll value from libinput (KWin, Sway), which is usually (or always?) 15. Partially because of this, many if not all clients completely ignore the axis value the compositor sends for `axis_source=wheel`.
Now this is a problem mostly once a compositor wants to adjust the scroll speed - KWin has that functionality for example, and it works by simply multiplying the axis value by some factor specified by the user... but it doesn't really work that well. Some clients completely ignore the axis value for discrete scroll events (Qt, SDL), others apply it but have a much higher base scroll speed than on other compositors (GTK).
Now the question is: how can this be resolved? The options I see are:
- Mutter and Weston adopt the libinput scroll value, or KWin and Sway adopt the workaround of sending an axis value of 10 per discrete step. This isn't necessarily that great, as clients don't know if a compositor has adjusted to the 'correct' behavior
- specify one of the behaviors and add a version bump, so that clients can adopt accordingly
- add a completely new event without the historical baggage. As an idea, a `axis_pixels` event that specifies a scroll distance in pixels would provide both a fix for the inconsistency between compositors and help provide consistent scroll speeds between apps. I know that at least in Qt there is a matching API for that
Related: #87https://gitlab.freedesktop.org/wayland/wayland/-/issues/342Clarify on commit ordering vs. actually carrying out the update2022-12-20T12:00:56ZNils EmmerichClarify on commit ordering vs. actually carrying out the updateIt was unclear to me if it is allowed to delay and change the order of the actual update of a surface with respect to the commit ordering of unrelated surfaces.
A compositor might want to delay the surface updates until the attached buf...It was unclear to me if it is allowed to delay and change the order of the actual update of a surface with respect to the commit ordering of unrelated surfaces.
A compositor might want to delay the surface updates until the attached buffer is ready to be used to prevent frame misses.
To minimize the effects of this delay on other clients, the time when unrelated surfaces visibly update might change from the order in which the surface states were committed.
Here surfaces are unrelated if they are not updated atomically together, such as synchronized subsurfaces or through the [transactions_v1](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26) protocol.
The reordering could be observable with a screenshot extension or to the user.
Therefore, this seems like a protocol violation as requests are ordered, and commits don't allow such delayed updates with reorders. At least, this is how I interpreted the docs.
However, compositors like Mutter already implement such behavior through [MR](https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880). It seems reasonable to allow this and add some clarification to `wl_surface.commit` that updates can be delayed and reordered for unrelated surfaces.https://gitlab.freedesktop.org/wayland/wayland/-/issues/341Inconsistent description between wl_data_offer.source_actions and wl_data_sou...2022-12-12T12:26:25ZDavid RedondoInconsistent description between wl_data_offer.source_actions and wl_data_source.set_actions`wl_data_source.set_actions` says
>**This request must be made once only**, and can only be made on sources
used in drag-and-drop, so it must be performed before
wl_data_device.start_drag.
`wl_data_offer.source_actions`says
>This ev...`wl_data_source.set_actions` says
>**This request must be made once only**, and can only be made on sources
used in drag-and-drop, so it must be performed before
wl_data_device.start_drag.
`wl_data_offer.source_actions`says
>This event indicates the actions offered by the data source. It
will be sent right after wl_data_device.enter, or **anytime the source
side changes its offered actions through wl_data_source.set_actions.**https://gitlab.freedesktop.org/wayland/wayland/-/issues/338Stride constraints for wl_shm_pool::create_buffer2022-11-24T02:06:54ZM. StoecklStride constraints for wl_shm_pool::create_bufferThe current text for `wl_shm_pool::create_buffer` defines the image stride as follows:
> The stride argument specifies the number of bytes from the beginning of one row to the beginning of the next.
`wl_shm` also has an invalid stride...The current text for `wl_shm_pool::create_buffer` defines the image stride as follows:
> The stride argument specifies the number of bytes from the beginning of one row to the beginning of the next.
`wl_shm` also has an invalid stride error, with name="invalid_stride", summary="invalid size or stride during pool or buffer creation".
However, it is not specified what stride values are invalid. To ensure that applications can rely on the same behavior across compositors, this should be standardized and documented.
In theory, we could allow _any_ stride value, as long as the union of the content bytes of the image lies within the shm pool region. By the definition of the stride quoted above, if the first row of the image starts at address `p`, then the second row of the image starts at `p + stride`. This is well defined even if the stride is zero, negative, or smaller in absolute value than `width * bpp` -- although not necessarily useful.
Some common constraints in practice:
* libwayland-shm requires the stride (in bytes) to be at least the image width (in pixels)
* wlroots/wlr-shm currently requires that the stride to be a multiple of `bpp`, the number of bytes for a pixel
* pixman (and cairo) require that the stride be a multiple of 4.
* libwayland-shm requires that the image row padding also fits in the pool; i.e., `offset+stride*height<pool_size`, which can be more than necessary if, say, `height=1` and `stride > width*bpp`
See also https://gitlab.freedesktop.org/wayland/wayland/-/issues/333 for related issues specifying multi-planar and subsampled formats.https://gitlab.freedesktop.org/wayland/wayland/-/issues/336scanner: check local enums2022-11-07T07:10:56ZSimon Sercontact@emersion.frscanner: check local enumsIf the enum isn't namespaced (doesn't contain `.`), check that it exists.
Ref https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/174If the enum isn't namespaced (doesn't contain `.`), check that it exists.
Ref https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/174https://gitlab.freedesktop.org/wayland/wayland/-/issues/335Privileged wayland sockets2022-11-08T15:45:52ZJulian OrthPrivileged wayland socketsWe already have several protocols (e.g. xwayland-only protocols) that must not be exposed to unprivileged clients. I expect this number to rise in the future with at least ext-screencopy and ext-layer-shell becoming privileged protocols....We already have several protocols (e.g. xwayland-only protocols) that must not be exposed to unprivileged clients. I expect this number to rise in the future with at least ext-screencopy and ext-layer-shell becoming privileged protocols.
One way to separate unprivileged and privileged sockets is via the file system. Sandboxes only expose selected sockets in $XDG_RUNTIME_DIR to sandboxed applications. A wayland compositor can therefore create a socket called wayland-N.privileged which exposes even privileged protocols.
If such a schema was standardized, then clients that make use of such privileged protocols (e.g. screenshot tools, application launchers) could try to connect to the privileged socket. This would allow users to launch them without having to jump through compositor-specific hoops to launch them with elevated privileges.https://gitlab.freedesktop.org/wayland/wayland/-/issues/334Introduce a proper role object for cursor surfaces2022-11-15T11:36:15ZSimon Sercontact@emersion.frIntroduce a proper role object for cursor surfacesRight now cursors are a bit special: they're set via `wl_pointer.set_cursor` and take a raw `wl_surface`. This is inconsistent with all other roles. This makes it difficult to update the offset, or to update the offset and the image atom...Right now cursors are a bit special: they're set via `wl_pointer.set_cursor` and take a raw `wl_surface`. This is inconsistent with all other roles. This makes it difficult to update the offset, or to update the offset and the image atomically. Updating the offset is possible via `wl_surface.offset`, but it's annoying because it's relative to the previous offset.
Additionally, cursors are not extensible. There's no easy way to refer to an existing cursor. There could be a new protocol to set a cursor by an image name, but with the status quo it'd need to hand-roll an input type (pointer/tablet/etc) enum.https://gitlab.freedesktop.org/wayland/wayland/-/issues/333Define semantics of `wl_shm` with tiled or multi-plane formats2022-11-24T09:54:01ZDemi Marie Obenourdemiobenour@gmail.comDefine semantics of `wl_shm` with tiled or multi-plane formatsThe semantics of `wl_shm` with tiled or multi-plane formats are not clear. In particular, I am not aware of any document specifying how to handle sizes that are not a multiple of the subsampling quantum.
Edit:
- As per <https://gitlab...The semantics of `wl_shm` with tiled or multi-plane formats are not clear. In particular, I am not aware of any document specifying how to handle sizes that are not a multiple of the subsampling quantum.
Edit:
- As per <https://gitlab.freedesktop.org/wayland/wayland/-/issues/333#note_1619508>, tiled formats are _never_ valid.
- Is the same true of formats that require a non-linear modifier?https://gitlab.freedesktop.org/wayland/wayland/-/issues/332WAYLAND_DEBUG logging doesn't include arrays' contents2022-11-02T12:21:43ZDmitry BatrakWAYLAND_DEBUG logging doesn't include arrays' contentsCurrently, only array size is logged by the protocol logger. For completeness, it would be good to include the contents of arrays. As the structure of the contents isn't enforced by the protocol, it can be logged as a sequence of byte va...Currently, only array size is logged by the protocol logger. For completeness, it would be good to include the contents of arrays. As the structure of the contents isn't enforced by the protocol, it can be logged as a sequence of byte values.
I can submit a merge request, solving this issue, if the idea is acceptable.https://gitlab.freedesktop.org/wayland/wayland/-/issues/331Clarify protocol error raise in wl_data_device.start_drag2022-10-19T08:04:50ZGrayson GuarinoClarify protocol error raise in wl_data_device.start_dragThe protocol states: `If the icon surface already has another role, it raises a protocol error` without specifying which protocol error should be raised.The protocol states: `If the icon surface already has another role, it raises a protocol error` without specifying which protocol error should be raised.https://gitlab.freedesktop.org/wayland/wayland/-/issues/330atomic keyboard focus changes2023-07-06T18:46:21ZMatthias Clasenatomic keyboard focus changesIn GTK, I've recently run into the following situation:
A popover is opened from a toplevel window, containing an editable label.
The user clicks on the editable label to start editing, and the label goes into
editing mode for a split s...In GTK, I've recently run into the following situation:
A popover is opened from a toplevel window, containing an editable label.
The user clicks on the editable label to start editing, and the label goes into
editing mode for a split second, but reverts right back. The next click succeeds.
What it happening here protocol-wise is that clicking on the popup generates the
following events:
1) button press on the popup
2) keyboard leave on the toplevel
3) keyboard enter on the popup
GTK handles the button press to switch the editing label to editing mode.
Then focus leaves the popover, due to the keyboard leave, which causes the editing
mode to be canceled.
Then focus comes back to the editable label due to the keyboard enter, but it is
too late, we are no longer in editing mode.
In discussion of this sequence with garnacho and jadahl, it was suggested that it
would be great if the keyboard leave/enter events were paired somehow, so GTK can
know that the keyboard is just moving between two of its surfaces, instead of leaving
for good.
Ways to achieve that could be:
- Add a target surface ID to the leave event
- Add a 'keyboard frame' and guarantee that such leave/enter pairs are emitted within a keyboard frame
If the keyboard leaves to a different client, we'd see a keyboard frame-begin, keyboard leave, keyboard frame-end sequence, which tells us that the keyboard has moved elsewhere.https://gitlab.freedesktop.org/wayland/wayland/-/issues/329Question: Can EDID (for example) information be added to wl_output?2022-10-13T12:52:13ZAndrew MarshallQuestion: Can EDID (for example) information be added to wl_output?There was some discussion in https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/109 regarding providing a means to uniquely (and persistently) identify an output, but I don't know if there was any further work done.
Basical...There was some discussion in https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/109 regarding providing a means to uniquely (and persistently) identify an output, but I don't know if there was any further work done.
Basically I'm interested in exposing either a serial number (or the entire EDID) so that applications can use this information to uniquely identify an output. The EDID is particularly useful as it can be used to extract extended display information from, for example, DRM (such as the specific display connections, Display Port information etc which is available under XRandR)
I know that the "KDE output device" protocol provides EDID information and wondered if there was any interest in adding it to wl_output.
Essentially my goal is to have this information available to a Gtk application running on Weston - I can of course fork my own copy of weston but am unsure of where to look to implement a protocol.
Any pointers appreciated - thanks.https://gitlab.freedesktop.org/wayland/wayland/-/issues/327Clarify if request/event carry an immediate response or not2022-10-09T23:13:16ZMark Bolhuismark@bolhuis.devClarify if request/event carry an immediate response or notA few days ago I asked on the IRC why the wl_callback.done event from a wl_display.sync request was returned earlier than the xdg_surface.configure event from an initial wl_surface.commit request, even though the commit request was sent ...A few days ago I asked on the IRC why the wl_callback.done event from a wl_display.sync request was returned earlier than the xdg_surface.configure event from an initial wl_surface.commit request, even though the commit request was sent first.
From talking to kennylivensen it seems that some events are sent immediately and some are only scheduled for later.
For example the wl_registry.global events must be sent immediate which means that if you call wl_display.sync after binding to the registry then the resulting wl_callback.done event must sent by the compositor after all the initial wl_registry.global events.
The spec does not state which responses must be sent immediately such that the done event from a subsequent sync request is sent afterwards, or which events are only scheduled for the future, and thus are sent out of order from a sync request.
wl_display.sync
```
The sync request asks the server to emit the 'done' event on the returned wl_callback object. Since requests are handled in-order and events are delivered in-order, this can be used as a barrier to ensure all previous requests and the resulting events have been handled.
```
wl_registry
```
When a client creates a registry object, the registry object will emit a global event for each global currently in the registry. Globals come and go as a result of device or monitor hotplugs, reconfiguration or other events, and the registry will send out global and global_remove events to keep the client up to date with the changes. To mark the end of the initial burst of events, the client can use the wl_display.sync request immediately after calling wl_display.get_registry.
```
xdg_surface
```
After creating a role-specific object and setting it up, the client must perform an initial commit without any buffer attached. The compositor will reply with an xdg_surface.configure event. The client must acknowledge it and is then allowed to attach a buffer to map the surface.
```
There is nothing in these descriptions that would suggest that wl_registry.global events are sent immediately, and that xdg_surface.configure isn't.
The mention of wl_display.sync for wl_registry is only a suggestion but from reading the rest one would think that the same logic applies to xdg_surface.
----------------------
I'm opening this issue to discuss what appropriate wording changes are needed to clarify this behavior.
There are certain words and phrases that are ambiguous:
- Handled in-order: With respect to what? The order the client sends them to the server?
- Delivered in-order: Again with respect to what? The requests that carry a reply, or to the order they are read from the fd? Also what does deliver mean here? Does it mean the client has called the event handler for that event?
- Emit/Send: Are these synonyms? And send when?
I'm proposing the use of new words that carry strict definitions:
Some of these words are already used in the spec.
- Response/Reply: Both mean the same thing. An event that is required to be sent after a request from the client, or visa versa.
- Schedule: The client/server will respond sometime in the future, and therefore the response will be out of order with respect to the order the client/server sent requests/events that carry a response.
- Immediately: The client/server will respond immediately upon receiving the request. This means that a call to wl_display.sync immediately following a request that carries an immediate reply ensures that the wl_callback.done event is sent by the compositor afterwards.
These words must be used in the descriptions of every request/event that carries a response.
----------------------
See also:
- [GLFW](https://github.com/glfw/glfw/commit/f2617a671f7003a57a52e6f84afc6903e0a824f6)https://gitlab.freedesktop.org/wayland/wayland/-/issues/326Accessibility for Active Focus (aka wm_class name)2022-10-01T00:12:54ZBen ReavesAccessibility for Active Focus (aka wm_class name)I am a contributor to a dynamic key remapper under x11, xkeysnail & more recently forked into keyszer, that can detect the actively focused application via x11's wm_class name property and then allows for the remapping of hotkey combos t...I am a contributor to a dynamic key remapper under x11, xkeysnail & more recently forked into keyszer, that can detect the actively focused application via x11's wm_class name property and then allows for the remapping of hotkey combos to other hotkey combos a user may want or need. I also believe other popular applications such as autokey may do similar things and that this would be a very important accessibility feature handicapped individuals and people that may need or want to use exotic/rare keyboard input devices for whatever reason.
What would be the best way to integrate something like this into Wayland or submit a proper proposal?
This issue is also discussed extensively here as well.
https://github.com/flatpak/xdg-desktop-portal/issues/304
My kinto app can be found here https://github.com/rbreaves/kinto/ .https://gitlab.freedesktop.org/wayland/wayland/-/issues/325Clarify what kind of coordinate systems are used in some places.2022-09-27T11:37:14ZyshuiClarify what kind of coordinate systems are used in some places.I think the wayland core protocol does not specify any of the coordinate systems it uses. I was told surface-local coordinates are top-left (i.e. X to the left, Y down, origin at top-left), but I think not everybody is clear on that fact...I think the wayland core protocol does not specify any of the coordinate systems it uses. I was told surface-local coordinates are top-left (i.e. X to the left, Y down, origin at top-left), but I think not everybody is clear on that fact.
Can we explicitly state this in the spec?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/323wl_data_device.leave after wl_data_device.drop2022-09-23T08:42:27ZVlad Zahorodniiwl_data_device.leave after wl_data_device.dropMany compositors send `wl_data_device.leave` after `wl_data_device.drop`, but on the other hand, `wl_data_device.leave`'s docs state that you should destroy the data offer if you receive that event
```xml
<event name="leave">
...Many compositors send `wl_data_device.leave` after `wl_data_device.drop`, but on the other hand, `wl_data_device.leave`'s docs state that you should destroy the data offer if you receive that event
```xml
<event name="leave">
<description summary="end drag-and-drop session">
This event is sent when the drag-and-drop pointer leaves the
surface and the session ends. The client must destroy the
wl_data_offer introduced at enter time at this point.
</description>
</event>
```
This has a conflict with `wl_data_offer.finish`. The client may not be able to finish drag-and-drop operation in a timely manner after receiving `wl_data_device.drop`.https://gitlab.freedesktop.org/wayland/wayland/-/issues/321Support specific XCURSORPATH or search XDG_DATA_DIRS2022-09-13T00:21:35ZcatsoutSupport specific XCURSORPATH or search XDG_DATA_DIRSCurrently there is no method to change the hardcode XCURSORPATH.
However, when using with some complex systems(such as flatpak/snap/nix), it may be needed.
We should support XDG_DATA_DIRS which is described in [XDG Base Directory Spe...Currently there is no method to change the hardcode XCURSORPATH.
However, when using with some complex systems(such as flatpak/snap/nix), it may be needed.
We should support XDG_DATA_DIRS which is described in [XDG Base Directory Specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html), or at least supports specific XCURSORPATH when compiling.
Related:
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1484
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/192
https://github.com/alacritty/alacritty/issues/4371
https://github.com/flatpak/flatpak/commit/ad87b12264e2795c27a2a4da496b2e3c719767e1