Wayland support for vsg

[VasanthBalguri]

Hi All,

I am working on wayland support for vsg, I would like to share my progress:

I added my commits over 1.1.0 release as it seems stable...
⚠️ Limitations: (Help appreciated 🙏)

1. It uses server side decorations for now, so it will work on those DEs which support it (KDE,sway,... but not Gnome)
2. The muti-window example failed to work
3. Qt examples are not working as expected

👇 How to get it:

• Clone my fork
  • git clone https://github.com/VasanthBalguri/VulkanSceneGraph
• Checkout wayland-testing branch
  • git checkout wayland-testing
• Run following commands to build
  • mkdir build
  • cd build
  • cmake .. -DBUILD_WAYLAND=1
  • make
• Let me know if there is a way to distribute it as compiled library 🙏

I am open for any feedback or queries 😄

[VasanthBalguri]

Prequesites

• xkbcommon and wayland development libraries must be installed
  • sudo apt install libxkbcommon-dev libwayland-dev

[robertosfield]

Thanks for posting your work on Wayland support. I just got back from a day our so only done a quick code review. If I have an opportunity tomorrow I will try it out on Kubuntu 22.04 desktop.

After my first once through questions/suggestion that spring to mind are:

1. Longer term perhaps we need an option for users to compile against Wayland and/or Xcb and have the VSG have a mechanism for choosing which implementation they want at runtime. Right now though just having a compile option will be fine.
2. The button mask being cached in Wayland_Window will probably need to be done via a thread safe singleton so that when users have multiple windows the button state isn't lost, or better still if there is a way of asking the window system the pointer state.
3. For Qt use we might not need the input handling, perhaps just Wayland integration would be required, if so then perhaps whether input events need handling could be toggled at compile/runtime.

What were the Qt problems? The way vsgQt works is to use Qt to create the window but defer the vkInstance and vkSurface creation to the VSG's vsg::Window/Surface classes, with the vsg::Window subclass taking the Qt native window id from the WindowTraits. The Win32_Window.cpp and Xcb_Window.cpp both do this so you can look them to see what they do.

[VasanthBalguri]

1. Longer term perhaps we need an option for users to compile against Wayland and/or Xcb and have the VSG have a mechanism for choosing which implementation they want at runtime. Right now though just having a compile option will be fine.

I will look into it, also if the application can intelligently choose its implementation based on the target machine will be good(like if it has wayland and supports our required extensions), although it will require some more effort from our end.

2. The button mask being cached in Wayland_Window will probably need to be done via a thread safe singleton so that when users have multiple windows the button state isn't lost, or better still if there is a way of asking the window system the pointer state.

Unlike X11, in wayland window doesn't have access to global state of input devices.
When window gets into focus the emitted events go directly to that window,so things like global key state, drag and drop, placing window at given location on screen require dedicated extensions which are universally not supported.This makes multi window application tricky.

Hence, having a separate key state will not be of an issue for now, as every window receives it own set of inputs.
Unfortunately multi-window example doesn't work. I need to look into it...

I am thinking of using KDE/QT as a base for this implementation, it has better extensions.

As of now I am facing following issue with QT:

I will need to dig into QT source to find the root cause...

[VasanthBalguri]

3. For Qt use we might not need the input handling, perhaps just Wayland integration would be required, if so then perhaps whether input events need handling could be toggled at compile/runtime

I didn't have time to dig into Qt source code, seems like I need to refactor my source to handle this scenario...
Also the 2. point makes sense now for QT scenario, I will look into it. 😅

[VasanthBalguri]

This is off-topic..

Is there any reason we are packaging the vsg in a single library?
splitting the library will be helpful I suppose, like having a dedicated library built for each platform, instead of configuring at compile time:
libvsg -> libvsgwindow -> binary
Here if we can swap the platform library(if shared library then it is possible at runtime I suppose)
Correct me if I am wrong 🙏

[robertosfield]

glfw has a Wayland implementation. glfw is what I used as my once of reference for learning how to do Xcb/Vulkan integration.

