Fixes I made to get a vsg wayland window.

[blobfish]

[VasanthBalguri]

Hi Blobfish,

Thanks for these fixes and giving it a try, I want to ask if you have faced any performance issues while resizing window? Any other feedback is appreciated...

[VasanthBalguri]

Hi @blobfish ,

When I tired to build I ma getting followig error:

[ 97%] Building CXX object src/vsg/CMakeFiles/vsg.dir/platform/wayland/Wayland_Window.cpp.o
In file included from /home/vasanth/practice/VulkanSceneGraph-personal/src/vsg/platform/wayland/Wayland_Window.cpp:4:
/home/vasanth/practice/VulkanSceneGraph-personal/include/vsg/platform/wayland/Wayland_Window.h:91:71: error: ‘const wl_pointer_listener’ has no non-static data member named ‘axis_value120’
91 | .axis_relative_direction = pointer_axis_relative_direction};
| ^
/home/vasanth/practice/VulkanSceneGraph-personal/include/vsg/platform/wayland/Wayland_Window.h:175:67: error: ‘const xdg_toplevel_listener’ has no non-static data member named ‘wm_capabilities’
175 | .wm_capabilities = xdg_toplevel_handle_wm_capabilities};
|

I can see that following apis are not compatible with my system:
wm_capabilities, axis_value120 and axis_relative_direction

Is seems like some new apis are added in later versions, we need to find a mechanism which can identify the target version of the wayland and compile accordingly, this seems more work than what I initially anticipated :(

Or for time being we can drop these apis for now and ignore the warnings.

@blobfish you can give following a try:

void WaylandRegistryState::registry_add_object(void *data, struct wl_registry *registry, uint32_t id, const char *interface, uint32_t version) {
WaylandRegistryState state = static_cast<WaylandRegistryState>(data);
std::cout << "Interface: "<< interface << " Version: " << version <<std::endl;

this will output the capabilities of the wayland in your system and its version

@robertosfield other than that I see no issues with this changes, you can take a call here...

[robertosfield]

@VasanthBalguri could you provide changes you had to make to get things to compile.

I presume we'll need to pass in the API version of wayland, collected from our CMake scripts, or use the wayland headers to decide whether to compile in the newer APIs. I'm not familiar with wayland so can't say what approach would be best.

[blobfish]

I was afraid of that. The wayland header files do a good job of describing the struct members protocol revision history, but I couldn't map that to any library revision. I couldn't find any useful #defines in either the system headers or the generated headers. I don't know how to conditional compile for wayland. For now, the simplest thing to do is just revert the change for the warnings.

IMHO: Wayland Ignorant:
I am getting the impression that baking in all the handlers at compile time is not 'how you do it'. We are jumping through a bunch of hoops just trying to silence warnings. Thinking we could zero initialize some structs at compile time and set the desired handlers at run time using introspection if needed/possible.

[VasanthBalguri]

Hi Blobfish/Robert, I feel that blobfish is right as the build machine is not always the same as the target machine, there will be variation. But there is no api discovery mechanism in wayland other than wl_registry_listener, as it has a version where we can infer the apis based on docs. I am thinking of the following solution: - We will provide a barebones solution which will work on the majority of wayland platforms in vsg core codebase as the lower version build will work on the higher version of target wayland, but vice versa might not work. - But we will provide interfaces which can be used to extend this, which can be linked in compile time or in runtime - We will give sample implementation in vsgExamples which vendors can adopt - I am not well versed in reflections and metaprogramming, but I will learn as I go and try to figure out a solution once I am free - In short, it will run in any system out of the box, but for anything fancy vendor will have to do it themselves. @blobfish, for now please remove the 3 apis i mentioned, the other changes look good, it will work fine for older versions like ubuntu 22.04. Regards, Vasanth

…

On Fri, 16 Jan, 2026, 9:18 pm blobfish, ***@***.***> wrote: *blobfish* left a comment (vsg-dev/VulkanSceneGraph#1650) <#1650 (comment)> I was afraid of that. The wayland header files do a good job of describing the struct members protocol revision history, but I couldn't map that to any library revision. I couldn't find any useful #defines in either the system headers or the generated headers. I don't know how to conditional compile for wayland. For now, the simplest thing to do is just revert the change for the warnings. IMHO: Wayland Ignorant: I am getting the impression that baking in all the handlers at compile time is not 'how you do it'. We are jumping through a bunch of hoops just trying to silence warnings. Thinking we could zero initialize some structs at compile time and set the desired handlers at run time using introspection if needed/possible. — Reply to this email directly, view it on GitHub <#1650 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6DBONV3463WXFYD2ODRGL4HEB3PAVCNFSM6AAAAACQ7E5LL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONRQGY4DQNZRHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[robertosfield]

Would it be possible to just query at runtime for the Wayland libraries and functions using dlopen and dlsym?