First preview release of Xfce's Wayland compositor [LWN.net]

Brian Tarricone has announced the first preview release of xfwl4, a Wayland compositor for the Xfce desktop environment.

After close to six months of work, I feel like it's ready to get some wider use, even though of course there will be bugs and missing features. Think of this as an alpha release. [...]

The end goal of xfwl4 is to behave as closely as possible to an Xfce desktop running on an X server. Ideally a user could switch between the two without even knowing there's a difference. In reality, of course, it won't be quite that seamless, and there's still more work to be done to get as close as possible to that ideal. This is a first solid cut at it, at the very least.

to post comments

Happy to see this emerge

Posted Jun 22, 2026 14:58 UTC (Mon) by jepler (subscriber, #105975) [Link] (29 responses)

as an xfce user still stubbornly on xorg, this gives me hope that maybe it won't be a huge regression when I'm ultimately forced to switch to wayland.

Happy to see this emerge

Posted Jun 22, 2026 21:44 UTC (Mon) by linuxrocks123 (subscriber, #34648) [Link] (3 responses)

I was angry about the prospect of being forced to switch to Wayland and therefore created a plan to avoid that. Here's my personal plan not to be forced to switch to Wayland:

https://lwn.net/Articles/1027465/

Useful developments since that post include Wayback, which is "a Wayland compositor with a single rootful XWayland instance taking up the entire screen."

Happy to see this emerge

Posted Jun 23, 2026 18:51 UTC (Tue) by dagobayard (subscriber, #174025) [Link] (2 responses)

But I bet this doesn't deal with the real dealbreaker wrt Me & Wayland:
input tools (xdotool, xkbset, etc etc.). I truly can't live without
them, for reasons similar to these: https://nocoffei.com/?p=451 , and I'm
pessimistic about desktop devs ever understanding their importance.

Happy to see this emerge

Posted Jun 23, 2026 19:16 UTC (Tue) by daroc (editor, #160859) [Link]

Back when I used XMonad as my window manager, I had a handful of tools written using xdotool. Switching to wayland did break them, but I later learned about ydotool (https://github.com/ReimuNotMoe/ydotool) which does many of the same things. It emulates an actual input device at the kernel level, and therefore runs no matter what display technology one is using. It's also not a perfect replacement for xdotool, and using non-default keyboard layouts with it is slightly painful, but it is functional. Similarly, many wayland compositors have an equivalent of xkbset, although it's obviously less convenient that they're different tools.

Happy to see this emerge

Posted Jun 23, 2026 22:07 UTC (Tue) by linuxrocks123 (subscriber, #34648) [Link]

Yes, it should deal with that. Everything is an X window running under an X server, including the Wayland applications, so there is no reason X automation tools should not work.

X11-based automation is why one reason I don't want to switch to Wayland, in fact.

Happy to see this emerge

Posted Jun 23, 2026 19:21 UTC (Tue) by tuna (guest, #44480) [Link] (24 responses)

You are not forced to use a compositor that communicates with apps using the Wayland protocol. You can use whatever SW you want on your own HW.

Happy to see this emerge

Posted Jun 23, 2026 22:09 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (23 responses)

This is not a helpful meme. If your preferred desktop environment drops X11, then you are de facto "forced" into one of four options:

1. Fork it.
2. Switch to a different DE.
3. Switch to Wayland.
4. Stop using a GUI on Linux.

For most Linux end users, (1) is not a realistic option (DEs are far too complex for one individual to maintain a fork indefinitely) and (2) gets less and less realistic with each passing year (as DEs drop X11 support). (4) is probably feasible for a lot of users (they can switch to Windows or another OS), but not a particularly helpful answer. That leaves us with (3).

It is worth acknowledging that this software is maintained by volunteers. Framing it as being "forced into Wayland" is a somewhat one-sided way of putting things. But that does not make it altogether inaccurate. End users are justifiably frustrated when functionality is removed for "architectural" or infrastructure reasons, rather than because the functionality is actually problematic in some way. Many DEs have actively removed most of their keyboard settings, usually because they were using the X server as a backend for those settings, and whatever Wayland compositor they switched to lacks feature parity with X (and/or because nobody could be bothered to explore the compositor's API surfaces and find equivalent knobs). It is unfair when Wayland gets blamed for those DE failures, but from the users' perspective, everything was fine until Wayland showed up.

Happy to see this emerge

Posted Jun 24, 2026 0:25 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

End users are justifiably frustrated when functionality is removed for "architectural" or infrastructure reasons, rather than because the functionality is actually problematic in some way.

I think it's a bit more basic than that: users hate losing functionality they depend on regardless of the reason. Wayland had sound reasons for eliminating some of X11's features, but that doesn't make users any happier to lose them. If you remove a feature that was previously in X11 because it doesn't belong in the display server, you really need to figure out where it does belong and put it there, rather than just treating it as someone else's problem.

Happy to see this emerge

Posted Jun 24, 2026 22:05 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

None of those features were problematic as such (i.e. there's nobody seriously arguing that "you should not be allowed to configure your keyboard to map Caps Lock to Esc or Ctrl," aside from a few strident GNOME people who are thankfully irrelevant to this article about Xfce). They may have been problematic as X11 features specifically, but that is exactly what I meant by "architectural or infrastructure reasons." The proper solution was to migrate those features from the X server to some other part of the DE, not to rip them out entirely and pretend they never existed.

Happy to see this emerge

Posted Jun 24, 2026 9:09 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (17 responses)

The problem is that input and localization were totally inadequate under X11, leading to the creation of an horrific amount of *partial* *incompatible* workarounds (ie one could fix some extremely specific use cases, at the expense of all others).

The Wayland authors (most of which used to maintain the old totally inadequate mess) tried to streamline the situation to recover maintainability, but sort of stopped half way, due to the pressure of shipping something, and probably under the influence of their allies Gnome-side (perfect is the enemy of good, just forbid all the use cases we do not care about, like HiDPI was forbidden till market pressure made everything is 96dpi untenable).

Input in Wayland is a lot better than in X11 but (for example) the streamlining did not go as far as dissociating input methods from locale (state of the art in Microsoft Office circa 1995, then generalised at the OS level), dissociating date formats from locale (which is why Linux is state of the art UTF-8 side but unable to adopt same-epoch ISO 8601 = rfc 3339) nor providing a clear architectural nexus for all the input behaviour fine tuning some were used to. To be clear X11 did not provide this nexus either is was all hacked and workarounded over time.

But Emojis and multimedia keys work fine in Wayland. The streamlining was sufficient to fix this use case.

Happy to see this emerge

Posted Jun 24, 2026 12:20 UTC (Wed) by pizza (subscriber, #46) [Link] (14 responses)

> Input in Wayland is a lot better than in X11 but (for example) the streamlining did not go as far as dissociating input methods from locale (state of the art in Microsoft Office circa 1995, then generalised at the OS level), dissociating date formats from locale (which is why Linux is state of the art UTF-8 side but unable to adopt same-epoch ISO 8601 = rfc 3339)

WTF do input methods, locales, and *date formats* have to do with the display server?

These aren't part of the display subsystem in Windows either; these all live at the Windows equivalent of GNOME/KDE there too.

Happy to see this emerge

Posted Jun 24, 2026 13:41 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (12 responses)

Shows you do not have the faintest idea what Wayland (and X11 for that matter) are. A computer is not a dumb tv. The “display server” is not just displaying, it is orchestrating the input flow to apps, and orchestrating the output flow (display but also sound) apps emit in response to this output. It’s not just about producing the perfect display, it’s about producing the perfect display in response to user input.

One of the main reasons X11 had to be abandoned, back when Wayland was codenamed X12, for example, was that the X11 core protocol allocated a single byte for key codes which broke in a major way when globalization and multimedia keys became a thing and HID could not be shoved into the legacy protocol (you could, exactly like for legacy 8bit encodings, try to define custom mappings that hopefully dropped enough parts to fit). And then you had the unpleasant malware reality where you really did not want any random app spying on the input provided to the banking app.

Wayland is all about trying to untangle legacy output *and* input, when the general co-mingling baked into X11 could not cope with new realities. Unfortunately some of the untangling is not finished yet.

Happy to see this emerge

Posted Jun 24, 2026 14:40 UTC (Wed) by pizza (subscriber, #46) [Link] (11 responses)

> It’s not just about producing the perfect display, it’s about producing the perfect display in response to user input.

Again, what does that have to do with locales and stuff like date/time presentation?

Wayland doesn't give two hoots about languages or fonts or text rendering or time formats; interpreting and displaying that (in repsonse to user input) is up to the application (and/or the frameworks said applications use) to render their output. Wayland is only concerned with getting the application's rendered pixmap to the display (and accurately representing the display capabilities)

Yes, input is the other side of the same coin, but like output, Wayland's input path is a mostly dumb relay of input events from a specific set of input hardware [*] to a specific application. Interpreting those events is up to the application (and/or frameworks).

[*] There's no inherent reason why it has to be "hardware", it's just a stream of logical events. Higher-level input methods (CJK, OSKs, etc) that inject said events into applications have been deployed for a long time now.

Happy to see this emerge

Posted Jun 24, 2026 15:45 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (10 responses)

A dumb relay of events is useless without a clear definition of what those events are. Before the dumb relay part there *is* either a negociation at the wayland protocol level, or an unambiguous specification at the wayland protocol level, of what is relayed. Users really do not like if the same event produces different things in different apps, regardless of their DE or toolkit. Users do not want to reconfigure their input each time the display server selects a new surface. Something that emits “A” should be relayed as “A” to every app, regardless of what this app makes of “A” (and “A” is the simple case, because of ASCII).

The Wayland project consisted of untangling many things that were baked into the X11 server, including font rendering since you want to take that example, and coordinating those things via the wayland protocol and its extensions. All those untangled things, including those that ended up in a different subsystem than the display server itself, are part of the Wayland project. And it allowed display server people to focus on display things but the display server alone is no Wayland let alone an X11 replacement.

A Wayland environment can not select a modern date format because the Wayland project did not untangle the way glibc defines the date format and therefore it is not possible to negotiate a date format over the wayland protocol, just a glibc locale. And there is no point in redefining things at another level than wayland because users expect their dates to look the same in all apps. We are no longer in a world where all apps are launched in a shell terminal and are statically synchronized via shell environment variables.

Wayland is all the things that Microsoft had to bake into wslg to make gui apps work, and Wayland limitations and deficiencies show for example when it is mightily hard to convince wslg to use the correct locale and input method. The nice thing about wslg is that the host environment is free of all the legacy X11/terminal stuff, that obscures where Wayland is unfinished and relies on something else to sort of work.

Locales and Wayland

Posted Jun 24, 2026 16:18 UTC (Wed) by farnz (subscriber, #17727) [Link] (6 responses)

I'm looking at the list of Wayland protocols, going through them one-by-one, and I haven't yet found a single protocol that lets you share a date format or locale name (like X11, this is outside the display server remit).

What Wayland does get right is that the core protocol is (a) much more limited than X11's, and (b) does not have singletons for anything that represents hardware, where X11 core has a single keyboard, pointer etc.

Locales and Wayland

Posted Jun 25, 2026 12:21 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (1 responses)

Which is why I stated Wayland is unfinished and as soon as you remove the out of band glue you get users (be it WSLG or X11 users) that ask WTF is the setxkbmap equivalent. Wayland fixed the 8bit limitation of the X11 core protocol but forgot to implement the associated control plane.

Locales and Wayland

Posted Jun 25, 2026 13:38 UTC (Thu) by farnz (subscriber, #17727) [Link]

It wasn't forgotten about - Wayland explicitly chose not to put any control plane into the core, because part of what has not aged at all well in X11 is the assumptions made by the control plane.

Instead, the expectation is that if there's a common control plane that makes sense for today's compositors, and that should be part of the Wayland protocol, compositors will get together and put up a common Wayland extension for that control plane. And then, because it's an extension, if the world changes underneath us such that the control plane is wrong, support for that extension can be dropped.

Remember that a big part of the X11 lesson (as compared to previous iterations of the X Window System) is that protocol extensions are what give you longevity - as a matter of practicality, people are very happy to agree that you need to implement more than just the core protocol to get an acceptable system (e.g. XKB, and MIT-SHM are pretty much required on modern desktops, and some applications require XInputExtension if you want decent support for drawing tablets), so the more that can be moved out of core, the better - nobody remembers PHIGS any more, and because the X11 support for PHIGS was an extension, it just doesn't get implemented.

Locales and Wayland

Posted Jun 27, 2026 14:58 UTC (Sat) by anton (subscriber, #25547) [Link] (3 responses)

X11 core has a single keyboard, pointer etc.

Some months ago I used a keyboard with US layout connected to a laptop with a keyboard with German layout. I wanted each key on each keyboard to send the character it shows on the key. When I researched how to achieve that, I found that there is a solution for that for X11, but not for Wayland (sorry, details evade me). Unfortunately, the laptop runs a relatively recent Ubuntu with Wayland, so I had to switch the layout explicitly everytime I switched the keyboard, which was extremely annoying.

Locales and Wayland

Posted Jun 28, 2026 9:36 UTC (Sun) by farnz (subscriber, #17727) [Link] (2 responses)

There's an X11 solution that works for applications that use the right set of X11 extensions, but not applications that use core protocol - core protocol requires that you have one keyboard with one keymap.

On Wayland, the core protocol supports this directly, and it's a matter for compositor implementers to care about - so far, they haven't.

Locales and Wayland

Posted Jun 29, 2026 13:56 UTC (Mon) by anton (subscriber, #25547) [Link] (1 responses)

Could it be that it's easier to use the right set of X11 extensions that the appropriate part of the Wayland core protocol?

One other thing I wonder about is whether the Wayland design does not throw too much responsibility over the wall to the compositor developer, rather than having a design where such things could be added independently of the compositor. Admittedly, I have very little idea about the design of Wayland and not that much more about the design of X11.

Locales and Wayland

Posted Jun 29, 2026 14:45 UTC (Mon) by farnz (subscriber, #17727) [Link]

The X11 design and the Wayland design are, in many ways, very similar - it's just that where X11 requires a large amount of IPC between the compositor, the window manager, and the X server, Wayland integrates those into a single entity called the "compositor".

And using the appropriate part of the Wayland core protocol is as simple as the X11 solution where everyone agrees to use the modern Xi2 extension instead of X11 core, just without the risk of a client that only supports X11 core coming along.

Happy to see this emerge

Posted Jun 25, 2026 9:10 UTC (Thu) by daniels (subscriber, #16193) [Link] (2 responses)

> A Wayland environment can not select a modern date format because the Wayland project did not untangle the way glibc defines the date format and therefore it is not possible to negotiate a date format over the wayland protocol, just a glibc locale. And there is no point in redefining things at another level than wayland because users expect their dates to look the same in all apps.

Why duplicate this in Wayland, instead of fixing glibc to provide something sufficient?

By that measure, is Wayland insufficient because it doesn't provide a universal file-access API, or network access mediation to enforce parental controls?

Happy to see this emerge

Posted Jun 25, 2026 12:44 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (1 responses)

> Why duplicate this in Wayland, instead of fixing glibc to provide something sufficient?

Mostly because the date format is a lot more important to the GUI environment (where a human reads the date) than in the low-level stuff glibc cares about. The improvements in graphical environments have sort of moved localization responsibility from the TUI to the GUI. There is less and less incentive to localize the terminal, we are slowly moving to a world where people are giving up on localizing the TUI because technical TUI users can live with C.UTF-8.

Happy to see this emerge

Posted Jun 25, 2026 18:53 UTC (Thu) by pizza (subscriber, #46) [Link]

> Mostly because the date format is a lot more important to the GUI environment (where a human reads the date) than in the low-level stuff glibc cares about.

It's important _everywhere_ a human could read the date. All UIs matter.

And arguably more important when a human doesn't -- Data interchange requires that specific locale-independent formats are used (eg ISO8601)

Happy to see this emerge

Posted Jun 24, 2026 15:03 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

Nothing. They accreted in X11 by default, because it was the most convenient place to dump the code, not because they actually belonged there.

Happy to see this emerge

Posted Jun 25, 2026 9:07 UTC (Thu) by daniels (subscriber, #16193) [Link] (1 responses)

The parent comment to this is absolutely correct (only took 15 years and we got a balanced take, nice).

It's also true that we did try to streamline a bunch of things to recover maintainability and basic functionality. It's not true that GNOME 'allies' tried to stymie better or more complete accessibility support. If you look at the (old, terrible, but still the only functional one we have) accessibility stack that Linux relies on, well, all of that came from GNOME - mostly back when Sun cared about the desktop.

Most everyone wanted a good and complete a11y story, but no-one stepped up to fill the gap. A lot of us didn't have the expertise required to design something useful, nor the time to spend a couple of years learning. The desktop-focused corporate contributors we'd expected to fill the gap, for whatever reason, didn't. So here we are with a broken stack, a couple of super-promising but abandoned efforts to properly fix it from the ground up in a way that also works for browsers, people who rely on a11y technology (or even just 'complex' input methods full stop) being frustrated that nothing works, and the people who built the thing originally sad that nothing ever came to pass.

It's not that multimedia keys were deemed more important than proper CJK support, or assistive input or whatever: it's that the people who were there at the time were perfectly capable of doing one but not the other. Rightly or wrongly, we felt that we'd be doing people a disservice to try, because what we'd create would be so terrible that it was better to leave a void for someone to step into.

Equally, the 'HiDPI was forbidden because of GNOME' is a weird take. It wasn't there originally because we had a million other things to get working. Eventually, the first cut of HiDPI support which served us for a good 10 years or so, was contributed by a GNOME developer.

(source: input in Wayland is mostly my fault, but I've not worked on input for a very long time)

Happy to see this emerge

Posted Jun 25, 2026 13:02 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

> It's not that multimedia keys were deemed more important than proper CJK support, or assistive input or whatever: it's that the people who were there at the time were perfectly capable of doing one but not the other.

Sorry, I didn’t imply it was (just thoroughly sick of all the people that insist that since they can display their fav emogi mission is accomplished). I also understand that people want to scratch their own itches. Just very sad that the enormous amount of volunteer localization work, that we see everyday in all the floss apps we use, did not make fixing the localization infrastructure completely a wayland priority.

Thank you for the work you did on wayland input (even if it is unfinished;)

Happy to see this emerge

Posted Jun 24, 2026 19:49 UTC (Wed) by tuna (guest, #44480) [Link]

People who create new or updated software and shares it with you and me are not forcing us to use that software. You can always continue using the old software that they shared with us if you want to. Or you can use something else.

Happy to see this emerge

Posted Jun 29, 2026 10:38 UTC (Mon) by jengelh (subscriber, #33263) [Link] (1 responses)

>you are de facto "forced" into one of four options:
>
>1. Fork it. / For most Linux end users, is not a realistic option - DEs are far too complex
>4. Stop using a GUI on Linux. / probably feasible for a lot of users, but not a helpful answer

I see the good things in #1/#4: Complex software naturally dies out and hopefully is replaced by something more composable. I still remember fvwm2/mwm/twm/icewm.

Happy to see this emerge

Posted Jun 29, 2026 10:53 UTC (Mon) by pizza (subscriber, #46) [Link]

> I see the good things in #1/#4: Complex software naturally dies out and hopefully is replaced by something more composable. I still remember fvwm2/mwm/twm/icewm.

....The entire history of computing disagrees with you.

Already pretty great

Posted Jun 22, 2026 17:55 UTC (Mon) by jmalcolm (subscriber, #8876) [Link]

I have been using this on an old laptop for a few weeks and it has been completely stable. It is already better than running something like labwc if you want to use XFCE on Wayland.

It requires a couple of pre-release XFCE libraries but otherwise I have been using it with all the stable XFCE 4.20 components and it has been working great.