Notes for protocol-next design
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.
- Make
-
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.
- Is the equivalent of being able to version
-
Eventually, it should be possible to have a Wayland 2.0 -only system, assuming one does not need software that was not ported.