Support for XDG Shell on Wayland #1190
Conversation
|
CI gfxreconstruct build queued with queue ID 3680. |
|
CI gfxreconstruct build # 2951 running. |
|
CI gfxreconstruct build # 2951 passed. |
bradgrantham-lunarg
added
the
P1
Add support for XDG Shell on Wayland in addition to the classic Wayland shell and make XDG Shell the default choice when both are available. Change-Id: Ib5521c699275e23060c4e7ae05696ed8fc3f7221
Add Python script `generate_wayland.py` that generates source code from a Wayland XML protocol. This script has the same role as the `wayland-scanner` tool, except that the sources generated use the GFXReconstruct `WaylandLoader` instead of directly using `libwayland-client.so` symbols. The current state now is: - If the machine that compiles the code does not support Wayland (no `libwayland-client.so`) then the Wayland code is simply not compiled and the executable will not support Wayland (as done until now) - If the machine that compiles the code supports Wayland and the executable is ran on a machine that supports Wayland, then the `libwayland-client.so` of the client will be loaded using `dlopen` and the generated protocol sources will initialize protocol constants (interfaces). - If the machine that compiles the code supports Wayland but the executable is ran on a machine that does not support Wayland, then the WaylandLoader will remain uninitialized and thus not call the generated protocol sources and not attempt to initialize the protocol constants. This way, the binaries will be able no matter the state of the support of Wayland on the machine that runs them. Change-Id: I9b3878a71b74002859f4edda6d9a6fe180278a8f
marius-pelegrin-arm
force-pushed
the
wayland-xdg-shell
branch
from
4ea64fb to
879eae6
Compare
|
CI gfxreconstruct build queued with queue ID 137703. |
|
CI gfxreconstruct build # 3754 running. |
|
Hello ! So the solution I propose in the end is given with these two commits. The first commit is the one that I proposed here several months ago (with some changes for merge conflicts). Wayland is linked statically, but an issue found with this solution is that the generated binary will not run on a machine that does not have The second commit solves this issue and goes in the opposite direction. The main issue here is that I think this solution is the best that can be made, because doing so has no cost on performances - everything is loaded once, at runtime, only if wayland is used -, do not break any portability - nothing is linked statically so the binary just checks that everything is available when asked at runtime and fails gracefully in all cases and is as future proof as the Vulkan generators already integrated in GFXReconstruct. If you have any question or remark, do not hesitate ! |
|
CI gfxreconstruct build # 3754 failed. |
|
CI gfxreconstruct build queued with queue ID 138247. |
|
The LunarG CI failure # 3754 seemed to be due to an old version of |
|
CI gfxreconstruct build # 3759 running. |
|
CI gfxreconstruct build # 3759 passed. |
There was a problem hiding this comment.
Everything in the code parts of the PR look good. The only change I request (but am happy to do for you if you'd rather) is moving the wayland-protocols submodule into a 'download on demand' dependency, ie the generate_wayland.py script would download the protocols repo when it is being called.
Currently, the strategy for dependencies is to vendor anything that isn't changing often and submodule the things that do change often. Vulkan-Headers updates every week or so, with content that gfxrecon uses. Whereas most of the dependencies are either not updated nearly as frequently, or are in a stable state which doesn't make sense to update all the time.
Wayland-protocols from my understanding is very much like Vulkan-Headers, (more like the gitlab vulkan repo actually) and updates frequently. However, gfxrecon-replay isn't going to be adding new protocols every other week, so a submodule isn't a great fit.
Thus, I would think that download on demand would allow anyone who wants to add a protocol to do so easily while not increasing the checked in repo size or excess traffic to wayland-protocols.
|
@charles-lunarg when this lands, could you also check out #1245 to see if this PR resolves that issue? |
Changes requested by LunarG: Remove wayland-protocols submodule and ownload it from generate_wayland.py instead. Change-Id: I29932c82d0c4b847f94e47dd191e6fcb4406157a
|
CI gfxreconstruct build queued with queue ID 146153. |
|
CI gfxreconstruct build # 3825 running. |
|
There are multiple ways to do this so I just used the |
|
CI gfxreconstruct build # 3825 passed. |
Hi !
Inspired by the PR #698, here is a working support for XDG Shell on Wayland. It is not a replacement of the classic Wayland Shell by XDG Shell but an addition : both are now supported, but XDG Shell is the default choice if both are available, as it is recommended in the Wayland official documentation.
This PR works and can be tested, it is however not finished yet as choices need to be made about the link model. Currently, in GFXReconstruct, the libwayland is only loaded at runtime if necessary. However, Wayland XDG Shell structs, functions and constants are not available in libwayland. They are instead expected to be directly included in the project using sources generated by
wayland-scanner.The issue is these structs, functions and constants depends on the one available in libwayland. So what happens is that if libwayland is not available at link time, the compilation fails.
I see several solutions to this, and there are probably several that I do not see, but here is, in my opinion, the best solution. We could, as I did temporarily in the PR, link against libwayland at link time instead of loading it at runtime. If we compile the XDG Shell sources, it means that cmake found Wayland anyway, so there's no more assumption on the platform or the user environment if we link to libwayland when it is found. The only "loss" is a performance cost - the libwayland will be loaded at startup even if Wayland is finally not used.
If this solution is chosen, the
WaylandLoaderclass becomes useless (as everything is already linked, thus loaded when the program starts) and should be removed. I can do that work if this solution is chosen.Of course, let me know if I haven't seen another issue that linking against libwayland could cause or if you have a better solution to this issue.