W.r.t multiple libraries vs a single library, I have tried to keep things simple for developers with the ability to just link to single library if all they need is basic 3d rendering and loading of native file formats. There are pros and cons for doing single and multiple libraries, supporting multiple windowing backends at the same time makes multiple dynamic libraries preferable but so far this possibility hasn't existed for the VSG - we've only had one implementation per platform.

The input device issue does sound problematic for Wayland, I can't believe the situation is so bad. I was expecting modern well handled solutions rather than a regression on decades old X11's capabilities.

[VasanthBalguri]

Wayland is a mess unfortunately, there is de-facto implementation like wl-roots, but the default DE is gnome which has very restrictive set of extensions. It seems like developing for a DE is equivalent to developing for an OS 😞 which is very demotivating. The situation might get better over time though.

To give an example,even glfw had to use another library called libdecor to handle window decorations, which seems ridiculous..
glfw/glfw#2212

Right now, focusing our efforts on KDE/QT+Wayland is ideal I think. I will take a look at glfw and implement 1 to 1 for vsg.

[robertosfield]

Thanks for the link. Seems a sorry state of affairs that Wayland has been pushed as being ready for prime time long before it is.

If you come up with helpful links to KDE/Qt+Wayland discussions/code please post them here. I expect others will be interested in the topic of Wayland support.

I don't know if this OpenSceneGraph PR will help, it's a bit old now. Unfortunately I've been so swamped with VSG related work that I haven't had a chance to review this PR, let along merge it, so I can't say whether it will help with aspects but it might provide another perspective:

openscenegraph/OpenSceneGraph#1170

[VasanthBalguri]

Thank you for providing this, I will use this as a reference.

[robertosfield]

I don't now if this might be workable, but perhaps we could dynamically load native windowing libraries at runtime and get the function names to use rather than compiling directly against the library. This approach would provide the flexibility of not needing to directly link the VSG to a specific native windowing library.

This approach is essentially what we do with the vsg::InstanceExtensions and vsg::DeviceExtensions classes for handling Vulkan extensions. However, it's more complicated and more work to implement and use than just using a libraries functions directly.

[robertosfield]

To help wider testing I have merged @VasanthBalguri's wayland-testing branch into the main VulkanSceneGraph repo as the branch:

https://github.com/vsg-dev/VulkanSceneGraph/tree/VasanthBalguri-wayland-testing

You'll need to set the CMake var BUILD_WAYLAND to 1 as per the instructions in the first post in this thread.

I have now a build of the VSG, vsgXchange etc. & vsgExamples and everything builds, though there are many warnings on the VSG build that we'll need to address in time, no worries there. When I run on vsgviewer on my system I do see an exception through about lack of wayland support:

$ vsgviewer models/lz.vsgt
vsgviewer models/lz.vsgt
[Exception] - failed to create Wayland connection result = 0

I am using Kubuntu 22.04 right now so I'll need to look into whether it's possible to enable a Wayland back-end. I'm a newbie on Wayland so happy to stumble through and learn as I go.

--

On the topic of references for Wayland support, perhaps SDL might also be another reference we can look at for inspiration.

Another thought, I believe Wayland is common on automotive infotainment systems, the OSG found a home in this market, the VSG is now a much more natural fit than OSG as it's smaller, faster and more modern, so Wayland support might help those considering the VSG in this embedded market. The question I would raise would be about what happens with event handling on embedded Wayland platforms, I wouldn't be surprised if libxkbcommon isn't a thing, though.... I haven't kept up with recent automotive platforms so this hunch might well be off. If it's right though we might want to make it an optional code path.

[robertosfield]

I have now installed the wayland-plasma and selected this on log-in but when I run vsgviewer I see a new error:

 vsgviewer models/lz.vsgt
Authorization required, but no authorization protocol specified

[robertosfield]

I am now testing the wayland-testing branch on my Ubuntu 22.04 laptop and found I had to install wayland-protocols in addition to libxkbcommon-dev and libwayland-dev, so the install dependencies line is:

sudo apt install libxkbcommon-dev libwayland-dev wayland-protocols

Everything compiles OK, but still haven't got things working cleanly when I run vsgviewer I get a seg fault:

