wayland issueshttps://gitlab.freedesktop.org/wayland/wayland/-/issues2023-03-19T22:58:12Zhttps://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/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/291Introduce concept of "capability" globals for protocol next2022-04-28T05:33:07Zi509VCBIntroduce concept of "capability" globals for protocol nextGlobals in the wayland protocol can be classed into two groups: "capability" style globals, these are available for the entire lifetime of the connection, such as wl_shm. "dynamic" or "hotpluggable" globals, these may pop in and out as d...Globals in the wayland protocol can be classed into two groups: "capability" style globals, these are available for the entire lifetime of the connection, such as wl_shm. "dynamic" or "hotpluggable" globals, these may pop in and out as device state changes, such as wl_seat.
The capability style globals may be taken away by the server by disabling the global, but this leaves clients in an awkward spot. Clients either choose to overengineer some solution to handle capability style globals vanishing or just flat out ignore destruction of globals like wl_shm.
My proposal is to make the idea of a "capability global" a first class part of the protocol. Capability globals would be garunteed to be present for the lifetime of the connection and servers may not remove capability globals.
Regarding specifics there needs to be discussion how to integrate capability globals into the 2.0 protocol.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/98Wire format header does not describe number of file descriptors per message2021-10-07T13:54:15ZM. StoecklWire format header does not describe number of file descriptors per messageThe Wayland [wire format header](https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Wire-Format) provides a field for the message length in bytes, but does not provide a field for the number of file descriptors that is con...The Wayland [wire format header](https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Wire-Format) provides a field for the message length in bytes, but does not provide a field for the number of file descriptors that is consumed.
Because clients must fully parse the incoming protocol to match the file descriptors that are provided with corresponding messages, an [inventive solution](https://gitlab.freedesktop.org/wayland/wayland/commit/4485ed1f59cb8695f3ab690e074abd7e79a27640) in libwayland-client is needed to ensure that clients can parse even messages sent to objects that have been deleted by the client, but not yet acknowledged as deleted by the server. If the wire format would describe the number of file descriptors used per message, then libwayland-client could more easily close all file descriptors corresponding to unknown messages.
(I'm adding this issue because it's something to keep in mind in case the wire format ever has some other reason for a change; one may as well solve two problems at once then. It's also an issue for anyone writing their own code to manipulate the Wayland protocol. As noted in the comments of ["The Wayland Zombie Apocalypse is Near"](
https://web.archive.org/web/20180320133849/blogs.s-osg.org/wayland-zombie-apocalypse-near/
), wire format and core semantic changes should definitely *not* be made without consensus or in a way that can break existing code.)
It's possible to update the wire format in a (mostly) backwards compatible fashion. Since practically no messages use >4096 bytes, and no interfaces have >1024 methods, the second word of the wire format has bits to spare to count a small number of fds per message. [One approach, albeit not recommended.](https://gitlab.freedesktop.org/snippets/615)https://gitlab.freedesktop.org/wayland/wayland/-/issues/100Add a wl_display.delete_id request for server-created objects2019-07-08T08:32:48ZSimon Sercontact@emersion.frAdd a wl_display.delete_id request for server-created objectsSee https://gitlab.freedesktop.org/wayland/wayland/merge_requests/23#note_187478See https://gitlab.freedesktop.org/wayland/wayland/merge_requests/23#note_187478