GitHub - CuarzoSoftware/Louvre: C++ library for building Wayland compositors.
lemmy.world
C++ library for building Wayland compositors. Contribute to CuarzoSoftware/Louvre development by creating an account on GitHub.

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!

  • ijhoo@lemmy.ml
    32·
    6 months ago

    If we are talking ideas, I would propose the following:

    • focus on the future instead of the past
      • get rid of everything Xorg (including xwayland). Reasoning: recent app upgrades to gtk4 and qt6 support Wayland just fine. Gnome has it by default, I’m not sure where plasma stands. Few things that don’t work, people can probably live without (like chromium which has Firefox as a working alternative)
      • replace OpenGL with Vulkan (that means get rid of OpenGL completely if possible). Reasoning: things sold in the last 10 years support vulkan.
    • 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.
    • RDP?
    • Html? E.g. https://greenfield.app/
    • consider moving to codeberg?

    I know dropping xwayland and opengl is unpopular, but this is where things are going. It’s on the gnome Todo sometime because as far as I read, there is development for mutter to be built totally without xorg support. Plus they recently switched gtk4 to use New vulkan rendered by default.

    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

    • ehopperdietzel@lemmy.worldOP
      7·
      6 months ago

      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.

      • ijhoo@lemmy.ml
        22·
        6 months ago

        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.

        While I understand the need for legacy, I also think at some point legacy should be left alone. If it is really needed for some old app to run, VM should do fine. I don’t think missing xorg is ever going to be an issue in 2025+ (well, Electron apps maybe). Yet added and not used features (or seldom used features) is offset with future maintenance burden and/or security issues for no good reason.

        This also applies to OpenGL comment. Every code path introduces a maintenance burden. While support of more devices is good, supported devices are super old in this case and the question is - is it worth it? Vulkan drivers should either way be in a better state.

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

        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

        Who knows, maybe it would be a money opportunity.

        Why?

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

        • ehopperdietzel@lemmy.worldOP
          3·
          6 months ago

          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.