#0 0x00007ffff7f23e34 in wl_proxy_get_version () from /lib/x86_64-linux-gnu/libwayland-client.so.0
#1 0x00005555557d6cbc in vsgWayland::Wayland_Window::Wayland_Window(vsg::ref_ptrvsg::WindowTraits) ()
#2 0x00005555557d6e55 in vsg::Window::create(vsg::ref_ptrvsg::WindowTraits) ()
#3 0x0000555555636b32 in main ()

Will need to check the Wayland status of Ubuntu 22.04

[VasanthBalguri]

Any specific line number where it is segfaulting?

[robertosfield]

Just rebuilt with debug:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f23e34 in wl_proxy_get_version () from /lib/x86_64-linux-gnu/libwayland-client.so.0
(gdb) where
#0  0x00007ffff7f23e34 in wl_proxy_get_version () from /lib/x86_64-linux-gnu/libwayland-client.so.0
#1  0x0000555555945c94 in zxdg_decoration_manager_v1_get_toplevel_decoration (zxdg_decoration_manager_v1=0x0, 
    toplevel=0x55555622aca0) at /home/robert/Dev/VulkanSceneGraph/include/vsg/platform/wayland/xdg-decoration-client.h:197
#2  0x0000555555947196 in vsgWayland::Wayland_Window::Wayland_Window (this=0x7fffee6a5ac0, traits=...)
    at /home/robert/Dev/VulkanSceneGraph/src/vsg/platform/wayland/Wayland_Window.cpp:334
#3  0x0000555555947e55 in vsg::Inherit<vsg::Window, vsgWayland::Wayland_Window>::create<vsg::ref_ptr<vsg::WindowTraits>&> ()
    at /home/robert/Dev/VulkanSceneGraph/include/vsg/core/Inherit.h:37
#4  0x0000555555945d96 in vsg::Window::create (traits=...)
    at /home/robert/Dev/VulkanSceneGraph/src/vsg/platform/wayland/Wayland_Window.cpp:22
#5  0x00005555556aa727 in main (argc=2, argv=0x7fffffffdb98)
    at /home/robert/Dev/vsgExamples/examples/app/vsgviewer/vsgviewer.cpp:190

[VasanthBalguri]

Pls add following line here and share the results

