Solus Experimenting With Qt Wayland Compositor, NVIDIA EGLStreams Support

[phoronix]

Phoronix: Solus Experimenting With Qt Wayland Compositor, NVIDIA EGLStreams Support

Solus taking a break from their Steam Linux integration improvements and their other open-source desktop innovations has been experimenting with their own Qt Wayland compositor over the holiday period...

http://www.phoronix.com/scan.php?page=news_item&px=Solus-Experiment-QtWayland-NV

[Sho_]

Interestingly, they wired in NVIDIA proprietary driver support using EGLStreams.

No, they didn't - they use QtWayland, which has supported EGLStreams for quite some time. They didn't need to write any code for this.

[FishPls]

Hey Ikey, if you read this, care to tell how the new version (rewrite using Qt, right?) of Budgie is going? Any ETA?

[ikey_solus]

Hey Ikey, if you read this, care to tell how the new version (rewrite using Qt, right?) of Budgie is going? Any ETA?

No ETA as such, been hacking in a new repo over the holidays to start fleshing out a general feel for the architecture, i.e. shell, compositor, session.
It's all very very minimal right now and I'm putting focus on the compositor part. Once I've made some headway I'll start splitting it out into several
larger repos (compositor, panel, raven, shell, session, common) and they'll form the basis of Budgie 11. Current work repo: https://github.com/budgie-desktop/budgie-rd

[carewolf]

No, they didn't - they use QtWayland, which has supported EGLStreams for quite some time. They didn't need to write any code for this.

QtWayland makes it almost trivial to write a wayland compositor that supports both NVidia and everybody else, but you still have to write at least a few lines of code.

[ikey_solus]

QtWayland makes it almost trivial to write a wayland compositor that supports both NVidia and everybody else, but you still have to write at least a few lines of code.

Even more trivial if you opt to use QML - which we haven't. So theres more boilerplate and management but it gives us greater control over the rendering pipeline and such. I also opted to go for a modular approach, with the default plugin implementing the display type as a QOpenGLWindow. Idea being in future we can have a QVulkanWindow implementation as and when Vulkan spec permits. The main job of our renderer type in budgie-rd is mapping a QWindow derivative to a QWaylandOutput, and provide surface mapping, rendering and input layer management (so we can match to our internal Compositor::WaylandWindow type and dispatch QEvents). Then the rest of it is basically going to be typical window management stuff, workspaces, and some custom wayland protocols to allow us to correctly place panels and such on the correct z-index and implement our own strut reservation.

[kalin]

Even more trivial if you opt to use QML - which we haven't. So theres more boilerplate and management but it gives us greater control over the rendering pipeline and such. I also opted to go for a modular approach, with the default plugin implementing the display type as a QOpenGLWindow. Idea being in future we can have a QVulkanWindow implementation as and when Vulkan spec permits. The main job of our renderer type in budgie-rd is mapping a QWindow derivative to a QWaylandOutput, and provide surface mapping, rendering and input layer management (so we can match to our internal Compositor::WaylandWindow type and dispatch QEvents). Then the rest of it is basically going to be typical window management stuff, workspaces, and some custom wayland protocols to allow us to correctly place panels and such on the correct z-index and implement our own strut reservation.

Is there any option to switch to vulkan in your qt compositor in run time (without recompile). Do you believe that vulkan provide any benefits over opengl ?

[ikey_solus]

Is there any option to switch to vulkan in your qt compositor in run time (without recompile). Do you believe that vulkan provide any benefits over opengl ?

Not yet because there is no Vulkan implementation. There is too much waiting to happen upstream before we could ever implement one

[gsedej]

Is EGLStreams also for optimus based laptops? (Intel igp + nvidia)

[ikey_solus]

Is EGLStreams also for optimus based laptops? (Intel igp + nvidia)

Honestly not something I've looked at. It all really depends on the active DRM device, and I'm not entirely convinced Qt's eglfs offers enough flexibility in that department. Another shortcoming here is that Qt has to be built with -opengl es2 at configure time for NVIDIA EGLStreams to actually work. Unfortunately that breaks a whole host of normal applications too (such as VirtualBox and Krita, as we've just discovered in Solus..)