|
|
Log in / Subscribe / Register

Xfwl4: the roadmap for a Xfce Wayland compositor

[Posted January 27, 2026 by jzb]

The Xfce team has announced that it will be providing funding to Brian Tarricone to work on xfwl4, a Wayland compositor for Xfce:

Xfwl4 will not be based on the existing xfwm4 code. Instead, it will be written from scratch in rust, using smithay building blocks.

The first attempt at creating an Xfce Wayland compositor involved modifying the existing xfwm4 code to support both X11 and Wayland in parallel. However, this approach turned out to be the wrong path forward for several reasons:

  • Xfwm4 is architected in a way that makes it very difficult to put the window management behavior behind generic interfaces that don't include X11 specifics.
  • Refactoring Xfwm4 is risky, since it might introduce new bugs to X11. Having two parallel code bases will allow for rapid development and experimentation with the Wayland compositor, with zero risk to break xfwm4.
  • Some X11 window management concepts just aren't available or supported by Wayland protocols at this time, and dealing with those differences can be difficult in an X11-first code base.
  • Using the existing codebase would require us to use C and wlroots, even if a better alternative is available.

Work has already commenced on the project, and the project hopes to share a development release in mid-2026.


to post comments

Looking forward to it

Posted Jan 27, 2026 14:57 UTC (Tue) by dskoll (subscriber, #1630) [Link] (1 responses)

I use and love XFCE4 and was feeling much trepidation as it became obvious X11 would eventually go away. I hope they manage to keep the XFCE4-ness of the environment under Wayland.

Looking forward to it

Posted Jan 28, 2026 16:17 UTC (Wed) by AutoStatic (guest, #71722) [Link]

I think they will. I'm typing this in a XFCE session under Wayland using labwc and the experience is almost the same as with X11 besides some minor inconveniences. Really great to see work has started on xfwl4, the window manager was basically the only XFCE component not running under Wayland yet: https://wiki.xfce.org/releng/wayland_roadmap

Architecture / Modularization

Posted Jan 27, 2026 17:37 UTC (Tue) by swilmet (subscriber, #98424) [Link] (21 responses)

I wonder about the general architecture, if a crash on the compositor will make all the apps to crash as well. Even when written in Rust, it depends and links against some components of the graphics stack.

Currently GNOME Shell doesn't handle that well, see this ticket.

Knowing Xfce to be more modularized (compared to GNOME Shell), I also wonder about some possible separation that Wayland allows but is not always (and not often) applied in practice. For example I'm interested to see this FOSDEM talk this weekend: Separating the Wayland Compositor and Window Manager.

Such architectural decisions are best to be made early on on a new project.

Architecture / Modularization

Posted Jan 27, 2026 17:38 UTC (Tue) by swilmet (subscriber, #98424) [Link]

And on a related note, I don't know what's the status about this for KDE.

Architecture / Modularization

Posted Jan 28, 2026 1:21 UTC (Wed) by rsidd (subscriber, #2582) [Link] (18 responses)

I use sway (wlroots) and, yes, a compositor crash does bring down the whole desktop. I ran into it a couple years ago and it turned out the bug was an assert in libinput; replacing the assert with an "if" fixed it. I have not had any other issues in about 4 years of using sway now.

I am guessing that, even if xfwl4 uses smithay instead of wlroots, it is still vulnerable to crashes via dependencies like libinput; and wlroots is much more mature than smithay (though, thanks to cosmic, smithay is seeing activity these days). Hopefully they have thought through this choice.

Architecture / Modularization

Posted Jan 28, 2026 4:37 UTC (Wed) by raven667 (subscriber, #5198) [Link] (17 responses)

I personally use GNOME on all my computers but I can't remember the last time the shell crashed, I imagine that the underpinnings are _very_ reliable such that crash bugs in the compositor/WM just aren't a significant concern, unlike the old days.

Architecture / Modularization

Posted Jan 28, 2026 5:37 UTC (Wed) by dilinger (subscriber, #2867) [Link] (16 responses)

It's not just crashing, though. I gave Gnome/Wayland a good solid try two years ago, with both me and my wife using it. She lasted about a month (there were some missing features that she needed), and I lasted about 9 months before switching back to Cinnamon. One thing that drove me nuts was the memory leakage. It's not as bad as it used to be, but some extension or something was slowly leaking memory, and after 2-3 months of uptime I was finding the machine out of ram. With Cinnamon and Gnome/X, I just restart the window manager without having to restart my various in-progress things, but not with Wayland.

Architecture / Modularization

Posted Jan 28, 2026 8:22 UTC (Wed) by taladar (subscriber, #68407) [Link] (15 responses)

This might also be a concern for xmonad-style library-like window managers if restarting is not easily possible.

Architecture / Modularization

Posted Jan 28, 2026 10:55 UTC (Wed) by farnz (subscriber, #17727) [Link] (14 responses)

If you look at how Arcan has solved it, and how KDE is gradually improving in this area, the tricks are the same: have a state store component that's highly reliable, because all it does is accept state from the compositor and send state back to the compositor. The compositor sends over the bare minimum state to the state store to allow it to recover (client FDs so that they don't need to reconnect, DMABUFs for client buffer contents so that the client doesn't need to re-render to be visible again, locations and other renderer parameters), and on startup, pulls that state back out of the state store.

The result is that it can recover from a crash, because the state store doesn't crash (it doesn't communicate with clients, nor does it access hardware) when the compositor crashes. The hard part (and the bit KDE is working on now) is making sure that there's just enough state in the state store to let you recover, without getting tempted to make it do too much.

Architecture / Modularization

Posted Jan 28, 2026 12:50 UTC (Wed) by Wol (subscriber, #4433) [Link] (13 responses)

> The hard part (and the bit KDE is working on now) is making sure that there's just enough state in the state store to let you recover, without getting tempted to make it do too much.

And fix it so when you log back in (after logging out) your apps etc all appear back on screen in the same place? I currently have two instances of xosview every time I log in (I only want one :-), and all my apps seem to be centred on screen one on top of the other, so I have to re-arrange my screen before I can start anything.

Cheers,
Wol

Architecture / Modularization

Posted Jan 28, 2026 14:30 UTC (Wed) by farnz (subscriber, #17727) [Link] (11 responses)

That would be an example of making the state store do too much - it's supposed to be a runtime state store, not persistent between sessions.

Persistence between sessions is something the compositor needs to handle separately - the state store is for the things that need to persist between two instances of a compositor in a single session.

Architecture / Modularization

Posted Jan 28, 2026 17:17 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (10 responses)

Could you please expand on this? Maybe I don't know enough to understand the problem, but it seems really duplicative to have separate mechanisms to save state between compositors in the same session and between sessions. What is so different about starting another compositor in an existing session versus starting a new session that demands a different mechanism?

Architecture / Modularization

Posted Jan 28, 2026 17:28 UTC (Wed) by Wol (subscriber, #4433) [Link] (5 responses)

Eggsackerly.

The spec is to persist state from one instance of the compositor to the next. WHY the old compositor died is irrelevant to the requirement.

Cheers,
Wol

Architecture / Modularization

Posted Jan 28, 2026 18:25 UTC (Wed) by pizza (subscriber, #46) [Link] (4 responses)

> The spec is to persist state from one instance of the compositor to the next. WHY the old compositor died is irrelevant to the requirement.

Except for the minor detail where the the sets of state needed for both situations are different.

* "restoring after a new startup" requires a list of applications (including command line used to launch things) and the state consists of application X instance Y window Z ==> position/size" (and almost nothing else). And of course the applications themselves need to be able to pick up where they left off, which may or may not be technically feasible or desireable. [1]

* "compositor crashed" requires is "existing connection/socket/etc ==> [a large amount of runtime compositor state]" which will necessarily require a lot more than position/size because the already-running application itself has to seamlessly recover. Notably absent is any need to know how to re-launch these applications [2]

[1] I don't need dozens of empty xterms started up for me, for example.
[2] Worth noting that the compositor probably does not even know how the application was launched (ie executable name/path/cmdline), as its first interaction with the application was when said application initiates a connection to the compositor.

Architecture / Modularization

Posted Jan 28, 2026 19:40 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

So it sounds like the state required to recover from a crashed compositor is a SUPERSET of that required to restore state after a fresh start.

So why not implement the state required to recover, and get a fresh start FOR FREE? If you have to do all that work anyway, why not take advantage of it?

Cheers,
Wol

Architecture / Modularization

Posted Jan 28, 2026 20:09 UTC (Wed) by pizza (subscriber, #46) [Link]

> So it sounds like the state required to recover from a crashed compositor is a SUPERSET of that required to restore state after a fresh start.

Uh, A+B and B+C means they share B, not that one's a superset of another.

Architecture / Modularization

Posted Jan 29, 2026 9:06 UTC (Thu) by farnz (subscriber, #17727) [Link]

No - they have very little in common (see my other comment for details). Your position is like saying that because motorbikes and planes can both get you from point A to point B, but a plane carries more people, a pilot's licence is clearly a superset of a motorbike licence.

Both have window positions. But that's all that they have in common; one has details of how to start applications and get them to create the windows you need them to create to restore state after a fresh start. The other has details of how to pretend to already-running applications that the compositor never crashed, and thus they don't have to create new windows at all.

Architecture / Modularization

Posted Jan 29, 2026 9:57 UTC (Thu) by geert (subscriber, #98403) [Link]

> [1] I don't need dozens of empty xterms started up for me, for example.

I have a script to start them for me ;-)
But as long as --geometry is a no-op on Wayland...

Different state between sessions and within sessions

Posted Jan 28, 2026 18:57 UTC (Wed) by farnz (subscriber, #17727) [Link] (3 responses)

It's completely different state, and there's very little overlap.

The in-session restart state wants to start from a connected client socket FD that you can duplicate and pass back to the restarted compositor, and then send it a serialized lump of state (including DMABUF FDs) that allows the compositor to "fast-forward" to exactly the place the communications were in before the client crashed, as-if all the previous communications with the client had happened with this instance of the compositor. If it all works, the client is completely unaware of the crash - and if the client quit or crashed between the compositor restarting, and you sending this state to it, you just drop the client (that is, after all, what you'd have done if the compositor hadn't crashed).

The between-session restart state wants to know how to launch the client, and what to send the client to get it to issue appropriate protocol requests to (e.g.) reopen windows that you can then position where they were before. But that's completely different metadata, with the overlap basically being that both include positions and sizes in them.

For example, the in-session restart state might say "there is a monitor attached to DP-3, which is at 0x0 and size 3840x2160, scale factor 125/100", or "FD 123 has surface ID 0x12345678 open, contents provided by the DMABUF on FD 2155 using DMABUF, and attached as a sub-surface of 0x7714 at location 120x340. Surface 0x7714 is a top-level surface, at 10x10 from the top-left of DP-3". The compositor follows all of this metadata to restore state to where it was when it crashed, then does things like "DP-3 is disconnected, rearrange windows".

The between-session metadata might say "start browser-binary, and ask it to open https://lwn.net/ attaching metadata token browser-restart-lwn-net. When a top-level surface is created with attached metadata token browser-restart-lwn-net, move it to 10x10 from the top-left of the Dell U3216Q and make it 2000 pixels wide by 2000 pixels high, resizing and moving as appropriate if that monitor is not connected any more".

Different state between sessions and within sessions

Posted Jan 28, 2026 21:16 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

Thank you for the detailed response. It makes total sense now.

I also want to thank LWN for producing the kind of place where my question was treated as a serious request for information. I feel like if I asked the same kind of question in a lot of places, people would treat it as a challenge to their competence, resulting in a lot of unproductive bickering. It's so refreshing to have a place where that rarely happens and the moderators are quick to step in if it does.

Different state between sessions and within sessions

Posted Jan 29, 2026 9:13 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

What is probably closely related to the crash recovery state is the state required to restart for the purposes of upgrading the compositor without restarting all the applications too. That one might need a bit more information on the exact data types in use though so it can detect when something changed and needs migration between versions of the same data.

Different state between sessions and within sessions

Posted Jan 29, 2026 10:23 UTC (Thu) by farnz (subscriber, #17727) [Link]

It is - it's also a subset of the state that wprs has to maintain, since it knows whether the compositor can recover state implicitly, or has to have explicit protocol to recover a given piece of state.

Architecture / Modularization

Posted Feb 2, 2026 22:13 UTC (Mon) by piterpunk (subscriber, #52618) [Link]

After the InputCapture Portal implementation and being able to use input-leap/deskflow with Plasma 6 on Wayland, the session restore is one of the few big annoyances that I still have with Wayland. By now I still miss:

- That my apps remembers their size and position. It's very annoying to have all windows to show up stacked at the center of screen and always need to distribute them around my monitors and workspaces;
- Being able to Shade/Unshade windows. Reduce the windows to only its title bars is a very quick and convenient way to put an window "out of way" to see what is under it and then back to its place;
- Something to remember permissions that I gave for an application to do something (snapshot screen, read my keyboard, etc), I don't want to re-authorize things at every startup.

I am happy that it's a very small list.

Architecture / Modularization

Posted Jan 28, 2026 6:21 UTC (Wed) by pabs (subscriber, #43278) [Link]

Arcan has had crash resilience since 2017, so it is definitely possible.

https://arcan-fe.com/2017/12/24/crash-resilient-wayland-c...

Recent KDE seems quite resilient too, plasmashell crashes don't take out kwin, and kwin has some crash resilience stuff.

Really happy with XFCE on X11

Posted Jan 27, 2026 19:11 UTC (Tue) by NightMonkey (subscriber, #23051) [Link] (7 responses)

I do hope that as long as X11 development continues the good XFCE devs will continue to support it (or at least not intentionally break it). XFCE has been exceptionally stable and easy to use for me and my family on X11.

I don't use it often, but SSH X-forwarding has been very useful for those edge-case administration tasks for home systems setups.

I know the world is going to Wayland, and I hope Wayland gets better and better.

Really happy with XFCE on X11

Posted Jan 27, 2026 19:29 UTC (Tue) by dskoll (subscriber, #1630) [Link] (1 responses)

Yes, I'm also happy with it. I have some non-technical family members running it. I rarely need to have graphical access, but for those occasions when I do, I use x11vnc and a VNC viewer. That way, I get to take control of my relative's desktop and fix whatever they accidentally broke.

Oh, and off-topic, but can desktop app authors please enable a "DON'T MESS WITH ME!" setting that disables all changes to toolbars, settings, etc. unless it's explicitly re-enabled? Many non-technical people, especially elderly ones, click something without realizing it and then a toolbar disappears and they have no idea what happened. My dishwasher has a "Lock Controls" setting. We need that for desktop apps too!

Really happy with XFCE on X11

Posted Jan 27, 2026 20:50 UTC (Tue) by Wol (subscriber, #4433) [Link]

A. O. L.

And not even the non-technical and elderly! There are so many unknown hot keys and shortcuts that even the technically literate can easily click/press one by accident.

Once I've configured my stuff the way I like it, I want to *lock* *it* *down*. The grief from accidentally clicking something I don't know is much greater than the hassle of unlocking the desktop so I can change it.

But that does require buy-in from apps too. This is something I feel with gentoo - every now and then, and app with a single global config file gets that file updated (postfix, anyone), and gentoo wants to overwrite my config with the default! If I can put my config in a separate, LOCAL config override file, then stuff is not going to get accidentally trashed.

Cheers,
Wol

Really happy with XFCE on X11

Posted Jan 27, 2026 19:58 UTC (Tue) by jmalcolm (subscriber, #8876) [Link] (3 responses)

I also hope X11 support for XFCE sticks around. I am a huge Wayland booster but I have no desire to "kill" X11 and XFCE is an important environment on operating systems where Wayland has not penetrated as far as it has on Linux.

That said, it is hard to imagine a little project like XFCE maintaining both long term. It was intriguing that they were going to build an abstraction layer that would lower the cost of maintaining both but it seems like that has failed. So, they will have two different implementations. Not only is this more work but, as GNOME and Plasma discovered, it is also going to hold you back as you are forced to support only functionality that can reasonably be expressed in both environments.

This is why we have seen Budgie, GNOME, and KDE all move to Wayland only. I fully expect that Cinnamon will do the same once they switch. I had been expecting XFCE to maintain both but, with this move, that seems less certain. The fact that they are dedicating such a large fraction of their resources to Wayland tells you how they view the future. MATE is another question mark, although it is the default desktop in some very X11-ish places like Solaris and GhostBSD. As we exit 2027, the only X11 desktop environments may be Trinity and CDE.

I am sure you know this but Waypipe and WPRS offer an alternative to X-forwarding if you do find yourself on Wayland. It works quite well.

Really happy with XFCE on X11

Posted Jan 27, 2026 20:27 UTC (Tue) by dskoll (subscriber, #1630) [Link] (2 responses)

XFCE apps are built against GTK3, are they not? So unless they drop down to low-level Xlib calls or some other X11-specific toolkit in a particular app, the apps should be fine and should work on both X11 and Wayland.

It's only the window manager that's heavily intertwined with X11 that needs replacing.

Really happy with XFCE on X11

Posted Jan 27, 2026 20:34 UTC (Tue) by dskoll (subscriber, #1630) [Link]

Replying to myself: Of course, Gtk will drop X11 support in Gtk-5, and then XFCE will stop working on X11 or else rely on ancient/unmaintained versions of Gtk.

Really happy with XFCE on X11

Posted Jan 27, 2026 21:46 UTC (Tue) by jmalcolm (subscriber, #8876) [Link]

> XFCE apps are built against GTK3, are they not?

Yes they are. And they work very well today on both X11 and Wayland. The XFCE project itself is X11 first today but there are already distros that ship XFCE as Wayland only on top of a compostor like LabWC.

Some parts of XFCE will require special attention to keep working on X11 but you are right, the primary support burden will be XFWM itself.

Many of the non-GNOME GTK desktops seem to be sticking with GTK3 on purpose though there is some sign that shipping alternative implementations of libadwaita in GTK4 may replace that strategy. GTK itself has a long support lifefime so there is not much of an emergency to move away from these versions. GTK5 will probably arrive Wayland-only but that will affect application availability more than the viability of the desktop environment itself (at least at first).

Really happy with XFCE on X11

Posted Jan 28, 2026 13:06 UTC (Wed) by garyvdm (subscriber, #82325) [Link]

I find `waypipe ssh` to be a very suitable alternative to SSH X-forwarding.

https://gitlab.freedesktop.org/mstoeckl/waypipe/

Also SSH X-forwarding still works in wayland provided you are running xwayland.

Wayland starting to work

Posted Jan 27, 2026 19:40 UTC (Tue) by jmalcolm (subscriber, #8876) [Link] (21 responses)

In my view, this story shows that the Wayland strategy is starting to pay off. By that, I do not even mean in terms of functionality or features for users but rather as an architecture for developers.

A common complaint about Wayland is how much work each compositor has to do to implement Wayland. For X11, Xorg had essentially won the Linux desktop and everybody was using the same X server. Building an X11 window manager to run on top of Xorg was not that much work because Xorg itself was doing most of the heavy lifting. At least compared to implementing a Wayland compositor. At least, that is the story I keep hearing.

On Wayland, a lot of what Xorg was doing as the display server has to be done by each Wayland compositor independently.

But of course, we have seen libraries emerge that do most of the heavy lifting for you including wlroots, smithay, louvre, aquamarine, swc, and others. This is why you can have a new Wayland compositor project start like xfwl4 here as primarily the work of a single developer and yet suggest that they will have a first release available in just a few months (mid-2026 is 5 months from now).

And it is not just that these libraries address a core criticism of the Wayland approach. This is a massive improvement over the monolithic approach in Xorg. Not only does XFCE have a solid base to build on but they were able to select from multiple options to choose the one that was the best fit in terms of features, maturity, and language choice.

In choosing Smithay, XFCE is building on the same foundation as COSMIC and Niri. Good company. But beyond the compositor, Wayland requires you to implement the XDG-desktop-portal bridge. Many use the wlroots portal. GNOME, KDE and COSMIC build their own. Niri uses the one from GNOME. It will be interesting to see what XFCE settles on. Perhaps leveraging the work from COSMIC makes sense.

I see this as very similar to having multiple browser engines and JavaScript engines available on which to build web browsers. Most in the Open Source world would agree that having a single browser engine (Chromium perhaps) is a bad thing. We gnash our teeth over the health of Firefox. We cheer on efforts like Ladybird and Servo. And so we should in my view. Multiple implementations competing for market share drives innovation, increases quality, improves performance, and ensures that no single player has total market power over their user base. On the web, every implementation supports a different subset of web standards to varying degrees of completeness. But just as with the web, where things have matured to where most apps work well on most browsers, so will Wayland "engines" mature.

And even once we have many mature Wayland implementations for would-be compositor authors to choose from, anybody will be free to write another one if they think they can do it better (just as Ladybird is doing for the web).

The modularity of Wayland will prove to be one of its great strengths over time. Even though the best is yet to come, it is nice to read stories like this that demonstrate how far we have come.

Wayland starting to work

Posted Jan 29, 2026 18:34 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link] (20 responses)

I see this as an indictment of Wayland instead. XFCE is having to spend precious funds on a paid developer reinventing the wheel because a bunch of graphics developers got together and wanted to reinvent the wheel for themselves. If it's only _ONE_ paid developer because people have managed to build some libraries, that makes the unnecessary cost imposed on XFCE less, but it's still a case of Wayland damaging the Linux ecosystem for no good reason.

I run my own window manager, based on code from someone else: https://github.com/linuxrocks123/win31wm

It's nice and simple, and I have no plans to port it to Wayland, nor will I ever switch to Wayland. I've extensively studied this issue and believe that, with the aid of 12to11 and Wayback, I will never have to. I wish more projects would put their feet down instead of going along with Wayland's nonsense, but I understand XFCE's decision.

Wayland starting to work

Posted Jan 29, 2026 19:02 UTC (Thu) by dskoll (subscriber, #1630) [Link] (12 responses)

I'm also fine with X11 and see no need for Wayland, and chafe at some of its restrictions like not letting apps position their windows.

Unfortunately, that's not what most people think. And with Xorg essentially being unmaintained seeing as most (or all?) of the Xorg developers have switched to being Wayland developers, I don't think apps can "put their foot down" unless they are willing to maintain Xorg and X11 back-ends for toolkits like Gtk and Qt. That would take far more developers than just one paid developer to work on a Wayland compositor for XFCE.

It's too bad that we're in this situation, but reality is reality and we IMO cannot stop the eventual death of X11. Wayback and 12to11 might help for a while, but I don't see them as long-term solutions.

Wayland starting to work

Posted Jan 29, 2026 20:31 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link] (4 responses)

I don't think anyone needs to maintain XOrg, because Wayback is intended to prevent needing XOrg. I see no reason that Wayback should need significant maintenance or would become non-viable in the future.

Wayland starting to work

Posted Feb 3, 2026 22:07 UTC (Tue) by jmalcolm (subscriber, #8876) [Link] (3 responses)

> I don't think anyone needs to maintain XOrg, because Wayback is intended to prevent needing XOrg

Well, Wayback is just the bare minimum Wayland compositor required to run Xwayland. So Wayback is only useful as long as Xwayland exists. Wayback itself should be very simple to maintain for sure. Xwayland is not that hard to maintain as long as X11 stops evolving which is of course why the Wayland devs do not want X11 to evolve.

The thing is, two-thirds of the Xorg code is shared with Xwayland (almost all the Xwayland code is in Xorg). And this is the provides all the features other than hardware support. So, maintaining Xwayland (eg. security and toolchain compatibility) is effectively maintaining Xorg as well. And the only way to keep Xwayland stable is to keep Xorg stable too (to stop adding features to it)

So, yes, Wayback should provide a way to continue using X11 window managers for a very long time. But it also means almost by definition the complete stagnation of X11.

In contrast, the Xlibre project (not endorsing it) intends to keep evolving the Xorg codebase with the view that X11 remains the future of the Linux desktop. If evolving X11 means breaking things, they will do so. Clearly the Xorg folks and the Xlibre folks have a very different vision for the future. You do not need to invent conspiricy theories to understand why they could not work within the same repository. The missions are incompatible.

Perhaps the most interesting project is Phoenix. It also sees X11 as the future of the Linux desktop but does not see the Xorg codebase as the right way to get there. They are also going to break things but, as much as possible, what they are going to break is compatibility with ancient applications that nobody uses. They have even talked about the possbility of supporting Wayland applications. The project may go nowhere but it seems active at the moment. It is an interesting one to watch.

Wayland starting to work

Posted Feb 3, 2026 22:41 UTC (Tue) by pizza (subscriber, #46) [Link]

> In contrast, the Xlibre project (not endorsing it) intends to keep evolving the Xorg codebase with the view that X11 remains the future of the Linux desktop. If evolving X11 means breaking things, they will do so.

Except for the minor point that not "breaking things" is the entire point of sticking with X11 in the first place.

If Xlibre (or Phoenix) introduces something genuinely "new" then they have to get application, toolkit, driver writers, *and* other Xserver [1] buy-in for it to be of any real use... which is going to be a very tall order these days.

[1] Notably including Xorg, which thanks to XWayland is where most desktop users are (or soon will be) found these days.

Wayland starting to work

Posted Feb 13, 2026 8:40 UTC (Fri) by daenzer (subscriber, #7050) [Link] (1 responses)

> Xwayland is not that hard to maintain as long as X11 stops evolving which is of course why the Wayland devs do not want X11 to evolve.

It might not be your intention, but this can be read as "Wayland devs are trying to prevent X11 from evolving", which isn't true. They're simply not interested in evolving X themselves. Those who are would need to step up and do it.

> And the only way to keep Xwayland stable is to keep Xorg stable too (to stop adding features to it)

That's not true. Features can be added to Xorg without hurting Xwayland (and vice versa).

> So, yes, Wayback should provide a way to continue using X11 window managers for a very long time. But it also means almost by definition the complete stagnation of X11.

I don't agree that's a valid conclusion.

Wayland starting to work

Posted Feb 13, 2026 22:05 UTC (Fri) by raven667 (subscriber, #5198) [Link]

While the OP may have cause and effect reversed the fact that Xorg/X11 is and has been stagnating, and is unlikely to see a surge of development adding new features in the foreseeable future. There doesn't seem to be a lot of demand for it, people who prefer X11 don't want it to change, people who want change are working with Wayland.

Wayland starting to work

Posted Jan 30, 2026 19:25 UTC (Fri) by anton (subscriber, #25547) [Link] (6 responses)

Unfortunately, that's not what most people think.
I think that most people don't think about these issues at all.
we IMO cannot stop the eventual death of X11.
Maybe. Or you could listen to the story of Verilog as recounted at HOPL IV. The gist is that around the year 2000 Verilog seemed to be doomed, as VHDL was clearly winning; but as Verilog has some advantages that showed up especially in big projects, the rumours of its death were greatly exaggerated, and Verilog continued to be used, and eventually it became accepted that Verilog has a future. I expect either X11 or the compatibility layers (like Wayback) to live far longer than "most people" expect.

Wayland starting to work

Posted Jan 30, 2026 19:40 UTC (Fri) by dskoll (subscriber, #1630) [Link]

I hope you're right. The difference between X11/Wayland and Verilog/VHDL is that plenty of people still worked on Verilog and synthesis tools that used Verilog. AFAIK, almost nobody is working on X11 any more other than perhaps critical security bug fixes, and a fork by Enrico Weigelt that seems to have been made more out of spite than anything else.

Wayland starting to work

Posted Jan 30, 2026 20:04 UTC (Fri) by pizza (subscriber, #46) [Link]

> and eventually it became accepted that Verilog has a future. I expect either X11 or the compatibility layers (like Wayback) to live far longer than "most people" expect.

The reason Verilog didn't die is ultimately because the numerous commercial entities that had a huge investment in verilog-based designs continued to invest real money in keeping that ecosystem alive and viable.

Keeping the X11 ecosystem alive will require a similar sort of ongoing investment *from those that want to keep it alive*.

(Note this investment has to compensate for the fact that nearly all of the developers that had been involved in the X11 ecosystem -- volunteer _and_ commercial alike -- have long since moved on to other things)

(See also: retrocomputing fetishists, rust on esoteric cpu architechures, etc)

Wayland starting to work

Posted Jan 31, 2026 13:24 UTC (Sat) by intelfx (subscriber, #130118) [Link]

> I think that most people don't think about these issues at all.

Most people might not think about these issues directly, but they definitely enjoy the benefits of having these issues thought about by someone else (which is what Wayland does, compared to X11).

When I (as a fictional layman) cannot watch an HDR video on Linux, or when I cannot plug my laptop into a monitor with a different PPI class and have my windows remain crisp when dragged from one monitor to another, or use VRR on said monitor, I don't think about X11 or Wayland — I just think "This sucks, give me an OS that's actually competent".

And when I install the next version of Linux (with Wayland) and all of this stuff begins to work, I think "Wow, this is actually good now, please keep doing what you're doing".

So no, people don't think about these issues. But they do notice when *their* issues get resolved.

Wayland starting to work

Posted Feb 3, 2026 22:24 UTC (Tue) by jmalcolm (subscriber, #8876) [Link] (2 responses)

> I think that most people don't think about these issues at all.

You are correct. And that is the problem for X11 fans. People will use the graphical environments they like and they will almost certainly stick with the default display server technology those environments choose for them.

That means that 18 months from now, the Linux users of KDE, GNOME, COSMIC, Budgie, Cinnamon, Hyprland, Sway, Niri, MangoWM, DWL, River, XFCE, Wayland Maker, and others will all be using Wayland. I susupect most MATE and LxQT users will as well. For Desktop Environments, what does that leave? Trinity and CDE? And while there are hundreds of X11 window managers, how many people will be using them? X11 may have five percent desktop Linux market share 24 months from now (or less).

This is not a bold prediction. We are over 50% Wayland now. Perhaps 70%. And the most popular environments are about to be not just Wayland by default but in fact Wayland only. And all the "cool" environments right now are Wayland too.

The question is, what will bring these people back to X11? Because somebody that starts on Wayland even today is going to expereince a lot of pain trying to switch to X11. Two years from now, Wayland will have many more features that X11 does not and as well as almost all the features that X11 does have. And the Wayland way will be the "normal" way.

Yes, Wayback will work. Even Xorg will still be working fine I expect. But the vast majority of people will see them only as a way of preserving legacy environments that nobody uses day-to-day. I would not be surprised if most people do not even use Xwayland in three years. What will they be using it for? GTK2 apps? Xfig?

Phoenix has the potential to prove me wrong. But I would not bet on it.

Wayland starting to work

Posted Feb 3, 2026 22:51 UTC (Tue) by pizza (subscriber, #46) [Link]

> The question is, what will bring these people back to X11? Because somebody that starts on Wayland even today is going to experience a lot of pain trying to switch to X11.

....Including "The [modern] applications I was using don't work any longer". Of course, one can run a nested Wayland compositor under X to handle those things, but it's going to be at a significant feature+performance deficit due to the need to channel it all through X's limitations..

> I would not be surprised if most people do not even use Xwayland in three years. What will they be using it for? GTK2 apps? Xfig?

Everything I use on a daily basis is already Wayland-native (even good ol' emacs); of course there's a long tail of things I use less often.

Wayland starting to work

Posted Feb 4, 2026 11:22 UTC (Wed) by paulj (subscriber, #341) [Link]

Wayland Maker?

Oh... oh.. oh. Thank you for pointing that one out. Ran WindowMaker for many a year, but it became untenable once most of my time was on laptops - WindowMaker did not deal at all well with hot-plugging displays. Would love to have my beloved NeXTSTEP UI back. ;)

Wayland starting to work

Posted Jan 29, 2026 21:12 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

> but it's still a case of Wayland damaging the Linux ecosystem for no good reason.

Reasonable people disagree on "damaging" and "for no good reason"

(Usually because they fail to consider that the former status quo was quite "damaging" in its own right)

> nor will I ever switch to Wayland.

The time is rapidly approaching where this means intentionally cutting yourself off from newer software [1] that won't run without a Wayland environment.

[1] Notably including web browsers

Wayland starting to work

Posted Jan 29, 2026 22:58 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link] (2 responses)

> The time is rapidly approaching where this means intentionally cutting yourself off from newer software [1] that won't run without a Wayland environment.

12to11 can run Wayland-infected software under X11, so no, it doesn't.

Re web browsers in particular, it would take an apocalypse to stop the modern web from working on X11:

https://github.com/chromiumembedded/cef
https://github.com/ttalvitie/browservice
https://www.brow.sh/
https://github.com/fathyb/carbonyl

Wayland starting to work

Posted Jan 29, 2026 23:17 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

I never cease to be amazed by the lengths folks go (and the sheer amount of busywork they undergo) in order to maintain the appearance of ideological purity.

Wayland starting to work

Posted Jan 30, 2026 1:09 UTC (Fri) by linuxrocks123 (subscriber, #34648) [Link]

None of these projects strikes me as ideological in any way. Haven't you ever wanted to visit a website over ssh?

Wayland starting to work

Posted Feb 3, 2026 22:49 UTC (Tue) by jmalcolm (subscriber, #8876) [Link] (1 responses)

> I run my own window manager

progman looks cool.

> nor will I ever switch to Wayland

One of the great things about Open Source is that you do not have to if you do not want. But you may have to do more and more of the work yourself. And you will probably be excuded from some new stuff. But that is your choice.

I agree, Wayback and Xwayland are likley to keep X11 window managers working for a very, very long time. And without much maintainance. As long as X11 stops evolving, Xwayland is mostly about security fixes and toolchain compatibility. And Wayback is the bare minimum Wayland compositor to run Xwayback. I doubt it will need much maintainance at all (once completed).

> a bunch of graphics developers got together and wanted to reinvent the wheel for themselves

That is not what happened. The Xorg developers wanted Xorg to evolve. At some point, they decided that X11 could not advance to where they wanted to take it without breaking it. So, they choose to feature freeze Xorg and start something new. The reason to start something new was yes to have a fresh base. But it was also to keep from breaking Xorg on everybody. So Xorg has kept working, and will keep working. Wayland has been "broken" but is now complete enough that most people would rather use it than Xorg.

> Wayland damaging the Linux ecosystem for no good reason

The conscensus is that Wayland is superior. That is the "good reason". And so most would disagree that Wayland is "damaging the Linux ecosystem". The opposite. But you do not have to agree. And, as above, Xorg has been left in a perfectly working state for you to use if you prefer it. That is part of the Wayland strategy. Stopping the evolution of Xorg is also part of the Wayland strategy. If you agree that X11 should be in feature-freeze, you can use either Wayback or Wayland. If you do not agree with that, there are other projects that share your vision (eg. Xlibre and Phoenix). Perhaps they will become popular but it is not looking likely.

> I understand XFCE's decision

Today, the message from XFCE is that they will have both xfwm4 (x11 window manager) and xfwl4 (Wayland compositor). The rest of XFCE will run on either. If X11 does stay feature frozen, keeping xfwm4 running forever should not be too hard. So, the XFCE team does not seem to be doing anything here to force users to use Wayland. Rather, they want to ensure that, as users and apps move to Wayland, users are able to continue choosing XFCE as their desktop.

If XFCE makes both choices available, I guess we will see which one users choose. If they choose Wayland (and I suspect they will), we will see that XFCE is not wasting ther precious funds after all. Why would people choose Wayland? Well, I suspect it will have many more features, better compatibility, and better performance in the future than X11 does. And XFCE will get to be a part of that.

But progman running on Wayback will still be a choice. People that see it as the best option may choose it.

Wayland starting to work

Posted Feb 13, 2026 8:44 UTC (Fri) by daenzer (subscriber, #7050) [Link]

> So, they choose to feature freeze Xorg and start something new.

There is no Xorg feature freeze.

Wayland starting to work

Posted Feb 13, 2026 8:29 UTC (Fri) by daenzer (subscriber, #7050) [Link]

> [...] a bunch of graphics developers got together and wanted to reinvent the wheel for themselves.

That's quite an unfair characterization of the motivation for creating Wayland.

It was created by people who previously spent years of their life and blood making improvements to X and Xorg which we all take for granted now.

Wayland was born from the realization that X has limitations which cannot be overcome without breaking compatibility. Admittedly I didn't fully realize this myself until years later (I was too busy working on improving X and Xorg). Now it's clear that if it didn't happen, the Linux desktop would have hit a wall by now, unable to provide features people want. The people who created Wayland deserve respect for thinking about how to prevent that long before most people even realized it could happen.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds