this post was submitted on 14 Nov 2023
230 points (99.1% liked)

Linux

47383 readers
1036 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
230
Louvre: C++ library for building Wayland compositors. (lemmy.world)
submitted 10 months ago by ehopperdietzel@lemmy.world to c/linux@lemmy.ml
35 comments fedilink hide all child comments
 

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!

all 36 comments
sorted by: hot top controversial new old
[–] LeFantome@programming.dev 17 points 10 months ago (1 children)

Many people have predicted the death of the small, independent window manager with the coming of Wayland. I have heard multiple times that only large projects like GNOME and KDE would be able to take on the burden of making a compositor.

Now, I do think that lots of no longer actively developed window managers could get left behind. But the idea that it will be too complicated to create a window manager now is turning out to be wrong.

First, fewer desktop environments are getting left behind than feared. XFCE, Cinnamon, and MATE all seem to have Wayland plans now.

The big change is the appearance of not one but multiple compositor libraries designed to make it easier to create a window manager for Wayland. Some of them look like they might make it easier than it was under X. The approach taken by this one makes the idea of hacking around with it very inviting.

Although having to create a compositor has made things difficultly until now, I think the idea of decoupling the compositor for Wayland is going to look smart in the long run.

Being separate from Wayland, compositor devs are free to experiment and window manager authors can select the one that best maps to their goals.

I was reading up on Oasis Linux yesterday. It comes with a Wayland compositor ( SWC ) and tiling window manager ( Velox ) that are less than 20,000 lines of code combined!

It would not be practical for a light-weight distro to trim down Xorg like that. But I the compositor is separate, it can be either smaller or feature rich. SWC is XWayland compatible but obviously that is going to add more size if you need it.

Looking forward to the window manager innovation that projects like Louvre enable.

[–] ExLisper@linux.community -2 points 10 months ago* (last edited 10 months ago) (2 children)

People using X window manage will just keep using them. Wayland doesn't offer anything valuable to most users so people will just keep using the managers they like. In 10-20 years we will get some nice, new managers that naturally will support Wayland and people will switch because of the features, not because 'X insecure, Wayland awesome' BS.

[–] merthyr1831@lemmy.world 1 points 10 months ago

Wayland is already a lot nicer to use over X. Better gestures, better animations, better performance, and that's if you use Wayland today, not in a year's time.

Like I get why people are defensive over X but it literally isn't being developed anymore - And if it's really worth keeping over Wayland the time to get contributors to support it is passing quickly.

[–] LeFantome@programming.dev 1 points 10 months ago (1 children)

I agree with your overall sentiment with the caveat that 20 years will be closer to 5. Early adopters are enjoying Wayland only benefits today. For example, the Steam Deck just launched with HDR and mainline support for Linux gamers in general will not be far behind.

Also, the list of window managers being left behind is starting to look less appealing than the list of window managers that are Wayland only. Hyperland is probably already more popular than WindowMkaer. As GNOME and KDE go Wayland only, they will continue to add features that regular users will want. I see more announcements for new Wayland compositors than I do for new X window managers.

Another factor that gets missed is that the main dev support for X comes from Red Hat. RHEL9 is already Wayland based. When RHEL8 comes off support in 5 years, Red Hat will abandon X. How long will X stay viable after that?

As the number of X users dwindle, we will see toolkits drop support for X. GTK5 for example. 5 years may be too soon for that but I cannot see it taking 20 years.

Wayland being “valuable to most users” will come faster than you think.

[–] ExLisper@linux.community 1 points 10 months ago

Sure, maybe it will be 5 years. I'm definitely not going to rewrite my awesome wm config just because Wayland is hip now. I will have to get some really nice features out of that.

[–] drwankingstein@lemmy.dbzer0.com 12 points 10 months ago* (last edited 10 months ago) (2 children)

ngl Im more interested in the dock and what protocols it uses. I've been missing latte dock since I migrated to wayland

[–] ehopperdietzel@lemmy.world 14 points 10 months ago (1 children)

The dock is rendered directly by the compositor in one of the examples; it's not an external application as it ideally should be. It doesn't rely on any intricate protocols or systemd services to monitor the states of apps. I added it solely for demonstration purposes.

[–] drwankingstein@lemmy.dbzer0.com 3 points 10 months ago

Ah thats a shame, looks good however

[–] NathanUp@lemmy.ml 3 points 10 months ago

I just use plasma panels these days

[–] lily33@lemm.ee 12 points 10 months ago (3 children)

There's desperate need to a library that's simpler to use than wlroots or smithay - but unless it supports more protocols (later shell, gamma control, session lock), I don't think this is a real a alternative yet.

[–] ehopperdietzel@lemmy.world 12 points 10 months ago

I completely agree. I invest time in implementing protocols within the library, allowing it to handle many tasks autonomously, thus relieving developers from manually wiring everything themselves—without compromising flexibility oc. Regarding "later shell," did you mean "layer shell"? Developers can certainly still implement protocols not included with Louvre on their own, but that's not quite the intended approach.

[–] LeFantome@programming.dev 3 points 10 months ago

SWC has been out there for a long time. It came before Wlroots I think.

https://github.com/michaelforney/swc

[–] insomniac_lemon@kbin.social 1 points 10 months ago* (last edited 10 months ago) (1 children)

I was thinking similar, though I'm also still on X with nVidia and XFCE and am in a weird way* with programming.

I have my own custom XFWM theme that is really minimal (12px title with 8px tall buttons with some being wider to compensate, somewhat outdated example) and I'd like to expand upon it (floating titles, inset window buttons, dynamic button width, media integration) but I've looked at examples and don't understand enough to even get just a rectangle for a titlebar (though X I assume for something basic, X would probably still be the easiest).

*= the only language that I'm interested in (due to it being easy in a style I like while still having performance/capability/flexibility etc) is not popular, and worse is I have lost a bit of hope/confidence in its future (as well as its bus factor reducing further because the person who made the package manager+installer and a book walked away) so I still haven't really done much with it.

[–] LeFantome@programming.dev 1 points 10 months ago (1 children)

What programming language?

[–] insomniac_lemon@kbin.social 2 points 10 months ago* (last edited 10 months ago)

Nim-lang. some code that I actually wrote using Raylib bindings (Naylib) (+what it's loading)

I've asked about this on the Fediverse once already and didn't get any responses.

Also note that bindings for Godot 4.X (or some other not-superheavy Linux-compatible engine that has an editor especially) are a big part of what I want, so some specifics that may work on paper otherwise might not fit the bill either. Also because polygonal art (meme made with 3.X, 4.0 eye animation, not-yet-in-4.X test of someone elses' PR)

[–] JackGreenEarth@lemm.ee 6 points 10 months ago (1 children)

Is that desktop environment an apple UI clone?

[–] ehopperdietzel@lemmy.world 18 points 10 months ago* (last edited 10 months ago)

Yes (kinda), that is a screenshot of one of the example compositors I included called "louvre-views" which implements server side decorations for apps that support the XDG Decoration protocol.

[–] wiki_me@lemmy.ml 4 points 10 months ago (1 children)

You mentioned it being easier then wlroots, but wayfire and phoc reportedly act as high level abstractions on top of wlroots that could be used to make it easier to create window managers (wayfire author explicitly mentioned it), Maybe it will be good to create a comparison with these projects? or even divert your future efforts to one of them?

[–] ehopperdietzel@lemmy.world 5 points 10 months ago

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.

[–] russjr08@outpost.zeuslink.net 4 points 10 months ago (1 children)

Wow, that looks stunning! I am no where near skilled enough to be able to even begin wrapping my head around making a compositor, even with a library - but I do know that like the other commenter mentioned we certainly need more libraries aside from the two that we currently have (but I understand why that's a very tall order) so major props to you!

[–] ehopperdietzel@lemmy.world 1 points 10 months ago

Thanks, maybe you could follow the tutorial if you are interested. And I wouldn't mind answering doubts; that actually would help me improve the docs ;)

[–] ijhoo@lemmy.ml 3 points 10 months ago (1 children)

Do you plan to use vulkan wmi in any way?

Can xwayland be excluded?

[–] ehopperdietzel@lemmy.world 6 points 10 months ago* (last edited 10 months ago) (1 children)

Honestly, I haven't explored Vulkan yet. I initially chose GLES 2.0 as the primary renderer to ensure compatibility with a wide range of hardware. Introducing Vulkan myself would be a time-consuming task unless I receive assistance.

Regarding XWayland, Louvre doesn't currently support it, so it's naturally excluded. Well, it technically can run in rootful mode, but that is somewhat pointless. To enable independent window management, I believe I would need to create a mini X server, a task I haven't tackled as of now.

[–] ijhoo@lemmy.ml 3 points 10 months ago* (last edited 10 months ago) (1 children)

It looks very interesting.

I might be wrong, but it seems to me like Vulkan Support in hw is better than opengl:

  • amd since at least Polaris (there is a project to Bring vulkan to really old terrascale graphics, but is jot yet there)
  • Intel since idk ~~broadwell~~ Skylake
  • Nvidia proprietary for sure don't know since when and it seems that focus on nvk (new open source driver) is going to be on vulkan
  • android since version 7 - Eighty-five percent of active Android devices support Vulkan (this is better than android Version Rollout) https://developer.android.com/games/develop/use-vulkan
  • rpi, not sure which versions

Probably all of them have better Vulkan than opengl drivers (due to drivers being simpler). David Arlie rather quickly implemented first Vulkan driver for AMD once Vulkan was first released. Just in case you need incentive.

I was thinking of starting something similar as a learning exercise, but I'm really limited in time and not skilled as much in c++, so it would probably lead nowhere. Now I can just build on top - if I get any time for this, will come probably with questions.

Anyway, this idea was to make something modern. Without the legacy crap. Actual goals were:

  1. Vulkan only (move gfx API Info the future)
  2. no x/xwayland (most of the apps in newer toolkits already support Wayland, the others I'd rather avoid)
  3. Multithreaded
[–] ehopperdietzel@lemmy.world 3 points 10 months ago

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! 😄

[–] OsrsNeedsF2P@lemmy.ml 3 points 10 months ago (1 children)

What does "Single, Double or Triple Buffering" mean?

[–] ehopperdietzel@lemmy.world 8 points 10 months ago

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.

[–] NathanUp@lemmy.ml 2 points 10 months ago

Neat