void Wayland_Window::registry_add_object(void *data, struct wl_registry *registry, uint32_t id, const 
   char *interface, uint32_t version) {
Wayland_Window *window = static_cast<Wayland_Window*>(data);
 + std::cout<<" interface:"<<interface<<" id:"<<id<<" version:"<<version<<std::endl
    if (strcmp(interface,"wl_compositor") == 0) {

I want ti see what all interfaces are available in your system

[robertosfield]

I'm working under Windows today so can't look at testing this right away,

[VasanthBalguri]

Hi Robert, Seems like there are many issues. I was able to get mine up and running, but seems like I didn`t provide enough info. I run following system: Kubuntu 22.04 Kde plasma 5 I am away and I dont have access to my computer will be back on March 11 to verify. I built mine on version 1.1.0 as I got compilation errors on latest version. I will try to setup a VM and verify different distros once I am back home Regards, Vasanth

…

On Sun, 25 Feb, 2024, 10:44 pm Robert Osfield, ***@***.***> wrote: I am now testing the wayland-testing branch on my Ubuntu 22.04 laptop and found I had to install wayland-protocols in addition to libxkbcommon-dev and libwayland-dev, so the install dependencies line is: sudo apt install libxkbcommon-dev libwayland-dev wayland-protocols Everything compiles OK, but still haven't got things working cleanly when I run vsgviewer I get a seg fault: #0 0x00007ffff7f23e34 in wl_proxy_get_version () from /lib/x86_64-linux-gnu/libwayland-client.so.0 #1 <#1> 0x00005555557d6cbc in vsgWayland::Wayland_Window::Wayland_Window(vsg::ref_ptrvsg::WindowTraits) () #2 <#2> 0x00005555557d6e55 in vsg::Window::create(vsg::ref_ptrvsg::WindowTraits) () #3 <#3> 0x0000555555636b32 in main () Will need to check the Wayland status of Ubuntu 22.04 — Reply to this email directly, view it on GitHub <#1099 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6DBOIQFLWHK25QZDS7PC3YVNWORAVCNFSM6AAAAABDX4JUAOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKOBUGMYTE> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[VasanthBalguri]

Hi Robert, Yes the xkb is exclusive to linux desktop, although automotive uses linux kernel, it is not garuntee to be present there. I was initially in the same dillema, but got over it as I had no other option.As wayland has no standard for keboard mapping and it is upto the compositor to decide it. My compositor sends the raw values stored in linux/input.h header file, so it is common on all linuxs I suppose. Regards, Vasanth

…

On Sun, 25 Feb, 2024, 10:00 pm Robert Osfield, ***@***.***> wrote: To help wider testing I have merged @VasanthBalguri <https://github.com/VasanthBalguri>'s wayland-testing branch into the main VulkanSceneGraph repo as the branch: https://github.com/vsg-dev/VulkanSceneGraph/tree/VasanthBalguri-wayland-testing You'll need to set the CMake var BUILD_WAYLAND to 1 as per the instructions in the first post in this thread. I have now a build of the VSG, vsgXchange etc. & vsgExamples and everything builds, though there are many warnings on the VSG build that we'll need to address in time, no worries there. When I run on vsgviewer on my system I do see an exception through about lack of wayland support: $ vsgviewer models/lz.vsgt vsgviewer models/lz.vsgt [Exception] - failed to create Wayland connection result = 0 I am using Kubuntu 22.04 right now so I'll need to look into whether it's possible to enable a Wayland back-end. I'm a newbie on Wayland so happy to stumble through and learn as I go. -- On the topic of references for Wayland support, perhaps SDL might also be another reference we can look at for inspiration. Another thought, I believe Wayland is common on automotive infotainment systems, the OSG found a home in this market, the VSG is now a much more natural fit than OSG as it's smaller, faster and more modern, so Wayland support might help those considering the VSG in this embedded market. The question I would raise would be about what happens with event handling on embedded Wayland platforms, I wouldn't be surprised if libxkbcommon isn't a thing, though.... I haven't kept up with recent automotive platforms so this hunch might well be off. If it's right though we might want to make it an optional code path. — Reply to this email directly, view it on GitHub <#1099 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6DBOJLEOCYQ76Z6LEGRITYVNRKNAVCNFSM6AAAAABDX4JUAOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKOBUGA2TE> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[VasanthBalguri]

Hi Robert,

Sorry for delay, I was busy with personal and professional work.

I will try merge 1.1.4 release changes and add logging facility to this branch soon enough.
Currently I am working on other projects, so I cannot commit on when I can deliver it.

feel free to message me regarding anything.

[nolankramer]

Hey @VasanthBalguri, great work here. Do you still have any interest in working on this?

[VasanthBalguri]

Hi Nolan, It has been a while since I worked on it, I have seen that wayland is a very fragmented and opinionated framework. This made it challenging to implement the windowing especially multi windowing. Like Gnome has its own api for window decorations, KDE uses its own api, wlroots uses its own api. Not only that the maintainers of wayland had a plausible deniability saying "wayland is just api". So I was focusing on KDE back then. There were some glitches especially while using QT which made it more frustrating. As of now wayland might have matured more but when I was working that was the case. I can maybe explain what I have done but beyond that I don't have bandwidth for proceeding on this endeavor, at least for this year and next. Regards, Vasanth

…

On Thu, Dec 11, 2025 at 12:38 AM Nolan Kramer ***@***.***> wrote: Hey @VasanthBalguri <https://github.com/VasanthBalguri>, great work here. Do you still have any interest in working on this? — Reply to this email directly, view it on GitHub <#1099 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6DBOPOXGX2TYZJJCBYFIT4BBVTNAVCNFSM6AAAAACOU2KFE6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMRSGMZTIMA> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[nolankramer]

Thanks for the detailed response @VasanthBalguri ! Very helpful!

Just to keep this thread alive and keep track of things, since I know Wayland is the future forward, I'd like to bring to light some information:

As of now, 2025 (almost 2026), many of the functions used in the wayland branch now have stable API and are universal. This makes using functions like:

• zxdg_decoration_manager_v1 (now use xdg-decoration)
• zxdg_output_manager_v1 (now use xdg-output)
• xdg_wm_base (xdg-shell has been stable for awhile)

Reliable.

The wp_ prefix protocols (like wp_viewporter, wp_fractional_scale_v1) are now the standard path.

It also comes highly recommended to use libdecor to get window decorations, instead of trying to do decorations ourselves. Decorations are, like Vasanth said - highly opinionated - and it makes little sense for VSG to handle that in my opinion.

BUT like I highlighted earlier - many of the protocols that could be opinionated/fragmented are now standard. This is excellent news for bringing a stable Wayland implementation into VSG.

A question for @robertosfield - how do you feel about using libdecor to help with window decorations? Can be optionally included/linked to as well. In the case it's missing or the user chooses not to use it - we fallback to xdg-shell, which may be undecorated in both fullscreen and non-fullscreen (the user can handle the decorations themselves if they need to).

And additionally, how do you feel about using glfw or sdl to help with the entirety of window creation, or would you rather that be done by VSG (glfw or sdl are pretty heavy/bring in a lot, so I'd understand avoiding them - BUT they also have good wayland window creation routines, and we could just grab the window handle from them)?

Are there specific automotive Wayland compositors or protocols (AGL, ivi-shell, etc.) that VSG needs to target? Or is standard xdg-shell with fullscreen support sufficient for those use cases?

I think most of Vasanth's code here is actually pretty good, it just needs some API updates, cleanup, and perhaps additional fallback code here and there.

[VasanthBalguri]

Hi Nolan, Thanks for the input Nolan, I think I got motivated again to work on it :D. I will need some time though as I am going through a career transition. When I was working wlroots and kde seemed to be the closest to the desktop but then again it is opinionated and weakly documented. This is good news if the protocols are standardized for all the compositors, is the multi window protocol also standardized as of now? My inputs with regards to decoration is that, we should prefer Server side decoration as it will keep it uniform for the client. If libdecor can achieve that it is good, but keep in mind that it will add more dependencies which will add technical debt. From what I understand VSG is a middleware not a client application so it should be the responsibility of the developer to provide decorations, our responsibility is to provide the interface, @robertosfield <https://github.com/robertosfield> please add your inputs. Maybe once I am free I will build and test against the latest codebase, the 2 challenges I faced are following: Unable to make multi window examples work and unable to make it work with QT window. Links for reference: https://wayland.app/protocols/ openscenegraph/OpenSceneGraph#1170 Regards, Vasanth

…

On Tue, Dec 30, 2025 at 5:11 AM Nolan Kramer ***@***.***> wrote: Thanks for the detailed response @VasanthBalguri <https://github.com/VasanthBalguri> ! Very helpful! Just to keep this thread alive and keep track of things, since I know Wayland is the future forward, I'd like to bring to light some information: As of now, 2025 (almost 2026), many of the functions used in the wayland branch now have stable API and are universal. This makes using functions like: - zxdg_decoration_manager_v1 (now use xdg-decoration) - zxdg_output_manager_v1 (now use xdg-output) - xdg_wm_base (xdg-shell has been stable for awhile) Reliable. The wp_ prefix protocols (like wp_viewporter, wp_fractional_scale_v1) are now the standard path. It also comes highly recommended to use libdecor to get window decorations, instead of trying to do decorations ourselves. Decorations are, like Vasanth said - highly opinionated - and it makes little sense for VSG to handle that in my opinion. BUT like I highlighted earlier - many of the protocols that could be opinionated/fragmented are now *standard*. This is excellent news for bringing a stable Wayland implementation into VSG. A question for @robertosfield <https://github.com/robertosfield> - how do you feel about using libdecor to help with window decorations? And additionally, how do you feel about using glfw or sdl to help with the entirety of window creation, or would you rather that be done by VSG ( glfw or sdl are pretty heavy/bring in a lot, so I'd understand avoiding them - BUT they also have good wayland window creation routines, and we could just grab the window handle from them)? I think most of Vasanth's code here is actually pretty good, it just needs some API updates, cleanup, and perhaps additional fallback code here and there. — Reply to this email directly, view it on GitHub <#1099 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE6DBOL5S5M4O52SQLAD2A34EG34LAVCNFSM6AAAAACOU2KFE6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMZXGE3TMMI> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[nolankramer]

Going to reply directly, to give Robert a chance to catch-up in the thread.

With regards to Multi-Window: Yes, I believe protocol is stable there. I think each toplevel is just a separate xdg_toplevel. Were the issues you hit more about lifecycle/resource sharing across windows, or actual protocol gaps?

With regards to Qt: Were the glitches around Qt's Wayland backend fighting with VSG's surface handling? Might be worth testing again on Qt 6.x - their Wayland support has matured considerably. From what I know, here's what this means for the implementation:

• Qt owns the wl_display and wl_surface
• VSG needs to accept those handles via WindowTraits::nativeWindow / systemConnection

I think you've mostly got the plumbing for this, but once Robert has replied with his thoughts, I can take a closer look and focus on the Qt integration and any synchronization issues that might be there.

With regards to decor: libdecor is small and purposed. It really does come highly recommended - SDL, glfw, etc all use it. And again, we can allow VSG consumers to optionally use it (optional at both build time and runtime. Use if available, otherwise bare xdg-shell). It does prefer Server side decorations, and uses client-side as a fallback (i.e. only when the compositor INSISTS on client-side decor). I really don't think it's a good idea for VSG to get in the business of maintaining a decoration subsystem. But Robert has the final call here. And he will know if VSG users have use-cases that may conflict with it (again, we can make it optional - so might be a moot point). I personally believe it would be far more debt to build our own decor handling.

[robertosfield]

I haven't yet worked with Wayland beyond my testing of the VasanthBalguri-wayland-testing branch back when @VasanthBalguri submitted it in 2024, it wasn't yet ready for prime-time back then.

To help with testing I've merged VSG master into the VasanthBalguri-wayland-testing branch and would welcome folks updating it to work with the latest state of art of working with wayland.

W.r.t using SDL or glfw, an easy answer: absolute not. They simply don't provide the capabilities we need in the form we need and add dependencies and build complexity, and design/implementation wise we don't need to insert yet another abstraction layer between user applications and the OS/drivers/harder.

Users of the VSG should be able to use SDL, glfw, Qt etc. if they so wish, but for most users the built-in Windowing support will be more appropriate, and where it doesn't quite meet this we need to refine things further.

W.r.t adding libdecor as a dependencies for the users that want to use wayland, could it be made option? I can imagine some users would just want to create an embedded application that would never need window decoration and libdecor might not even support all the embedded platforms that users might want to use the VSG in.

[nolankramer]

Ha. An easy an answer for SDL/glfw indeed.

Do you know if there's any automotive use-cases that require protocols/compositors that VSG would need to specially target through Wayland (AGL, ivi-shell, etc.)? xdg-shell is pretty widely supported, but I have no insight into automotive use-cases tbh.

I suppose we could also just wait for automotive users to reply to this thread or create a separate issue or whatever if they have a specific Wayland need...

[VasanthBalguri]

@robertosfield it seems like @nolankramer has a point that adding libdecor will increase adoption amongst wayland users, but as this is a middleware and not a end application the usecases are diverse.

So having a interface around windowng and giving a base implementation of wayland window in vsg, which can be extended for platform specific(like linking libdecor) and include it in vsgExamples or any other repo instead.

You have given a idea in this comment:
#1099 (comment)

But these are for future, just documenting here for future brainstorming...

[robertosfield]

Ha. An easy an answer for SDL/glfw indeed.

Do you know if there's any automotive use-cases that require protocols/compositors that VSG would need to specially target through Wayland (AGL, ivi-shell, etc.)? xdg-shell is pretty widely supported, but I have no insight into automotive use-cases tbh.

I suppose we could also just wait for automotive users to reply to this thread or create a separate issue or whatever if they have a specific Wayland need...

I haven't had input from the Automotive side during the VSG development, and because I've been so busy with the desktop side I haven't chased this up.

I've been surprised by this as Vulkan and the VulkanSceneGraph are much more attuned to the needs of modern embedded systems that OpenGLES/OpenSceneGraph.

[VasanthBalguri]

@robertosfield and @nolankramer , gave it a try with 1.1.13 version following is the issue with multi window
"Number of vsg:Device allocated exceeds number supported" i will have to reimplement it such that it will reuse same vsg::Device, I need to dig deeper.

as per vsg::Qt i think issue is primarily that we are embedding our window inside QMainwindow, which is not properly embedding in case of wayland.

in Window.cpp line 149

#if defined(VK_USE_PLATFORM_WIN32_KHR)
traits->nativeWindow = reinterpret_cast(winId());
#elif defined(VK_USE_PLATFORM_XLIB_KHR)
traits->nativeWindow = static_cast<::Window>(winId());
#elif defined(VK_USE_PLATFORM_XCB_KHR)
traits->nativeWindow = static_cast<xcb_window_t>(winId());
#elif defined(VK_USE_PLATFORM_MACOS_MVK)
traits->nativeWindow = winId();
#endif

this is how it is mapped, think @robertosfield mentioned that we are deliberatley doing this as QT support for vulkan is not good at the time. Here as well I need to figure out how we can make it work for QT.

There seems to be an issue on QT5 which is not fixed:
https://forum.qt.io/topic/163119/qt5-qwindow-inside-windowcontainer-not-receiving-keyboard-events-on-wayland

Also one thing I noticed is that window resizing is laggy, need to check this as well

[robertosfield]

Originally vsgQt used the Vulkan support that Qt provided in Qt5 and Qt6 but I had to abandon it as it wasn't able to share the logical vkDevice between windows. OpenGL requires a graphics context per window so the Qt may have engineered it's approach to integrating Vulkan the same way to make the square peg of Vulkan fit in the round hole that used for OpenGL.

For full Vulkan support this sucks though, and the VulkanSceneGraph is a Vulkan scene graph, it's not a trying to be a OpenGL scene graph, so providing an encapsulation of Vulkan without limitations is what the VSG project is all about, trying to fit the VSG into the round peg provided by native Qt Vulkan integration will limit the VSG to working more like OpenGL and unable to share resources between Windows in the way it should.

If recent versions of Qt have fixed the f*ck up that was the original Vulkan integration then perhaps we can revisit it.

[AnyOldName3]

I don't think there's an especially good reason to keep Qt5 support if it impedes something that works better with Qt6. Qt5 has been out of extended support for months now, so even paying for a Qt support contract won't lead to any bugs you report being fixed. The only thing that will is the billed-by-the-hour support that they offer for their really ancient stuff, which also covers Qt4, which we obviously wouldn't bother supporting.

I suspect that there are still VSG-based projects that currently use Qt5, but at this point, they really should be migrated to Qt6.

[robertosfield]

This is thread is getting rather too Qt centric now when it is started life as a thread for discussion of specifics of Wayland support...

To help get community feedback on the question of which versions of Qt etc. folks are using and need support for I have created a specific thread for folks to chip in: #1646

[nolankramer]

If recent versions of Qt have fixed the f*ck up that was the original Vulkan integration then perhaps we can revisit it.

Looking at the most recent version of the API, this hasn't changed. QVulkanWindow is a simplified, convenience class for people building purposeful single-window 3D apps.

https://doc.qt.io/qt-6/qvulkanwindow.html#createRenderer

The window takes ownership of the returned renderer object.

They even have a note in their API:

Note: QVulkanWindow does not always eliminate the need to implement a fully custom QWindow subclass as it will not necessarily be sufficient in advanced use cases.

Although it would be nice of them to actually let people know that their architecture explicitly does not support sharing devices over multiple QVulkanWindow.

[robertosfield]

Thanks for the clarification.

[robertosfield]

As a general comment. One of the design & implementation features that I've had in mind from the first implementation of the platform windowing support was added to the VSG was that it would eventually evolve into an API that allow multiple implementations to be compiled into the VSG and then selected from at runtime.

For instance if we have Xcb and Wayland on a platform then we might want to build the VSG with both Xcb and Wayland support and then enable applications to select which windowing implementation to use. This would allow vsgQt or other applications/libraries to select between the backend implementation required.

[VasanthBalguri]

The multi window is working but I need some help here:

• I am unable to understand how the window close happens behind the scenes
• I can see that we are calling:

window->bufferedEvents.emplace_back(vsg::CloseWindowEvent::create(window, event_time));

• but there is no clear point where the window is destroyed or any hook for that, as of now I am handling it in the window destructor. This is causing segfault.
• I will figure out the issue from my end, but I need help with the chain of calls happening which will lead to closure of window @robertosfield
• Also I need to work on code refactoring and documenting the design pattern which I used.

[VasanthBalguri]

@robertosfield when will the destructor of ref_ptr will be called?

[robertosfield]

It's like any other C++ object, the destructor is called when the object goes out of scope.

In the ref_ptr<> destructor the object that it points to is unreferrenced by calling ptr->unref(). If the object's ref count goes to zero it's then deleted.

[robertosfield]

The CloseWindowEvent is there to broadcast a close event, it doesn't action a close, so it's up to the application to call close on the window.

If the vsg::CloseHandler is assigned to a viewer it'll respond to the close event by calling window->close. See: https://github.com/vsg-dev/VulkanSceneGraph/blob/master/include/vsg/app/CloseHandler.h

[VasanthBalguri]

My changes are here, tested with single window and multi window examples, working fine for now
https://github.com/VasanthBalguri/VulkanSceneGraph/tree/wayland-latest2
PR: #1647

It might need some more polish but it is okay for testing

[robertosfield]

I have merged @VasanthBalguri's latest work on wayland support with a new wayland-latest2 branch:

https://github.com/vsg-dev/VulkanSceneGraph/tree/wayland-latest2

I have left the original work as the branch wayland-latest.

[VasanthBalguri]

That branch can be deleted I suppose as it is no longer needed.

[robertosfield]

I have built the VSG, vsgXchange and vsgExamples with the wayland build option and then when running vsgviewer I get:

$ vsgviewer models/teapot.vsgt
vsgviewer models/teapot.vsgt 
[Exception] - failed to create Wayland connection result = 0

I will have a look at logging into KDE with Wayland used rather than X11.

[robertosfield]

To test out Wayland on my Kubuntu 22.04 system I installed the plasma-workspace-wayland:

sudo apt install plasma-workspace-wayland

The logged out and select wayland on my login, but... unfortunately just get a black screen and a static cursor, no keyboard or mouse activity has an effect so I just have to restart the machine by pressing the computer reboot button...

I have NVidia drivers so could this be an issue?

[AnyOldName3]

Wayland is a bit less reliable on Nvidia than AMD/Intel/non-desktop vendors, but it's not nearly as bad as it used to be. It's reliable enough that plenty of distros default to it and in some cases don't have an X session available by default anymore. Obviously, 2022 was four years ago though, so there are going to be quite a few things that were fixed in later releases of lots of packages that Kubuntu 22.04 doesn't have, but later releases would.

[VasanthBalguri]

https://www.reddit.com/r/linuxquestions/comments/1n1jqh1/what_is_the_current_state_of_wayland_nvidia/

found this thread, the gist of it is that wayland + nvidia support is better on distros like arch which have the latest versions of packages. As for ubuntu the OP says even version 24 is somewhat unstable, the version 25 is better it seems. Also, the behaviour is same for GNOME and KDE it seems.

[robertosfield]

Oooops, I'm on Kunbuntu 24.04 LTS not 22.04...

Still Wayland + Kubunu 24.04 + NVidia -> Black screen of death, so I can't test as things stand.

Given folks might be switching between X11 and Wayland with the same application I think it'll be essentially to be able to compile the VSG to work with both at the same time, or compile the VSG as shared library and have applications at runtime link to X11 or Wayland version.

I will create a live USB disk of Kubuntu 25.10 and see how I get on. Things will have to be juggled with other work though.