Skip Navigation
Louvre v2.0.0 Release: C++ library for building Wayland compositors
  • Every code path introduces a maintenance burden.

    Regarding Xwayland, I think so, but with respect to OpenGL + Vulkan, I don't see it as that complicated. It's a matter of configuring contexts and updating Louvre's higher level APIs for buffer allocation and rendering.

    Is super cool, there is a presentation in one of the conferences about it. Architecture is explained somewhere in the docs. Anyway, if you do implement it - this would be a good alternative to https://guacamole.apache.org

    Oh, so it basically displays a remote window manager in the browser? For a moment, I thought it was running the compositor directly inside the browser with extensions or something like that, hahaha.

    It’s not Microsoft, but actually an open source community running open source forge. Also, it’s way faster to use in browser.

    I see. Well, to be honest, I am quite comfortable with GitHub and its features like actions, discussions, etc., and I don't really care if Microsoft owns it as long as it's free. But thanks for the suggestion.

  • Louvre v2.0.0 Release: C++ library for building Wayland compositors
  • get rid of everything Xorg

    I agree, all the apps I use run natively on Wayland, but I think there will always be some legacy X11 apps that won't get ported. So, I think I'll implement it, but it is definitely not a priority.

    replace OpenGL with Vulkan

    I think I can just add support for Vulkan. There is no need to get rid of GLES as it increases the range of supported devices.

    not sure what is the state in smaller distros. Maybe it would be good to reach out to LinuxMint, lxqt and others to see what would it take for them to switch. If you could implement needed features easily…maybe they would switch.

    I know that Linux Mint already has support for Wayland. I am not sure which library or base compositor they are using, but I am always willing to support anyone using Louvre. Right now, I want to focus on developing my own compositor, which I'll name Crystals.

    RDP?

    That's an important feature, which I'll add at some point.

    Html? E.g. https://greenfield.app/

    Looks very interesting! I wonder how it works, so I definitely will check it out.

    consider moving to codeberg?

    Why?

    Another question came to my mind: how is video processing handled? There were some changes in Mutter and/or gtk4 so it would be efficient, any chance for louvre to have it?. E.g. https://www.phoronix.com/news/GNOME-46-Beta-Released

    Currently, the only type of buffers that are directly scanned out are cursors. I want to add an API to allow the use of other types of buffers soon. It is a bit complicated because overlay planes are very hardware-dependent and limited, and they support a few specific formats/modifiers. So, you also need to negotiate that with the client and so on.

  • Louvre v2.0.0 Release: C++ library for building Wayland compositors
  • Louvre is less modular but handles a lot of tedious tasks behind the scenes, providing a simple API (the enjoyable/creative part I'd say) without sacrificing much flexibility. On the other hand, Wlroots is excellent and highly modular, which is good, but it also means it places all the responsibility on you. You must invest time to fully understand each protocol and implement many tedious tasks yourself, which naturally takes quite some time. Additionally, Louvre is multi-threaded, as seen in the benchmark results in the repository, resulting in higher and more stable FPS compared to single-threaded designs when rendering complex scenes.

  • Louvre v2.0.0 Release: C++ library for building Wayland compositors
  • Thank you :)

    what about Vulkan instead GL? Should be more performant and use less battery. Especially if it is meant to also work on mobile.

    Yes, I believe I could create a renderer using Vulkan without much difficulty. Initially, I chose GLES2 for compatibility reasons.

    is Louvre drawing those window decorations?

    Yes, only the decorations with macOS style.

    there is some overlap with https://github.com/winft/theseus-ship - any idea for a collaboration there?

    Well, that's a compositor (which uses COMO) and Louvre is a library, so sure, I could collaborate with COMO.

    there seems to be a company behind, while I didn’t investigate, are there plans for further development that you would publish, is there a way to influence those plans (suggestions, donations, some other way)

    Cuarzo Software is just a name I use to release my open source projects, it’s not a real company. Everyone is welcome to suggest ideas or contribute to the development of these projects, and I genuinely appreciate that.

    any plans to make a shell around it?

    If time allows me, of course.

    it is mentioned that this is a library, but obviously there is a working compositor. Regardless if this is a technology demonstrator, would it be possible to publish a compositor with decent theming and a few distinct layer modes (classic windows with taskbar, windows 8 like, Mac, gnome, ubuntu). I guess many smaller Linux DEs would consider it then…

    Absolutely, you're free to build a compositor however you like, whether it's in 2D, 3D, or any other style. Essentially, it's akin to creating a game, with window applications acting as textures.

    how does it compare to kwin/mutter?

    Those are compositors and Louvre is just a library, so I don't know how to compare them. As you noticed, the compositor in the video is just one of the examples I made with Louvre.

  • Louvre v2.0.0 Release: C++ library for building Wayland compositors

    Hello everyone,

    I wanted to share with you (once more) the release of Louvre v2.0.0 (C++ library for building Wayland compositors) #linux .

    Demo Video.

    Highlights of the new features:

    • Screencasting: Now compatible with PipeWire via xdg-desktop-portal-wlr.
    • Session Lock Protocol: Allows for the display of login windows.
    • Layer Shell Protocol: For wallpapers, panels, notifications, etc.
    • New Input Events API: Enhanced with support for touch events, pointer gestures, and pointer constraints.

    Release Details.

    If there's any protocol or functionality you would like to see added, please feel free to suggest it or contribute to its development!

    21
    Louvre 1.2.0 Release (C++ Wayland Library)
  • You're right, thank you for your comment. Being so involved in this sometimes makes me forget that not everyone knows things like that. As you rightly pointed out, my current focus is on addressing everything related to Wayland first. Following that, I intend to incorporate rootless XWayland support. When I mentioned "hopefully never," it was simply a touch of sarcasm.

  • Louvre 1.2.0 Release (C++ Wayland Library)
  • Not yet, I mean, XWayland rootful mode has always been supported. But in this mode, all X application windows are rendered within a single Wayland window, enabling functionalities such as running an entire X Desktop Environment within the compositor. However, what hasn't been implemented yet is the rootless mode. In rootless mode, each X window is treated as a separate Wayland window, enabling better integration with the compositor.

  • Louvre 1.2.0 Release (C++ Wayland Library)

    Hello, yesterday we released Louvre 1.2.0 (C++ library for building Wayland compositors):

    Main New Features:

    • Fractional Scaling (with optional oversampling)
    • VSync control (with optional refresh rate limiting)
    • Gamma Correction

    New Wayland Protocols:

    • Viewporter
    • Fractional Scale
    • Tearing Control
    • Wlr Gamma Control

    See the GitHub Release

    16
    Louvre: C++ library for building Wayland compositors.
  • I'm not sure if I explicitly mentioned that it's easier than wlroots, but I believe its design can considerably ease the learning curve for newcomers. While I've read about those projects, I haven't had the chance to try them myself. Although I'd be interested in contributing to their development, I don't intend to abandon Louvre. I find it beneficial that there are different alternatives, as each can bring unique and clever ideas to enhance various aspects, ultimately improving the overall design across the board.

  • Louvre: C++ library for building Wayland compositors.
  • I actually already created a library for that called Heaven (https://github.com/CuarzoSoftware/Heaven), but I want to rewrite it to make it simpler and add backends for different IPC mechanisms (Unix domain sockets and D-Bus).

    It allows apps to create as many menu bars as they want. The idea is that when one of its toplevel windows is activated, it can notify the “topbar app” to display a specific menu bar. The compositor also informs the “topbar app” about the currently active client. So, it has three APIs: one for apps, another for the “topbar app,” and another for the compositor. Apps are identified by their PID.

    Now, with respect to the second question, a long time ago, I tried to create a compositor using QtWayland, which had the most documentation at that time. However, it had some problems with certain interfaces that made the compositor crash. So, I then looked for wlroots but could find no documentation whatsoever, so I decided to start from scratch. As time passed, I began to learn and understand how protocols work, realizing that one of the most challenging things was implementing protocols correctly, as there are too many interfaces that depend on each other, and you need to implement them all before you can see results and validate that it works. That’s why I decided to create this lib, even as my university thesis, with the focus of offering a default and basic implementation of each protocol so that developers can see a functional compositor from the start and then gradually and specifically override whatever they need, being able to validate each feature they add immediately. Of course, there are many other complicated things I had to learn, such as the DRM/KMS API, buffer sharing through DMA, among other stuff. I really appreciate wlroots, though. I learned a lot by analyzing its source code, and surely today I would be able to create a compositor with it, hahaha.

  • Louvre: C++ library for building Wayland compositors.
  • I actually already created a library for that called Heaven (https://github.com/CuarzoSoftware/Heaven), but I want to rewrite it to make it simpler and add backends for different IPC mechanisms (Unix domain sockets and D-Bus).

    It allows apps to create as many menu bars as they want. The idea is that when one of its toplevel windows is activated, it can notify the "topbar app" to display a specific menu bar. The compositor also informs the "topbar app" about the currently active client. So, it has three APIs: one for apps, another for the "topbar app," and another for the compositor. Apps are identified by their PID.

    Now, with respect to the second question, a long time ago, I tried to create a compositor using QtWayland, which had the most documentation at that time. However, it had some problems with certain interfaces that made the compositor crash. So, I then looked for wlroots but could find no documentation whatsoever, so I decided to start from scratch. As time passed, I began to learn and understand how protocols work, realizing that one of the most challenging things was implementing protocols correctly, as there are too many interfaces that depend on each other, and you need to implement them all before you can see results and validate that it works. That's why I decided to create this lib, even as my university thesis, with the focus of offering a default and basic implementation of each protocol so that developers can see a functional compositor from the start and then gradually and specifically override whatever they need, being able to validate each feature they add immediately. Of course, there are many other complicated things I had to learn, such as the DRM/KMS API, buffer sharing through DMA, among other stuff. I really appreciate wlroots, though. I learned a lot by analyzing its source code, and surely today I would be able to create a compositor with it, hahaha.

  • Louvre: C++ library for building Wayland compositors.
  • Interesting, I don't recall where I read about Vulkan support still being experimental in many Mesa drivers; it might have been an outdated post. I'll look into it, and perhaps I'll decide to dive into learning Vulkan. Additionally, there are buffer-sharing mechanisms that already work smoothly with GLES, so I need to explore if the situation is similar for Vulkan. Thanks for your response, and if you have the time and inclination to help include it, feel free to do so! 😄

  • Louvre: C++ library for building Wayland compositors.
  • The idea of single, double, and triple buffering revolves around how many framebuffers we use for display rendering. Typically, we go with double buffering, displaying one framebuffer while rendering happens on the other. Swap them, and the cycle continues. The goal is to prevent screen tearing and glitches from popping up on the screen.

  • Louvre: C++ library for building Wayland compositors.

    Hello, yesterday I officially released Louvre v1.0.0, a C++ library designed for building Wayland compositors with a primary focus on ease of development. It provides a default method for handling protocols, input events, and rendering, which you can selectively and progressively override as required, allowing you to see a functional compositor from day 1.

    It supports multi-GPU setups, multi-session (TTY switching), and offers various rendering options, including a scene and view system that automatically repaints only the damaged (changing) regions during a frame. Because it uses multiple threads, it can maintain a high FPS rate with v-sync enabled when rendering complex scenarios. In contrast, single-threaded compositors often experience a rapid drop in FPS, for example, from 60 to 30 fps, due to "dead times" while waiting for a screen vblank, leading to the skipping of frames.

    The library is freely available, open source, thoroughly documented, includes examples, and features a detailed tutorial.

    You can find it here: https://github.com/CuarzoSoftware/Louvre

    I hope it proves useful for you. If you decide to use it and encounter any doubts or wish to contribute to its development, please don't hesitate to reach out.

    Greetings!

    35
    InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)EH
    ehopperdietzel @lemmy.world
    Posts 3
    Comments 24