wayland issueshttps://gitlab.freedesktop.org/wayland/wayland/-/issues2022-07-05T07:54:55Zhttps://gitlab.freedesktop.org/wayland/wayland/-/issues/241Map shared memory from the client read-only2022-07-05T07:54:55ZDemi Marie Obenourdemiobenour@gmail.comMap shared memory from the client read-onlyClients may wish to share memory with the server that the server is not able to write, such as memory-mapped files the server does not have write permission for. Additionally, having the server be able to write to shared memory is a foo...Clients may wish to share memory with the server that the server is not able to write, such as memory-mapped files the server does not have write permission for. Additionally, having the server be able to write to shared memory is a footgun on the server side.https://gitlab.freedesktop.org/wayland/wayland/-/issues/243Reducing the number of objects doesn’t release all of the memory2021-10-08T17:04:09ZDemi Marie Obenourdemiobenour@gmail.comReducing the number of objects doesn’t release all of the memoryIf a client instantiates (say) $10^7$ objects, and then destroys all of them, the `wl_map` that stores the object list will not shrink. This can be fixed with a fancier data structure, such as an interval tree.If a client instantiates (say) $10^7$ objects, and then destroys all of them, the `wl_map` that stores the object list will not shrink. This can be fixed with a fancier data structure, such as an interval tree.https://gitlab.freedesktop.org/wayland/wayland/-/issues/245Proposal: require destructor events to be annotated2021-10-18T09:09:31ZDemi Marie Obenourdemiobenour@gmail.comProposal: require destructor events to be annotatedDestructor events can be annotated in the XML, but this is currently not required. By requiring destructor events to be annotated, several benefits ensue. These include, but are not limited to:
1. wayland-scanner can check that every ...Destructor events can be annotated in the XML, but this is currently not required. By requiring destructor events to be annotated, several benefits ensue. These include, but are not limited to:
1. wayland-scanner can check that every object has either a destructor request (named either “release” or “destroy”) or a destructor event (and no requests).
2. libwayland-server can detect more errors, such as destroying an object without either sending a destructor event or having received a destructor request.
3. Since an object can now be destroyed only by a destructor request or event on that object itself, it is possible for libwayland-client to automatically destroy objects created by events sent to zombie objects.https://gitlab.freedesktop.org/wayland/wayland/-/issues/246Proposal: Add a `destroy-with="request-name"` attribute for events that creat...2021-10-24T21:42:12ZDemi Marie Obenourdemiobenour@gmail.comProposal: Add a `destroy-with="request-name"` attribute for events that create objectsThis will allow libwayland-client to send destructor requests to objects created by events sent to zombies.This will allow libwayland-client to send destructor requests to objects created by events sent to zombies.https://gitlab.freedesktop.org/wayland/wayland/-/issues/247Notes for protocol-next design2023-03-19T22:58:12ZPekka Paalanenppaalanen@gmail.comNotes for protocol-next designThis is a random collection of ideas or more like open questions for the next major revision of Wayland protocol and libraries. The Wayland architecture for the graphics stack should remain as is.
**Disclaimer:**
> I probably cannot wor...This is a random collection of ideas or more like open questions for the next major revision of Wayland protocol and libraries. The Wayland architecture for the graphics stack should remain as is.
**Disclaimer:**
> I probably cannot work on this any more than filing this issue. I am also not sure doing this would be worth the effort either. There are no plans to work on this.
However, we should still collect a list of things that cannot be made nice without breaking libwayland ABI or Wayland protocol, just in case the pressure builds up high enough to make the work worthwhile. So here goes.
----
Let's call the next generation set of libraries and protocol Wayland 2.0.
- Wayland 2.0 must be able to co-exist with Wayland 1.0 in the same system and in the same compositor instance.
- Maybe Wayland 2.0 should have a different socket file name, so that clients can choose.
- Wayland 2.0 probably needs a new, independent set of libwayland libraries, so that we can drop all existing ABI we do not want to carry around, like the event loop API.
- Wayland 1.0 and Wayland 2.0 libraries must be able to co-exist and be used in the same process and thread.
- Wayland 2.0 should support 64-bit types on the wire. We already have use for them.
- Somehow, it should be easy to add Wayland 2.0 support in compositors and toolkits while keeping Wayland 1.0 support.
- For C language bindings, maybe keep the current design?
- Existing Wayland XML files need to usable with both Wayland 1.0 and Wayland 2.0. We do not want to duplicate those just for the sake of Wayland 2.0 when they are not specifically depending on Wayland 2.0 features like 64-bit types. We can require backward-compatible changes in XML files to make them Wayland 2.0 compatible, but they still need to work with Wayland 1.0.
- New XML files can be written to be Wayland 2.0 exclusive, to e.g. make use of new wire types.
- A new code generator.
- Do not special-case C language bindings, use the same low level API for all languages.
- Drop dependency to libffi. This means we need to generate more code for dispatch.
- Do not special-case `wayland.xml`. All user projects (compositors and toolkits/apps) need to use the code generator even for the core interfaces. This avoids exporting interface data symbols from the Wayland 2.0 libraries, which has been a bit of a pain with Wayland 1.0. We also get less special-cases to consider when augmenting the ABI later.
- Make sure user projects generate their Wayland code as private, to avoid accidental conflicts between binaries in a process.
- Make core protocol more symmetric.
- Make `delete_id` messaging fully symmetric.
- Fix the problems around server created protocol objects.
- Protocol errors still make sense to keep server→client only.
- Object id tracking rewrite.
- Eradicate zombies? Or at least make them fully symmetric.
- Replace `wl_map`?
- Aggressive id re-use? Limited new id allocation range like it is in Wayland 1.0?
- How to keep EGL and Vulkan WSI working?
- With independent libraries, you cannot just pass a Wayland 2.0 object to API that expects a Wayland 1.0 object.
- Inter-operating between Wayland 1.0 and Wayland 2.0 libraries is likely infeasible, certainly unwanted from implementation point of view.
- Passing objects from one library to the other inside a process.
- Using the same connection with both libraries.
- Having one library on one side of a connection and the other library on the other side of the connection.
- Negotiate root object version on connection.
- Is the equivalent of being able to version `wl_display` of Wayland 1.0.
- Still need to offer client API that does not block on connection initialization.
- Eventually, it should be possible to have a Wayland 2.0 -only system, assuming one does not need software that was not ported.https://gitlab.freedesktop.org/wayland/wayland/-/issues/248can't close client in client created listener2021-10-28T07:48:02ZSebastian Wickcan't close client in client created listenerIf the compositor runs into an error condition in a client created listener (`wl_display_add_client_created_listener`) it is not possible to call `wl_client_destroy` since the listeners are called from inside wl_client_create which in tu...If the compositor runs into an error condition in a client created listener (`wl_display_add_client_created_listener`) it is not possible to call `wl_client_destroy` since the listeners are called from inside wl_client_create which in turn would return a pointer to the already freed client memory.https://gitlab.freedesktop.org/wayland/wayland/-/issues/253Broken man pages containing C macros2021-11-11T12:51:31ZNicolai DagestadBroken man pages containing C macrosHi,
It the man pages for wl_array and wl_list both contain documentation on C macros, and from what I gathered it seems to be generating these pages from the header files by including the value of the macro. By doing this they add baslas...Hi,
It the man pages for wl_array and wl_list both contain documentation on C macros, and from what I gathered it seems to be generating these pages from the header files by including the value of the macro. By doing this they add baslashes ("\\") that escape the newline in the roff source.
I haven't understood exactly how the man pages are generated yet so this is reported as an issue instead of sending a patch fixing the problem, if somebody could point me in the right direction I'd be happy to try and fix it though 🙃
Attached screenshot of the current output and the expected one
![current](/uploads/d345b7b166eb79adb3fafb3071323f63/current.png)
![expected](/uploads/494b3eeb5cd344cd2d266f7d8e471b3b/expected.png)https://gitlab.freedesktop.org/wayland/wayland/-/issues/255Allow multiple wl_keyboards, wl_pointer, etc. under single wl_seat2022-10-27T08:23:43ZRoman GilgAllow multiple wl_keyboards, wl_pointer, etc. under single wl_seatThe current paradigm for input devices is that under one wl_seat all physical devices are grouped together to single wl_keyboard, wl_pointer, etc. instances.
This was meant as a simplification in comparison to the old X11 device handlin...The current paradigm for input devices is that under one wl_seat all physical devices are grouped together to single wl_keyboard, wl_pointer, etc. instances.
This was meant as a simplification in comparison to the old X11 device handling but has led to some issues. For example having multiple keyboards connected with different keymaps connected under a single wl_seat is in principle not possible. One can connect such and the compositor updates the keymap in between, but this breaks if keys are pressed simultaneously.
With !62 there is an attempt to solve this through logical keyboard groups, but it would be better to directly allow, maybe if not currently possible in a Wayland 2.0 version, compositors to create multiple wl_keyboards, etc. under a single seat and let clients handle the multiplexing.https://gitlab.freedesktop.org/wayland/wayland/-/issues/258avoid the wl_surface.frame callback mechanism for protocol-next2021-11-26T00:28:09ZSebastian Wickavoid the wl_surface.frame callback mechanism for protocol-nextThe frame callback mechanism is relatively unspecified and leaves a lot of room for different implementations. Different compositors send the callback event at different points in their refresh cycle which makes the timing of clients rat...The frame callback mechanism is relatively unspecified and leaves a lot of room for different implementations. Different compositors send the callback event at different points in their refresh cycle which makes the timing of clients rather unpredictable on different compositors. Some compositors try (have tried?) to dynamically adjust when the event is sent to reduce latency but some clients also try to reduce latency by adjusting their rendering relative to the frame callback event which results in a bad feedback loop.
On the next version replacing the frame callback mechanism with a better frame scheduling mechanism should be considered.https://gitlab.freedesktop.org/wayland/wayland/-/issues/259provide an atomic transaction primitive for all surface state in protocol-next2021-11-19T11:48:44ZSebastian Wickprovide an atomic transaction primitive for all surface state in protocol-nextThe way surface state propagates through a surface tree is slightly underspecified and not the most intuitive. Furthermore some use cases require committing multiple surface trees atomically (https://gitlab.freedesktop.org/wayland/waylan...The way surface state propagates through a surface tree is slightly underspecified and not the most intuitive. Furthermore some use cases require committing multiple surface trees atomically (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/26) which further complicates the logic.
For the next version surface commits could be removed. All (non-sub-)surfaces which should be committed together is instead added to a transaction object which, on commit, takes a snapshot of all (pending) state of all surface trees.https://gitlab.freedesktop.org/wayland/wayland/-/issues/260Auto-Type in login form2024-02-12T18:42:30ZXylleAuto-Type in login formHello,
since I switched to wayland the KeepassXC software can't fill in the forms automatically.
Before Wayland with the same version of gnome-shell, this software did its job very well.
After some research it appears that the problem c...Hello,
since I switched to wayland the KeepassXC software can't fill in the forms automatically.
Before Wayland with the same version of gnome-shell, this software did its job very well.
After some research it appears that the problem comes from wayland.
Considering the complexity of the passwords, this is a real setback in terms of security. For some software there are some workarounds but they are not optimal. For the rest of the software there is no solution.
Having a key combination that automatically fills in a login form is a real plus in terms of security. It is easy to define a password per site/software and of a more than correct complexity.
Could you implement a solution that would allow software such as KeepassXC to have access to the window title and to send keystrokes.
Sincerely Xyllehttps://gitlab.freedesktop.org/wayland/wayland/-/issues/266Clarifications around wl_surface.frame and opaque subsurfaces2023-11-25T00:19:22ZRobert MaderClarifications around wl_surface.frame and opaque subsurfacesThe spec says:
> A server should avoid signaling the frame callbacks if the surface is not visible in any way, e.g. the surface is off-screen, or completely obscured by other opaque surfaces.
If compositors implement this strictly (AFAI...The spec says:
> A server should avoid signaling the frame callbacks if the surface is not visible in any way, e.g. the surface is off-screen, or completely obscured by other opaque surfaces.
If compositors implement this strictly (AFAIK only Mutter does ATM), clients using subsurfaces to build an UI have a hard time using `wl_surface.frame`, as they often need to request a frame for every (partly) opaque subsurface individually.
Consider e.g. a client that use subsurfaces as overlays - examples here are Firefox and the Gstreamer Wayland sink - and has a big parent surface that is supposed to handle input. `wl_surface.set_input_region()` provides a decent way to make the subsurfaces not consume input events. The same unfortunately is not true for `wl_surface.frame`. If the client wants a single source for frame callbacks, it can not just request them on the parent surface, as each opaque subsurface may block them.
GTK3 now has a workaround for such issues, allowing multiple callbacks to be requested via `gdk_wayland_window_add_frame_callback_surface()`. This however adds overhead and complexity both in the application and the compositor[^1].
I wonder if we can find a more elegant solution for this problem. The most obvious solutions that came to my mind so far came are:
1. Change the core spec to state that surfaces occluded by descendant subsurfaces should still receive callbacks.
2. Add a new protocol that allows to make "recursive" callbacks in some way.
I'd happily work on 2. if that's deemed the best solution, but first wanted to hear opinions if a core spec change is not more straight forward (or other ideas come up). So - I'd be supper happy about comments :)
CC: @jadahl, @pq, @daniels, @emersion, @zzag
---
[^1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1735494https://gitlab.freedesktop.org/wayland/wayland/-/issues/267Clarify wl_surface.damage[_buffer] behavior when no buffer is attached2022-01-21T01:26:10ZRobert MaderClarify wl_surface.damage[_buffer] behavior when no buffer is attachedCertain clients currently call `wl_surface_damage_buffer()` even if no buffer is attached - i.e. neither a new one, nor one that is still hold by the compositor.
Strictly speaking, right now the call only makes sense if a buffer is pend...Certain clients currently call `wl_surface_damage_buffer()` even if no buffer is attached - i.e. neither a new one, nor one that is still hold by the compositor.
Strictly speaking, right now the call only makes sense if a buffer is pending:
> This request is used to describe the regions where the pending buffer is different from the current surface contents
In Mutter we currently print a error to the journal but don't inform the client that this is arguably invalid behavior. I think we should clarify this situation by either:
1. adding a new `wl_surface.error` for this case
2. explicitly allowing it and
1. requiring compositors to ignore the call in this case
2. requiring compositors to repaint the damaged region on screen
AFAIK there's only one use-case where 2.2. is actually useful: when using shm-buffer in combination with `wp_viewporter.src_rect`. In this case a client may change the `src_rect.[x.y]`, changing what should be displayed on screen while neither changing the buffer content nor surface size, likely not triggering a repaint. There *are* scenarios where this could be useful, but arguably such highly optimized clients shouldn't use shm-buffers in the first place *and* we could require compositors to update the surface area in such cases (arguably this is already the case).
Opinions?https://gitlab.freedesktop.org/wayland/wayland/-/issues/273[Feature request] Add support to wl_keyboard for wayland to send xkb RMLVO tu...2022-01-17T04:40:27ZWeng Xuetian[Feature request] Add support to wl_keyboard for wayland to send xkb RMLVO tuple.The use case this is intended for input method.
In input method, one use case that we want to use the layout/variant specified by user, re-use xkb options from the system. Right now we only have keymap fd which only contains some raw da...The use case this is intended for input method.
In input method, one use case that we want to use the layout/variant specified by user, re-use xkb options from the system. Right now we only have keymap fd which only contains some raw data. It would ideal to have the same thing like _XKB_RULES_NAMES under X11.
zwp_input_method_v1 is reusing wl_keyboard interface; zwp_input_method_v2 in the wild is following the interface of wl_keyboard. So I'd like to have the support in wl_keyboard first.https://gitlab.freedesktop.org/wayland/wayland/-/issues/274Add 'float' wire data type?2023-10-31T09:09:12ZPekka Paalanenppaalanen@gmail.comAdd 'float' wire data type?I started thinking, what would it take to add a floating point data type to the argument types on the wire, and it seems doable for 32-bit float.
Let's say we add float support in libwayland version 1.k. It needs to be recognized in XML...I started thinking, what would it take to add a floating point data type to the argument types on the wire, and it seems doable for 32-bit float.
Let's say we add float support in libwayland version 1.k. It needs to be recognized in XML and emitted by scanner. It needs a new message signature character. It needs to be added in `union wl_argument`. That's all?
The reason we cannot add any 64-bit types (easily) is that on 32-bit architectures, they would change the size of `union wl_argument`.
The float type could be used in new protocol extensions. Adding it to existing protocol extensions would be discouraged, because it means that an extension that used to be buildable with wayland-scanner version < 1.k no longer builds. IOW, you cannot upgrade wayland-protocols without upgrading libwayland - although, is that something we want to explicitly support? For scanners for other languages, I think adding `float` to an existing extension would be disruptive.
Obviously both server and client libwayland on the two sides of a Wayland connection must both support `float` for it to work. Ensuring this is simple:
- If client uses an old libwayland, it cannot use an extension needing `float`, so never binds it.
- If server uses an old libwayland, it will not advertise an extension needing `float`.
Furthermore, it doesn't matter if wayland-protocols gets *new* extensions using `float`. All users of existing extensions can just keep on using old libwayland, since they never attempt to build new extensions needing `float`.
A project that uses an extension that need `float` will strictly require libwayland version >= 1.k. It cannot be built with an older version, and after building it cannot be run with an older version. But I think we already assume that you won't run with an older libwayland that what scanner you used for building.
A user for `float` types could obviously be wayland/wayland-protocols!14, but we can also work around the lack of float with integers too.
----
What do you think of extending wire types like this?
Would you have use for `float` on the wire?https://gitlab.freedesktop.org/wayland/wayland/-/issues/276Attaching wl_data_source multiple times concurrently2022-02-12T08:23:18ZJulian OrthAttaching wl_data_source multiple times concurrentlySome applications, such as those based on GDK, require `wl_data_source::cancelled` to be sent to them to recognize that a received `wl_data_offer` was created by another client. If they don't receive `wl_data_source::cancelled` after att...Some applications, such as those based on GDK, require `wl_data_source::cancelled` to be sent to them to recognize that a received `wl_data_offer` was created by another client. If they don't receive `wl_data_source::cancelled` after attaching a `wl_data_source` to a seat, they will never call `wl_data_offer::receive` because they assume that the data offer refers to their own `wl_data_source`.
Therefore sending `wl_data_source::cancelled` is required. However I could not find any language in the spec explaining when exactly this event should be sent. The spec does not prohibit clients from attaching one data source for multiple purposes at the same time, e.g., attaching them to multiple seats or for both DnD and selection. Should `cancelled` be sent as soon as at least one of these attachments gets replaced? If so then what is the behavior of the other attachments?https://gitlab.freedesktop.org/wayland/wayland/-/issues/278Clarification on `axis_discrete` specification2022-02-13T23:57:20ZMax XiongClarification on `axis_discrete` specificationThe axis_discrete specification for wl_pointer contains this sentence:
> Note that the protocol allows for other events to occur between the axis_discrete and its coupled axis event, including other axis_discrete or axis events.
Can any...The axis_discrete specification for wl_pointer contains this sentence:
> Note that the protocol allows for other events to occur between the axis_discrete and its coupled axis event, including other axis_discrete or axis events.
Can any of the other events use the same axis as the first event? If they do how does one pair the events?https://gitlab.freedesktop.org/wayland/wayland/-/issues/280Clarification on wl_pointer.leave and currently held buttons2023-05-23T09:55:33ZDavid EdmundsonClarification on wl_pointer.leave and currently held buttonsIn the wl_keyboard protocol it explicitly says when we get a wl_keyboard.leave event "the client should assume all keys are lifted."
wl_pointer has no matching statement for button state.
---
The reason it came up is right now in Qt cl...In the wl_keyboard protocol it explicitly says when we get a wl_keyboard.leave event "the client should assume all keys are lifted."
wl_pointer has no matching statement for button state.
---
The reason it came up is right now in Qt clients we do clear up pressed buttons on pointer leave.
This causes us a minor user-facing bug that it's an apparently established X11 practice to right click hold, open a context menu, then select the entry when the mouse on release. This is broken with the above behaviour.
However not resetting the button state on wl_pointer.leave would cause us bigger issues if a compositor doesn't clean up button state explicitly when leaving.
However we want it to work would benefit from a spec clarification.https://gitlab.freedesktop.org/wayland/wayland/-/issues/281scanner: more convenient callbacks2022-03-09T09:21:39ZSimon Sercontact@emersion.frscanner: more convenient callbacksI'm not sure this is worth fixing, just opening an issue in the spirit of #247.
Right now the generated callback function signatures aren't very convenient to use. Some parameters aren't really necessary, and including them makes it so ...I'm not sure this is worth fixing, just opening an issue in the spirit of #247.
Right now the generated callback function signatures aren't very convenient to use. Some parameters aren't really necessary, and including them makes it so the argument lists are longer, easy to get wrong and less readable.
### Server-side
```c
struct wl_display_interface {
void (*sync)(struct wl_client *client,
struct wl_resource *resource,
uint32_t callback);
};
// could be
struct wl_display_interface {
void (*sync)(struct wl_resource *resource,
uint32_t callback);
};
```
Because `client = wl_resource_get_client(resource)`.
### Client-side
```c
struct wl_display_listener {
void (*error)(void *data,
struct wl_display *wl_display,
void *object_id,
uint32_t code,
const char *message);
};
// could be
struct wl_display_listener {
void (*error)(struct wl_display *wl_display,
void *object_id,
uint32_t code,
const char *message);
};
```
Because `void *data = wl_proxy_get_user_data(wl_display)`.https://gitlab.freedesktop.org/wayland/wayland/-/issues/283server: global filter not taken into account when creating/destroying globals2022-03-23T09:29:43ZSimon Sercontact@emersion.frserver: global filter not taken into account when creating/destroying globalsRef https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/148:
> if a client connects and binds a registry, and then the server adds a global afterwards, the client will always get a `wl_registry.global` message for it even if...Ref https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/148:
> if a client connects and binds a registry, and then the server adds a global afterwards, the client will always get a `wl_registry.global` message for it even if binding that global would result in failure.