>The goal is, that xfwl4 will offer the same functionality and behavior as xfwm4 does...
I wonder how strictly they interpret behavior here given the architectural divergence?
As an example, focus-stealing prevention. In xfwm4 (and x11 generally), this requires complex heuristics and timestamp checks because x11 clients are powerful and can aggressively grab focus. In wayland, the compositor is the sole arbiter of focus, hence clients can't steal it, they can only request it via xdg-activation. Porting the legacy x11 logic involves the challenge of actually designing a new policy that feels like the old heuristic but operates on wayland's strict authority model.
This leads to my main curiosity regarding the raw responsiveness of xfce. On potato hardware, xfwm4 often feels snappy because it can run as a distinct stacking window manager with the compositor disabled. Wayland, by definition forces compositing. While I am not concerned about rust vs C latency (since smithay compiles to machine code without a GC), I am curious about the mandatory compositing overhead. Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?
> I wonder how strictly they interpret behavior here given the architectural divergence?
It's right there in the rest of the sentence (that you didn't quote all of): "... or as much as possible considering the differences between X11 and Wayland."
I'll do my best. It won't be exactly the same, of course, but it will be as close as I can get it.
> As an example, focus-stealing prevention.
Focus stealing prevention is a place where I think xfwl4 could be at an advantage over xfwm4. Xfwm4 does a great job at focus-stealing prevention, but it has to work on a bunch of heuristics, and sometimes it just does the wrong thing, and there's not much we can do about it. Wayland's model plus xdg-activation should at least make the focus-or-don't-focus decision much more consistent.
> I am curious about the mandatory compositing overhead. Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?
I'm not sure yet, but I suspect your fears are well-founded here. On modern (and even not-so-modern) hardware, even low-end GPUs should be fine with all this (on my four-year-old laptop with Intel graphics, I can't tell the difference performance-wise with xfwm4's compositor on or off). But I know people run Xfce/X11 on very-not-modern hardware, and those people may unfortunately be left behind. But we'll see.
At least they are honest regarding the reasons, not a wall of text to justify what bails down to "because I like it".
Naturally these kinds of having a language island create some attrition regarding build tooling, integration with existing ecosystem and who is able to contribute to what.
So lets see how it evolves, even with my C bashing, I was a much happier XFCE user than with GNOME and GJS all over the place.
You know that all the Wayland primitives, event handling and drawing in gnome-shell are handled in C/native code through Mutter, right ?
The JavaScript in gnome-shell is the cherry on top for scripting, similar to C#/Lua (or any GCed language) in game engines, elisp in Emacs, event JS in QtQuick/QML.
It is not the performance bottleneck people seem to believe.
> ...or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?
I think I know what "frame perfect" means, and I'm pretty sure that you've been able to get that for ages on X11... at least with AMD/ATi hardware. Enable (or have your distro enable) the TearFree option, and there you go.
I read somewhere that TearFree is triple buffering, so -if true- it's my (perhaps mistaken) understanding that this adds a frame of latency.
> I read somewhere that TearFree is triple buffering, so -if true- it's my (perhaps mistaken) understanding that this adds a frame of latency.
True triple buffering doesn't add one frame of latency, but since it enforces only whole frames be sent to the display instead of tearing, it can cause partial frames of latency. (It's hard to come up with a well-defined measure of frame latency when tearing is allowed.)
But there have been many systems that abused the term "triple buffering" to refer to a three-frame queue, which always does add unnecessary latency, making it almost always the wrong choice for interactive systems.
I don't know what "workarounds" you're talking about, or what unwanted behavior that I presume you're talking about. Would you be more specific?
I ask because just a few minutes ago, I ran VRRTest [0] on my dual-monitor machine and saw no screen tearing on either monitor. Because VRR is disabled in multi-monitor setups, I saw juddering on both monitors when I commanded VRRTest render rates that weren't a multiple of the monitor's refresh rate, but no tearing at all.
My setup:
* Both monitors hooked up via DisplayPort
* Radeon 9070 (non-XT)
* Gentoo Linux, running almost all ~amd64 packages.
* x11-base/xorg-server-21.1.20
* x11-drivers/xf86-video-amdgpu-25.0.0-r1
* x11-drivers/xf86-video-ati-22.0.0
* sys-kernel/gentoo-sources-6.18.5
* KDE and Plasma packages are either version 6.22.0 or 6.5.5. I CBA to get a complete list, as there are so many relevant packages.
(I'm posting in a reply in part because the edit window is long since past.)
Yeah. I'm actually quite interested in hearing what "workarounds" and/or misbehavior you're talking about. 'amdgpu(4)' says this about the TearFree property:
Option "TearFree" "boolean"
Set the default value of the per-output ’TearFree’ property,
which controls tearing prevention using the hardware page flip‐
ping mechanism. TearFree is on for any CRTC associated with one
or more outputs with TearFree on. Two separate scanout buffers
need to be allocated for each CRTC with TearFree on. If this op‐
tion is set, the default value of the property is ’on’ or ’off’
accordingly. If this option isn’t set, the default value of the
property is auto, which means that TearFree is on for rotated
outputs, outputs with RandR transforms applied, for RandR 1.4
secondary outputs, and if ’VariableRefresh’ is enabled, otherwise
it’s off.
The explicit mention that the "auto" enables TearFree only for secondary outputs and rotated and/or transformed outputs if 'VariableRefresh' is disabled seems to directly contradict what I think you're saying. And if "auto" enables TearFree on secondary displays, my recommendation of "on" certainly also does. But, yeah. I await clarification.
One thing to keep in mind is that composition does not mean you have to do it with vsync, you can just refresh the screen the moment a client tells you the window has new contents.
Compositor overhead even with cheapo Intel laptop graphics is basically a non-issue these days. The people still rocking their 20 year old thinkpads might want to choose something else, but besides that kind of user I don't think it's worth worrying too much about.
It isn't always pure overhead, but also jitter, additional delays and other issues caused by the indirection. Most systems have a way to mostly override the compositor for fullscreen windows and for games and other applications where visible jitter and delays are an issue you want that even on modern hardware.
> Most systems have a way to mostly override the compositor for fullscreen windows and for games
No, they don't. I don't think Wayland ever supported exclusive fullscreen, MacOS doesn't, and Windows killed it a while back as well (in a Windows 10 update like 5-ish years ago?)
Jitter is a non-issue for things you want vsync'd (like every UI), and for games the modern solution is gsync/freesync which is significantly better than tearing.
Isn't that true for even the most basic features you expect from a windowing system? X11 may have come with everything and the kitchen sink, Wayland drops all that fun on the implementations.
They replaced it with "Fullscreen Optimisations", which is mostly the same, but more flexible as leaves detection of fullscreen exclusive windows to the window manager.
In both the GNOME and Windows "Fullscreen Optimizations" it's the compositor doing an internal optimzation to avoid a copy when it's not necessary. In neither scenario is the system nor applications "overriding" or bypassing the compositor. The compositor still has exclusive ownership of the display. And the application's swapchain is still configured as if it was going through a composition pass (eg, it's probably not double-buffered)
"Fullscreen Optimisations" is how X11 has always worked.
Window's actual exclusive fullscreen always caused tons of issues with Alt+TAB because it was designed for a time when you couldn't fit both a game and the desktop in VRAM.
X11 doesn't have an exclusive fullscreen mode either. [*] It's always has relied on compositors and drivers to detect when fullscreen windows can be unredirected. Some programs chose to implement behavior like minimizing on focus loss or grabbing input that is closer to Windows's exclusive fullscreen mode but the unredirecting of the display pipeline doesn't depend on that.
[*] Well, there was an extension (can't recall the name right now) but not much used it and support was dropped at some point.
That matches what I recall too, back when I ran a very cheap integrated intel (at least that's what I recall) card on my underpowered laptop. I posted a few days ago with screenshots of my 2009 setup with awesome+xcompmgr, and I remember it being very snappy (much more so than my tuned Windows XP install at the time). https://news.ycombinator.com/item?id=46717701
> As an example, focus-stealing prevention. In xfwm4 (and x11 generally), this requires complex heuristics and timestamp checks because x11 clients are powerful and can aggressively grab focus. In wayland, the compositor is the sole arbiter of focus, hence clients can't steal it, they can only request it via xdg-activation. Porting the legacy x11 logic involves the challenge of actually designing a new policy that feels like the old heuristic but operates on wayland's strict authority model.
Not that that's necessarily the best way to do it but nothing stops xfwl4 from simply granting every focus request and then applying their existing heuristics on the result of that.
> Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?
I think this is ultimately correct. The compositor will have to render a frame at some point after the VBlank signal, and it will need to render with it the buffers on-screen as of that point, which will be from whatever was last rendered to them.
This can be somewhat alleviated, though. Both KDE and GNOME have been getting progressively more aggressive about "unredirecting" surfaces into hardware accelerated DRM planes in more circumstances. In this situation, the unredirected planes will not suffer compositing latency, as their buffers will be scanned out by the GPU at scanout time with the rest of the composited result. In modern Wayland, this is accomplished via both underlays and overlays.
There is also a slight penalty to the latency of mouse cursor movement that is imparted by using atomic DRM commits. Since using atomic DRM is very common in modern Wayland, it is normal for the cursor to have at least a fraction of a frame of added latency (depending on many factors.)
I'm of two minds about this. One, obviously it's sad. The old hardware worked perfectly and never had latency issues like this. Could it be possible to implement Wayland without full compositing? Maybe, actually. But I don't expect anyone to try, because let's face it, people have simply accepted that we now live with slightly more latency on the desktop. But then again, "old" hardware is now hardware that can more often than not, handle high refresh rates pretty well on desktop. An on-average increase of half a frame of latency is pretty bad with 60 Hz: it's, what, 8.3ms? But half a frame at 144 Hz is much less at somewhere around 3.5ms of added latency, which I think is more acceptable. Combined with aggressive underlay/overlay usage and dynamic triple buffering, I think this makes the compositing experience an acceptable tradeoff.
What about computers that really can't handle something like 144 Hz or higher output? Well, tough call. I mean, I have some fairly old computers that can definitely handle at least 100 Hz very well on desktop. I'm talking Pentium 4 machines with old GeForce cards. Linux is certainly happy to go older (though the baseline has been inching up there; I think you need at least Pentium now?) but I do think there is a point where you cross a line where asking for things to work well is just too much. At that point, it's not a matter of asking developers to not waste resources for no reason, but asking them to optimize not just for reasonably recent machines but also to optimize for machines from 30 years ago. At a certain point it does feel like we have to let it go, not because the computers are necessarily completely obsolete, but because the range of machines to support is too wide.
Obviously, though, simply going for higher refresh rates can't fix everything. Plenty of laptops have screens that can't go above 60 Hz, and they are forever stuck with a few extra milliseconds of latency when using a compositor. It is unideal, but what are you going to do? Compositors offer many advantages, it seems straightforward to design for a future where they are always on.
Love your post. So, don’t take this as disagreement.
I’m always a little bewildered by frame rate discussions. Yes, I understand that more is better, but for non-gaming apps (e.g. “productivity” apps), do we really need much more than 60 Hz? Yes, you can get smoother fast scrolling with higher frame rate at 120 Hz or more, but how many people were complaining about that over the last decade?
I enjoy working on my computer more at 144Hz than 60Hz. Even on my phone, the switch from 60Hz to a higher frame rate is quite obvious. It makes the entire system feel more responsive and less glitchy. VRR also helps a lot in cases where the system is under load.
60Hz is actually a downgrade from what people were used to. Sure, games and such struggled to get that kind of performance, but CRT screens did 75Hz/85Hz/100Hz quite well (perhaps at lower resolutions, because full-res 1200p sometimes made text difficult to read on a 21 inch CRT, with little benefit from the added smoothness as CRTs have a natural fuzzy edge around their straight lines anyway).
There's nothing about programming or word processing that requires more than maybe 5 or 6 fps (very few people type more than 300 characters per minute anyway) but I feel much better working on a 60 fps screen than I do a 30 fps one.
Everyone has different preferences, though. You can extend your laptop's battery life by quite a bit by reducing the refresh rate to 30Hz. If you're someone who doesn't really mind the frame rate of their computer, it may be worth trying!
It isn't equivelent in the sense that the progressive scanout on CRTs resulted in near-zero latency and with minimal image persistance, versus flat panels which are global refresh adding latency and worsening motion clarity. So it isn't really a "but", it's a "made even better by being rendered only one pixel/dot at a time".
Motion clarity yes, but it's zero latency in the least useful way possible, only true when you're rendering the top and bottom of the screen at different points in time. And scanout like that isn't unique to CRTs, many flat panels can do it too.
When rendering a full frame at once and then displaying it, a modern screen is not only able to be more consistent in timing, it might be able to display the full frame faster than a CRT. Let's say 60Hz, and the frame is rendered just in time to start displaying. A CRT will take 16 milliseconds to do scanout. But if you get a screen that supports Quick Frame Transport, it might send over the frame data in only 3 milliseconds, and have the entire thing displayed by millisecond 4.
I never complained about 60, then I went to 144 and 60 feels painful now. The latency is noticable in every interaction, not just gaming. It's immediately evident - the computer just feels more responsive, like you're in complete control.
Even phones have moved in this direction, and it's immediately noticable when using it for the first time.
I'm now on 240hz and the effect is very diminished, especially outside of gaming. But even then I notice it, although stepping down to 144 isn't the worst. 60, though, feels like ice on your teeth.
Did you use the same computer at both 60 and 144? I have no doubt that 144 feels smoother for scrolling and things like that. It definitely should. But if you upgraded your system at the same time you upgraded your display, much of the responsiveness would be due to a faster system.
I have a projector that can project 4k at 60hz or 1080p at 240, and I can really notice it by just moving the cursor around. I don’t need to render my games anywhere near 240 to notice that too. Same with phones - moving from pixel 3 to pixel 5, scrolling through settings or the home screen was a palpable difference. Pixel 3 now feels broken. It is not.m, it just renders at 60 instead of 90 fps.
Yes same system, then again at 240hz. Realistically I think just about any modern GPU can composite at 240 fps, although I see what you mean if I did an SSD upgrade or something, but I didn't.
> how many people were complaining about that over the last decade?
Quite a few. These articles tend to make the rounds when it comes up: https://danluu.com/input-lag/https://lwn.net/Articles/751763/ Perception varies from person to person, but going from my 144hz monitor to my old 60hz work laptop is so noticeable to me that I switched it from a composited wayland DE to an X11 WM.
Input lag is not the same as refresh rate. 60 Hz is 16.7 ms per frame. If it takes a long time for input to appear on screen it’s because of the layers and layers of bloat we have in our UI systems.
Refresh rate directly affects one of the components of total input lag, and increasing refresh rate is one of the most straightforward ways for an end user to chip away at that input lag problem.
If our mouse cursors are going to have half a frame of latency, I guess we will need 60Hz or 120Hz desktops, or whatever.
I dunno. It does seem a bit odd, because who was thinking about the framerates of, like, desktops running productivity software, for the last couple decades? I guess I assumed this would never be a problem.
Mouse cursor latency and window compositing latency are two separate things. I probably did not do a good enough job conveying this. In a typical Linux setup, the mouse cursor gets its own DRM plane, so it will be rendered on top of the desktop during scanout right as the video output goes to the screen.
There are two things that typically impact mouse cursor latency, especially with regards to Wayland:
- Software-rendering, which is sometimes used if hardware cursors are unavailable or buggy for driver/GPU reasons. In this case the cursor will be rendered onto the composited desktop frame and thus suffer compositor latency, which is tied to refresh rate.
- Atomic DRM commits. Using atomic DRM commits, even the hardware-rendered cursors can suffer additional latency. In this case, the added latency is not necessarily tied to frame times or refresh rates. Instead, its tied to when during the refresh cycle the atomic commit is sent; specifically, how close to the deadline. I think in most cases we're talking a couple milliseconds of latency. It has been measured before, but I cannot find the source.
Wayland compositors tend to use atomic DRM commits, hence a slightly more laggy mouse cursor. I honestly couldn't tell you if there is a specific reason why they must use atomic DRM, because I don't have knowledge that runs that deep, only that they seem to.
Mouse being jumpy shouldn’t be related to refresh rate. The mouse driver and windowing system should keep track of the mouse position regardless of the video frame rate. Yes, the mouse may jump more per frame with a lower frame rate, but that should only be happening when you move the mouse a long distance quickly. Typically, when you do that, you’re not looking at the mouse itself but at the target. Then, once you’re near it, you slow down the movement and use fine motor skills to move it onto the target. That’s typically much slower and frame rate won’t matter much because the motion is so much smaller.
Initially I wrote “input device”, but since mouse movements aren’t generally a problem, I narrowed it to “keyboard”. ;) Mouse clicks definitely fall into the same category, though.
Essentially, the only reason to go over 60 Hz for desktop is for a better "feel" and for lower latency. Compositing latency is mainly centered around frames, so the most obvious and simplest way to lower that latency is to shorten how long a frame is, hence higher frame rates.
However, I do think that high refresh rates feel very nice to use even if they are not strictly necessary. I consider it a nice luxury.
I couldn't find ready stats on what percentage of displays are 60 hz but outside of gaming and high end machines I suspect 60 hz is still the majority of of machines used by actual users meaning we should evaluate the latency as it is observed by most users.
The point is that we can improve latency of even old machines by simply attaching a display output that supports a higher refresh rate, or perhaps even variable refresh rate. This can negate most of the unavoidable latency of a compositor, while other techniques can be used to avoid compositor latency in more specific scenarios and try to improve performance and frame pacing.
A new display is usually going to be cheaper than a new computer. Displays which can actually deliver 240 Hz refresh rates can be had for under $200 on the lower end, whereas you can find 180 Hz displays for under $100, brand new. It's cheap enough that I don't think it's even terribly common to buy/sell the lower end ones second-hand.
For laptops, well, there is no great solution there; older laptops with 60 Hz panels are stuck with worse latency when using a compositor.
Plenty of brand new displays are still sold that only go up to 60hz, especially if you want high quality IPS panels.
They aren't as common now, but when making a list of screens to replace my current one, I am limiting myself to IPS panels and quite a few of the modern options are still 60hz.
Yeah, I personally still have a lot of 60 Hz panels. One of my favorites is a 43" 4K IPS. I don't think I will be able to get that at 120+ Hz any time soon.
Of course, this isn't a huge deal to me. The additional latency is not an unusable nightmare. I'm just saying that if you are particularly latency sensitive, it's something that you can affordably mitigate even when using a compositor. I think most people have been totally fine eating the compositor latency at 60 Hz.
> Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?
well, the answer is just no, wayland has been consistently slower than X11 and nothing running on top can't really go around that
Can you cite any sources for that claim? I found this blog post that says wayland is pretty much on par with X11 except for XWayland, which should be considered a band-aid only anyways: https://davidjusto.com/articles/m2p-latency/
I hope that XFCE remains a solid lightweight desktop option. I've become a huge fan of KDE over the past couple of years, but it certainly isn't what you would consider lightweight or minimal.
Personally, I'm a big proponent of Wayland and not big Rust detractor, so I don't see any problem with this. I do, however, wonder how many long-time XFCE fans and the folks who donated the money funding this will feel about it. To me the reasoning is solid: Wayland appears to be the future, and Rust is a good way to help avoid many compositor crashes, which are a more severe issue in Wayland (though it doesn't necessarily need to be fatal, FWIW.) Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary.
Of course, if they made the right choice, it should be apparent in relatively short order, so I wish them luck.
> Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary.
Very long time (since 2007) XFCE user here. I don't think this is accurate. We want things to "just work" and not change for no good reason. Literally no user cares what language a project is implemented in, unless they are bored and enjoy arguing about random junk on some web forum. Wayland has the momentum behind it, and while there will be some justified grumbling because change is always annoying, the transition will happen and will be fairly painless as native support for it continues to grow. The X11 diehards will go the way of the SysV-init diehards; some weird minority that likes to scream about the good old days on web forums but really no one cares about.
There are good reasons to switch to Wayland, and I trust the XFCE team to handle the transition well. Great news from the XFCE team here, I'm excited for them to pull this off.
I used XFCE for a long time and I very much agree. it just works, and is lightweight. I use KDE these days but XFCE would be my second choice.
> The X11 diehards will go the way of the SysV-init diehard
I hope you are not conflating anti-systemD people with SysV init diehards? As far as I can see very few people want to keep Sysv init, but there are lots who think SystemD init is the wrong replacement, and those primarily because its a lot more than an init system.
In many ways the objects are opposite. People hate system D for being more than init, people hate Wayland for doing less than X.
Edit: corrected "Wayland" to "XFCE" in first sentence!
Not sure I agree here, assuming you mean "... than X11". With Wayland, you put your display code, input-handling code, compositor code, session-handling code, and window-management code all in the same process. (Though there is a Wayland protocol being worked on to allow moving the WM bits out-of-process.)
With X11, display and input-handling are in the X server, and all those other functions can be in other processes, communicating over standard interfaces.
> you put your display code, input-handling code, compositor code, session-handling code, and window-management code all in the same process
That's an implementation detail. You can absolutely separate one out from the other and do IPC - it just doesn't make much sense to do so for most of these.
The only one where I see it making sense is the window manager, which can simply be an extension/plugin either in a scripting language or in wasm or whatever.
It's not an implementation detail that X11 specifies interfaces between those separate components and Wayland does not - X11 is designed for for the window manager being separate from the display server, Wayland is designed for them being the same.
I do not have a strong opinion about Xorg vs Wayland. My only real concern is that it might make it harder for the BSDs but that seems to be being dealt with. I do like being able to use X over the nextwork but that is a problem that can be solved.
I do dislike System D for two reasons. One is exactly because it s a monolith and, in effect, an extension of the OS. The other is the attitude of the developers which becomes very evident if you browser the issues.
How is Wayland more modular? It conflates the window manager, the compositor, and the display server, all into a single component that must be replaced as a single unit. This kind of new conflation is exactly what people dislike about systemd.
It's less monolithic in the sense that instead of one creaky unmaintainable ancient mass of software doing the actual rendering gruntwork there are now five (and counting) somewhat incompatible slick untested new masses of software doing it in slightly different ways that application developers have to worry about. It's kind of a pick your poison situation.
IME it's always best to read any claims of "unmaintainable" as "not as fun as designing something new". Nothing is truly unmaintainable if the will is there.
I know OpenBSD's fork of it is being maintained just fine even though they've declared it feature-complete (which for some reason is anathema to a lot of people).
If Rust has one weakness right now, it's bindings to system and hardware libraries. There's a massive barrier in Rust communicating with the outside ecosystem that's written in C. The definitive choice to use Rust and an existing Wayland abstraction library narrows their options down to either creating bindings of their own, or using smithay, the brand new Rust/Wayland library written for the Cosmic desktop compositor. I won't go into details, but Cosmic is still very much in beta.
It would have been much easier and cost-effective to use wlroots, which has a solid base and has ironed out a lot of problems. On the other hand, Cosmic devs are actively working on it, and I can see it getting better gradually, so you get some indirect manpower for free.
I applaud the choice to not make another core Wayland implementation. We now have Gnome, Plasma, wlroots, weston, and smithay as completely separate entities. Dealing with low-level graphics is an extremely difficult topic, and every implementor encounters the same problems and has to come up with independent solutions. There's so much duplicated effort. I don't think people getting into it realize how deceptively complex and how many edge-cases low-level graphics entails.
> using smithay, the brand new Rust/Wayland library
Fun fact: smithay is older than wlroots, if you go by commit history (January 2017 vs. April 2017).
> It would have been much easier and cost-effective to use wlroots
As a 25+ year C developer, and a ~7-year Rust developer, I am very confident that any boost I'd get from using wlroots over smithay would be more than negated by debugging memory management and ownership issues. And while wlroots is more batteries-included than smithay, already I'm finding that not to be much of a problem, given that I decided to base xfwl4 on smithay's example compositor, and not write one completely from scratch.
Thanks for the extra info. I'm glad it hasn't turned out to be much of an issue. I've looked at your repository and it seems to be off to a great start.
Personally, I'm anxious to do some bigger rust projects, but I'm usually put off by the lack of decent bindings in my particular target area. It's getting better, and I'm sure with some time the options will fill out more.
There really isn't a "massive barrier" to FFI. Autogenerate the C bindings and you're done. You don't have to wrap it in a safe abstraction, and imo you shouldn't.
This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem. Keeping the whole “it’s funded by the Government/Google etc” nonsense aside: I personally wish that at least a feeble attempt would be made to actually use the FFI capabilities that Rust and its ecosystem has before folks form an opinion. Personally - and I’m not ashamed to state that I’m an early adopter of the language - it’s very good. Please consider that the Linux kernel project, Google, Microsoft etc went down the Rust path not on a whim but after careful analysis of the pros and cons. The pros won out.
> This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem.
I have done it and it left a bad taste in my mouth. Once you're doing interop with C you're just writing C with Rust syntax topped off with a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer. It's unergonomic and you lose the differentiating features of Rust. Writing safe bindings is painful, and using community written ones tends to pull in dozens of dependencies. If you're interfacing a C library and want some extra features there are many languages that care far more about the developer experience than Rust.
> a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer
You just have to get over that. `unsafe` means "compiler cannot prove this to be safe." FFI is unsafe because the compiler can't see past it.
> Once you're doing interop with C you're just writing C with Rust syntax
Just like C++, or go, or anything else. You can choose to wrap it, but that's just indirection for no value imo. I honestly hate seeing C APIs wrapped with "high level" bindings in C++ for the same reason I hate seeing them in Rust. The docs/errors/usage are all in terms of the C API and in my code I want to see something that matches the docs, so it should be "C in syntax of $language".
> a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer
That's bizarrely emotional. It's a language feature that allows you to do things the compiler would normally forbid you from doing. It's there because it's sometimes necessary or expedient to do those things.
My point is that using C FFI is "the things the compiler would normally forbid you from doing" so if that's a major portion of your program then you're better off picking a different language. I don't dislike rust, but it's not the right tool for any project that relies heavily on C libraries.
> The X11 diehards will go the way of the SysV-init diehards; some weird minority
I upvoted your general response but this line was uncalled for. No need to muddy the waters about X11 -> Wayland with the relentlessly debated, interminable, infernal init system comparison.
> Literally no user cares what language a project is implemented in
This is only true most of the time - some languages have properties which "leak" to user.
Like if it's Java process, then sooner or later user will have to mess with launchers and -Xmx option.
Or if it's a process which has lots of code and must not crash, language matters. C or C++ would segfault on any sneeze. Python or Ruby or even Java would stay alive (unless they run out of memory, or hang due to a logic bug)
> The X11 diehards will go the way of the SysV-init diehards; some weird minority that likes to scream about the good old days on web forums but really no one cares about.
Being proud of how you are uncaring towards others is a sad state of affairs.
> Literally no user cares what language a project is implemented in
I think this is true but also maybe not true at the same time.
For one thing, programming languages definitely come with their own ecosystems and practices that are common.
Sometimes, programming languages can be applied in ways that basically break all of the "norms" and expectations of that programming language. You can absolutely build a bloated and slow C application, for example, so just using C doesn't make something minimal or fast. You can also write extremely reliable C code; sqlite is famously C after all, so it's clearly possible, it just requires a fairly large amount of discipline and technical effort.
Usually though, programs fall in line with the norms. Projects written in C are relatively minimal, have relatively fewer transitive dependencies, and are likely to contain some latent memory bugs. (You can dislike this conclusion, but if it really weren't true, there would've been a lot less avenues for rooting and jailbreaking phones and other devices.)
Humans are clearly really good at stereotyping, and pick up on stereotypes easily without instruction. Rust programs have a certain "feel" to them; this is not delusion IMO, it's likely a result of many things, like the behaviors of clap and anywho/Rust error handling leaking through to the interface. Same with Go. Even with languages that don't have as much of a monoculture, like say Python or C, I think you can still find that there are clusters of stereotypes of sorts that can predict program behavior/error handling/interfaces surprisingly well, that likely line up with specific libraries/frameworks. It's totally possible to, for example, make a web page where there are zero directly visible artifacts of what frameworks or libraries were used to make it. Yet despite that, when people just naturally use those frameworks, there are little "tells" that you can pick up on a lot of the time. You ever get the feeling that you can "tell" some application uses Angular, or React? I know I have, and what stuns me is that I am usually right (not always; stereotypes are still only stereotypes, after all.)
So I think that's one major component of why people care about the programming language that something is implemented in, but there's also a few others:
- Resources required to compile it. Rust is famously very heavy in this regard; compile times are relatively slow. Some of this will be overcome with optimization, but it still stands to reason that the act of compiling Rust code itself is very computationally expensive compared to something as simple as C.
- Operational familiarity. This doesn't come into play too often, but it does come into play. You have to set a certain environment variable to get Rust to output full backtraces, for example. I don't think it is part of Rust itself, but the RUST_LOG environment variable is used by multiple libraries in the ecosystem.
- Ease of patching. Patching software written in Go or Python, I'd argue, is relatively easy. Rust, definitely can be a bit harder. Changes that might be possible to shoehorn in in other languages might be harder to do in Rust without more significant refactoring.
- Size of the resulting programs. Rust and Go both statically link almost all dependencies, and don't offer a stable ABI for dynamic linking, so each individual Rust binary will contain copies of all of their dependencies, even if those dependencies are common across a lot of Rust binaries on your system. Ignoring all else, this alone makes Rust binaries a lot larger than they could be. But outside of that, I think Rust winds up generating a lot of code, too; trying to trim down a Rust wasm binary tells you that the size cost of code that might panic is surprisingly high.
So I think it's not 100% true to say that people don't care about this at all, or that only people who are bored and like to argue on forums ever care. (Although admittedly, I just spent a fairly long time typing this to argue about it on a forum, so maybe it really is true.)
I know, I know! Change is hard and scary. To be honest, while I am glad they're finally tackling this, I'm also expecting to have a pretty annoying couple of weeks whenever they ship this support and I finally decide to make the switch. There will be things to learn and new behaviors to understand and, yes, new bugs and annoyances to learn to work around. But I think if we both put our big boy pants on, keep a positive and friendly attitude, and help each other out, we can make it through these difficult times and come out the other side with proper high DPI support, sane multi-monitor handling and hot-swapping, and maybe even some wild new stuff like high color depth options.
Why does Wayland "feel like the future?" It feels like a regression to me and a lot of other people who have run into serious usability problems.
At best, it seems like a huge diversion of time and resources, given that we already had a working GUI. (Maybe that was the intention.) The arguments for it have boiled down to "yuck code older than me" from supposed professionals employed by commercial Linux vendors to support the system, and it doesn't have Android-like separation — a feature no one really wants.
The mantra of "it's a protocol" isn't very comforting when it lacks so many features that necessitate workarounds, leading to fragmentation and general incompatibility. There are plenty of complicated, bad protocols. The ones that survive are inherently "simple" (e.g., SMTP) or "trivial" (e.g., TFTP). Maybe there will be a successor to Wayland that will be the SMTP to its X400, but to me, Wayland seems like a past compromise (almost 16 years of development) rather than a future.
Wayland supports HDR, it's very easy to configure VRR, and it's fractional scaling (if implemented properly) is far superior to anything X11 can offer.
Furthermore, all of these options can be enabled individually on multiple screens on the same system and still offer a good mix-used environment. As someone who has been using HiDPI displays on Linux for the past 7 years, wayland was such a game changer for how my system works.
Fractional scaling for wayland is broken on a per app basis which feels strictly worse to me than it was before. Libre office currently is broken on wayland and works in x11
LibreOffice works for me on wayland lol. I don't know why you would wanna do fractional scaling on a per app basis whenever you got one screen. But, for your libreoffice woes, try using a different backend?
Which, because we're talking rendering and GPU and drivers, is incredibly frustrating, because if we're here, it's because the system doesn't have working GPU drivers, at which point, a misconfiguration is a crash and a power cycle and a "hope pstore managed to save something", and the hardware/software cursor settings getting lost somewhere-how.
I'm not trying to do it on a per app basis. I mean that some apps work and some don't. I should not be playing with rendering backends per app to get them working. If thats needed its broken.
People keep pushing KDE+Wayland to beginners either through recommendations or preconfigured stuff like bazzite. My experience is that the defaults in such a setup are broken and frustrating.
Even if you dislike Wayland, forwards-going development is clearly centred around it.
Development of X11 has largely ended and the major desktop environments and several mainstream Linux distributions are likewise ending support for it. There is one effort I know of to revive and modernize X11 but it’s both controversial and also highly niche.
You don’t have to like the future for it to be the future.
It's mostly coz nobody really wants to improve X11. I don't think there is many wayland features that would be impossible to implement in X11 it's just nobody wants to dig into crusty codebase to do it.
And sadly wayland decided to just not learn any lessons from X11 and it shows.
What do you mean nobody wants to improve X11? There were developers with dozens of open merge requests with numerous improvements to X11 that were being actively ignored/held back by IBM/Red Hat because they wanted Wayland, their corporate project, to succeed instead.
Reviewing PRs and merging them requires great effort, especially in case of a non-trivial behemoth like X. Surely if all these merge requests were of huge value, someone could have forked the project and be very happy with all the changes, right?
Not having enough maintainers, and some design issues that can't be solved are both reasons why X was left largely unmaintained.
> Surely if all these merge requests were of huge value
There were a lot of MRs with valuable changes however Red Hat wanted certain features to be exclusive to Wayland to make the alternative more appealing to people so they actively blocked these MRs from progressing.
> someone could have forked the project and be very happy with all the changes, right?
That's precisely what happened, one of the biggest contributors and maintainers got bullied by Red Hat from the project for trying to make X11 work and decided to create X11Libre (https://github.com/X11Libre/xserver) which is now getting all these fancy features that previously were not possible to get into X11 due to Red Hat actively sabotaging the project in their attempt to turn Linux into their own corporate equivalent of Windows/macOS.
We’re accustomed to "the future" connoting progress and improvement. Unfortunately, it isn’t always so (no matter how heavily implied). Just that it’s literally expected to be the future state if matters.
Wayland was the first display system on Linux I've used that just worked perfectly right out of the box on a bog standard Intel iGPU across several machines. I think that is a big draw for a lot of people like myself who just want to get things done. For me X11 represents the past through experience I had when I had to tinker with the X11 config file to get basic stuff like video playback to work smoothly without tearing. My first Wayland install was literally a "wow this is the future of Linux" for me quite honestly when I realised everything just worked without even a single line of config. I would recommend a Wayland distro like Debian to the average computer user knowing Wayland just works -- prior to Wayland I'd be like "well Linux is great but if you like watching YouTube you'll need to add a line to your xorg config to trun on the thingy that smoothes out video playback on Intel iGPUs". Appreciate others have different perpectives -- I come from the POV of someone who likes to install a OS and have all the basic stuff working out of the box.
It is many years, I guess close to a decade, since I needed to change X config manually. I still find the odd rough edge in Wayland (the most recent was failing screenshots with KDE).
This argument is actually backwards: one of the goals of the wayland project is to draw development away from X. If wayland didn't exist, people would have worked on X11 a lot more.
This question sounds to me like you suspect some outright evil getting projected here. That would go too far. The wayland project tried to get the support of X developers early so that they could become a sort of "blessed" X successor early on. Plenty of earlier replacement attempts have failed because they couldn't get bigger community support, so this had to be part of a successful strategy. Any detrimental effects on X from that move were never a direct goal, as far as I am aware, just a consequence.
This isn't quite right? Wayland was literally created by an X11 developer who got two more main X11 developers in. It's a second system, not a competitor as such.
Yes, I do interpret your “draw development away from X” as suggesting an attempt to damage X (sorry if I misinterpreted your post, but I do think my interpretation was not really that unreasonable).
This “blessed successor” without and detrimental effects as a main goal: that’s pretty close to my understanding of the project. IIRC some X people were involved from the beginning, right?
Wanting developers to switch projects doesn't have to be malicious, in fact personally i doubt there were any bad intentions in place, the developers of Wayland most likely think they're doing the right thing.
That’s a fork, which is fine. But for example, users from most mainstream distros will have to compile it themselves.
I guess we’ll see if that development is ever applied to the main branch, or if it supplants the main X branch. At the moment, though… if that’s the future of X, then it is fair to be a little bit unsure if it is going to stick, right?
That seems pretty interesting. I guess it relies on BSD plumbing though?
Funny enough, the my first foray into these sort of operating systems was BSD, but it was right when I was getting started. So I don’t really know which of my troubles were caused by BSD being tricky (few probably), and which were caused by my incompetence at the time (most, probably). One of these days I’ll try it again…
Yup, "pledge" is one of my BSD envies. Namespaces and unshare are significantly more complex and we're still told not to use them as a security barrier (which is explicitly in scope for pledge).
I've been on and off linux desktops since the advent of Wayland. Unsure of the actual issues people run into at this point outside of very niche workflows or applications, to which, there are X11 fallbacks for.
Also, by "commercial linux vendors", you do realize Wayland is directly supported (afaik, correct me if wrong) by the largest commercial linux contributors, Red Hat, Canoncial. They're not simply 'vendors'.
> Unsure of the actual issues people run into at this point outside of very niche workflows or applications, to which, there are X11 fallbacks for.
I don't know if others have experienced this but the biggest bug I see in Wayland right now is sometimes on an external monitor after waking the computer, a full-screen electron window will crash the display (ie the display disconnects).
I can usually fix this by switching to another desktop and then logging out and logging back in.
Such a strange bug because it only affects my external monitor and only affects electron apps (I notice it with VSCode the most but that's just cause I have it running virtually 24/7)
If anyone has encountered this issue and figured out a solution i am all ears.
This is probably worth reporting. I don't think I've ever heard or ran into something like that before. Most issues I ran into during the early rollout of Wayland desktop environments was broken or missing functionality in existing apps.
> it doesn't have Android-like separation — a feature no one really wants.
It's certainly a feature I want. Pretty sure I'm not alone in wanting isolation between applications--even GUI ones. There's no reason that various applications from various vendors shouldn't be isolated into their own sandboxes (at least in the common case).
There is a big reason: It impedes usability, extensibility and composability. If you sandbox GUI applications then the sandbox needs to add support for any interaction between them or they will just not be possible - and to fully support many advanced interactions like automation you will essentially have to punch huge holes in the sandbox anyway.
Meanwhile the advantages of sandboxing are pretty much moot in an open source distro where individual applications are open and not developed by user hostile actors.
Yes, sandboxing impedes those things. But I assume you're not advocating against sandboxing in general, right?
Starting with a sandbox and poking holes/whitelisting as-needed is a good way to go. Whitelisting access on a per-application basis is a pragmatic way to do this, and Flatpak with Wayland gives a way to actually implement this. It's imperfect, but it's a good start.
Preventing keylogging is a good, concrete example here. There's no reason some random application should be able to see me type out the master password in my password manager.
Likewise, there is no reason that some other application should be able to read ~/.bash_history or ~/.ssh/. The browser should limit itself to ~/Downloads. Etc.
> Meanwhile the advantages of sandboxing are pretty much moot in an open source distro where individual applications are open and not developed by user hostile actors.
Defense in depth. Belt and suspenders. I do trust the software I run to some degree, and take great care in choosing the software. But it's not perfect. Likewise, I take care to use sandboxing features whenever I can, acknowledging that they sometimes must have holes poked in them. But the Swiss cheese model is generally a good lens: https://en.wikipedia.org/wiki/Swiss_cheese_model
If we weren't concerned with belt and suspenders and could rely on applications being developed by non-hostile actors, then we could all run as root all the time! But we don't do that--we try to operate according to least-privilege and isolate separate tasks as much as is practical. Accordingly, technologies which allow improved isolation with zero or minimal impact to functionality are strictly a good thing, and should be embraced as such.
> given that we already had a working GUI. (Maybe that was the intention.)
Neither X11 nor Wayland provide a GUI. Your GUI is provided by GTK or QT or TCL or whatever. X11 had primitive rendering instructions that allowed those GUIs to delegate drawing to a central system service, but very few things do that anymore anyway. Meaning X11 is already just a dumb compositor in practice, except it's badly designed to be a dumb compositor because that wasn't its original purpose. As such, Wayland is really just aligning the protocol to what clients actually want & do.
- Having a single X server that almost everyone used lead to ossification. Having Wayland explicitly be only a protocol is helping to avoid that, though it comes with its own growing pains.
- Wayland-the-Protocol (sounds like a Sonic the Hedgehog character when you say it like that) is not free of cruft, but it has been forward-thinking. It's compositor-centric, unlike X11 which predates desktop compositing; that alone allows a lot of clean-up. It approaches features like DPI scaling, refresh rates, multi-head, and HDR from first principles. Native Wayland enables a much better laptop docking experience.
- Linux desktop security and privacy absolutely sucks, and X.org is part of that. I don't think there is a meaningful future in running all applications in their own nested X servers, but I also believe that trying to refactor X.org to shoehorn in namespaces is not worth the effort. Wayland goes pretty radical in the direction of isolating clients, but I think it is a good start.
I think a ton of the growing pains with Wayland come from just how radical the design really is. For example, there is deliberately no global coordinate space. Windows don't even know where they are on screen. When you drag a window, it doesn't know where it's going, how much it's moving, anything. There isn't even a coordinate space to express global positions, from a protocol PoV. This is crazy. Pretty much no other desktop windowing system works this way.
I'm not even bothered that people are skeptical that this could even work; it would be weird to not be. But what's really crazy, is that it does work. I'm using it right now. It doesn't only work, but it works very well, for all of the applications I use. If anything, KDE has never felt less buggy than it does now, nor has it ever felt more integrated than it does now. I basically have no problems at all with the current status quo, and it has greatly improved my experience as someone who likes to dock my laptop.
But you do raise a point:
> It feels like a regression to me and a lot of other people who have run into serious usability problems.
The real major downside of Wayland development is that it takes forever. It's design-by-committee. The results are actually pretty good (My go-to example is the color management protocol, which is probably one of the most solid color management APIs so far) but it really does take forever (My go-to example is the color management protocol, which took about 5 years from MR opening to merging.)
The developers of software like KiCad don't want to deal with this, they would greatly prefer if software just continued to work how it always did. And to be fair, for the most part XWayland should give this to you. (In KDE, XWayland can do almost everything it always could, including screen capture and controlling the mouse if you allow it to.) XWayland is not deprecated and not planned to be.
However, the Wayland developers have taken a stance of not just implementing raw tools that can be used to implement various UI features, but instead implement protocols for those specific UI features.
An example is how dragging a window works in Wayland: when a user clicks or interacts with a draggable client area, all the client does is signal that they have, and the compositor takes over from there and initiates a drag.
Another example would be how detachable tabs in Chrome work in Wayland: it uses a slightly augmented invocation of the drag'n'drop protocol that lets you attach a window drag to it as well. I think it's a pretty elegant solution.
But that's definitely where things are stuck at. Some applications have UI features that they can't implement in Wayland. xdg-session-management for being able to save and restore window positions is still not merged, so there is no standard way to implement this in Wayland. ext-zones for positioning multi-window application windows relative to each-other is still not merged, so there is no standard way to implement this in Wayland. Older techniques like directly embedding windows from other applications have some potential approaches: embedding a small Wayland compositor into an application seems to be one of the main approaches in large UI toolkits (sounds crazy, but Wayland compositors can be pretty small, so it's not as bad as it seems) whereas there is xdg-foreign which is supported by many compositors (Supported by GNOME, KDE, Sway, but missing in Mir, Hyprland and Weston. Fragmentation!) but it doesn't support every possible thing you could do in X11 (like passing an xid to mpv to embed it in your application, for example.)
I don't think it's unreasonable that people are frustrated, especially about how long the progress can take sometimes, but when I read these MRs and see the resulting protocols, I can't exactly blame the developers of the protocols. It's a long and hard process for a reason, and screwing up a protocol is not a cheap mistake for the entire ecosystem.
But I don't think all of this time is wasted; I think Wayland will be easier to adapt and evolve into the future. Even if we wound up with a one-true-compositor situation, there'd be really no reason to entirely get rid of Wayland as a protocol for applications to speak. Wayland doesn't really need much to operate; as far as I know, pretty much just UNIX domain sockets and the driver infrastructure to implement a WSI for Vulkan/GL.
Thanks a lot for an actually constructive comment on Wayland! The information tends to be lost in all the hate.
I understand the frustration, but I see a lot of "it's completely useless" and "it's a regression", though to me it really sounds like Wayland is an improvement in terms of security. So there's that.
The fact that this post is downvoted into grayness while lazy hateful rants aren't shows just how rotten HN community has gotten around opensource these days :/
> xdg-session-management for being able to save and restore window positions
> is still not merged, so there is no standard way to implement this in Wayland
For me, this is a real reason not to want to be forced to use Wayland. I'm sure the implementation of Wayland in xfce is a long time off, and the dropping of Xwindows even further off, so hopefully this problem will have been solved by then.
Do you know if global shortcuts are solved in a satisfactory way, and if there easy mechanism for one application to query wayland about other applications.
One hack I've made a while ago was to bind win+t command to a script that queried the active window in the current workspace, and based on a decision opened up a terminal at the right filesystem location, with a preferred terminal profile.
All I get from llms is that dbus might be involved in gnome for global shortcuts, and when registering global shortcuts in something like hyperland app ids must be passed along, instead of simple scripts paths.
Currently, the Wayland protocol itself doesn't have a standard solution to global shortcuts. Instead, it's being pushed to the XDG Desktop Portal API, under the org.freedesktop.portal.GlobalShortcuts service:
This should work with Hyprland provided that you are using xdg-desktop-portal-hyprland, as it does indeed have an implementation of GlobalShortcuts.
I'm not sure if this API is sufficient for your needs, or if it is too much of a pain to use. Like many Wayland things, it prescribes certain use cases and doesn't handle others. The "configure" call seems to rely on xdg-foreign-unstable-v2 support, but AFAIK Hyprland doesn't support this protocol, so I have no idea what you're supposed to do on Hyprland for this case.
I am sorry to see developers have to deal with things in a relatively unfinished state, but such is the nature of the open source desktop.
Thanks for the insight, I really appreciate it. I don't use hyperland (just what came up as brief research). Xfce generally has simple and legible code, hopefully this wayland compositor will be just as hackable and tweakable for my needs.
It's a downgrade that we have no choice but to accept in order to continue using our machines. Anyone familiar with Microsoft or Apple already knows that's the future.
They're trying to "nudge" everyone. Major desktop environments and entire distributions are removing X11 support to varying degrees. A lot of this is because they can't get their adoption rates above about half due to various broken workflows or simply user preference.
They intentionally don't want you to keep using X11, and they'll keep turning up the heat on the pot until we're all boiling.
Gnome just removed the middle-click paste option. Is that because they fixed the clipboard situation on Linux, and there's a universal, unambiguous way of cut and paste that works across every application? No. It's because middle-click to paste is an "X-ism." This is just demagoguery and unserious.
> Gnome just removed the middle-click paste option. Is that because they fixed the clipboard situation on Linux, and there's a universal, unambiguous way of cut and paste that works across every application? No. It's because middle-click to paste is an "X-ism." This is just demagoguery and unserious.
They disabled it by default. You can enable it if you want.
Once again, Gentoo Linux proves (somewhat regrettably) to be one of the best Linux distros out there. OpenRC and Xorg as defaults, with SystemD and Wayland as supported options is quite a lovely way to do things.
> Gnome just removed the middle-click paste option.
Gnome removes useful things all the time. "The Gnome folks do something user-hostile just because they feel like it" isn't news; that's been going on for decades. This habit of theirs is a big reason why I've been using KDE for a very long time.
Unfortunately I don't think Gentoo will keep X11 support in e.g. KDE once its dropped upstream (which is already announced), they don't have the manpower for that.
And KDE itself is also not the bastion of user choice it once was, even if they haven't yet gone quite as hostile as Gnome.
> Unfortunately I don't think Gentoo will keep X11 support in e.g. KDE once its dropped upstream...
IIRC, the only part that's dropping X11 support is Plasma. From [0]:
There are currently no plans to drop X11 support in KDE applications outside of Plasma.
This change only concerns Plasma’s X11 login session, which is what’s going away.
I don't really care about Plasma; a taskbar to house a system tray and clock is nice, as is desktop wallpaper, but I don't particularly care about that stuff. I use very little of KDE: kwin, krunner, kmix, kcalc, okular, dolphin (rarely), and whatever handles the global keyboard shortcuts.
Hell, on my ~twenty-year-old computer I don't use Plasma because it's a resource hog, but I still use KDE.
That's fair, but I would also read it as a sign of things to come for the rest. If you can't run full KDE on X11 there will not be many KDE developers caring about X11 support. KWin for example has already gained many bugs on X11 that I expect to never be fixed. And now KWin for X11 is split into a separate project which will hopefully mean fewer further regressions but probably also not much further development which means bitrot as things around it change.
> That's fair, but I would also read it as a sign of things to come for the rest.
Given this statement from the announcement that I linked to previously
The Plasma X11 session will be supported by KDE into early 2027.
We cannot provide a specific date, as we’re exploring the possibility of shipping some extra bug-fix releases for Plasma 6.7. The exact timing of the last one will only be known when we get closer to its actual release, which we expect will be sometime in early 2027.
I expect that I will get at least a year's notice before they stop actively working on the rest of the parts of KDE that interact with X11... whenever that ends up being. A year is more than enough time to find replacements for things that might eventually stop working one day.
Were I sixteen, I'd be very excited to preemptively move to something else. Now? The folks who work on it say that they'll keep it working for the forseeable future, and their behavior suggests that I'll get ample notice before they stop working on it.
The software in question works now (AFAICT) and will continue to work for quite a while. I am likely to get a significant amount of warning before they stop working on the software. I see no reason to switch. I have much better things to do with my time.
Yeah, I am staunch proponent of "don't try to fix what is not broken". Current XFCE is fast, light-weight, usable and works fine without major issues. While I don't fully understand the advantages / disadvantages of XFCE using Wayland instead of X, if, as someone else pointed out here on HN, running XFCE on Wayland is going to make it slower, it means these developers will be crippling one of XFCE's strongest feature. In that case other minor advantages seems pointless to users like me.
> running XFCE on Wayland is going to make it slower
Citation. None of the other desktops have slowed with Wayland, and gaming is as fast as, if not marginally faster on KDE/Gnome with Wayland vs LXDE on X.
Latency and throughput are very different things. However, it's worth noting that the comparison here is with and without compositing. If you were using compositing already on X11 (I believe XFCE offers it with "Desktop Effects" or something to that tune) then you've already been eating compositing latency, and you should actually get less latency in some situations.
But as far as it performing worse overall, I don't think that would be expected. Compositing itself does lean more on hardware acceleration to provide a good experience, though, so if you compare it on a machine that has no hardware accelerated graphics with compositing disabled, then it really would be worse, yeah.
Little misconception here (beware i'm using xlibre and causal user). On X11 you can find two mechanisms which can be called compositor :
1st: "enable display compositing" option - this one increases latency as every window draw need go though compositor application (in nutshell it exchanging opengl textures - only synchronization messages goes over "wire")
2nd: the Xserver rendering pipeline compositor, this one goes with modesetting (intel, amdgpu) driver TearFree option - almost everything inside X11 server in OpenGL textures and compositor perform direct blending to screen (including direct scanout).
What I want to tell, on modern X (there are merge requests for Xorg server to modesetting driver, amdgpu have this code) with TearFree enabled you by default optimal hardware acceleration - there comes lower latency
Long-time XFCE user here. We care that stuff works the same, we appreciate how much work it is to achieve that when the world is changing out from under you, and we appreciate that XFCE understands this and cares about it. Being in Rust is not a concern.
Wayland has lots of potential, but it's far from ready to replace X11, especially in multitasking environments. XFCE is taking their time, because their community is more very concerned stability.
I predict that XFCE will default to X11 until Wayland has reached broad feature parity, then default to Wayland but keep X11 support until the last vestages of incompatibility are delt with.
There's no reason that this wouldn't be accepted by their community, and it should be lighter weight, in the end.
I am an XFCE user since many years, and am pretty decidedly in the "traditional and conservative about technologies" camp, and I think this is neat and just fine and dandy -- as long as they're not in a hurry to depreciate X11. Whenever I eventually have to go Wayland I would like to continue to use XFCE, so thumbs up for doing the work.
Afaik there exists only X11 and Wayland, and X11 is dying if not dead. And for rust I don't see why a desktop user would be concerned by the language used as long as it is good enough.
In my view, this project itself shows some of the reasons why Wayland is the right path forward.
On X, we had Xorg and that is it. But at least Xorg did a lot of the work for you.
On Wayland, you in theory have to do a lot more of the work yourself when you build a compositor. But what we are seeing is libraries emerge that do this for you (wlroots, Smithay, Louvre, aquamarine, SWC, etc). So we have this one man project expecting to deliver a dev release in just a few months (mid-2026 is 4 months from now).
But it is not just that we have addressed the Wayland objection. This project was able to evaluate alternatives and decide the smithay is the best fit both for features and language choice. As time goes on, we will see more implementations that will compete with each other on quality and features. This will drive the entire ecosystem forward. That is how Open Source is supposed to work.
Because Wayland only does essential low-level stuff such as display and graphics it forced people to start coming up with a common Linux desktop (programming) interface out of nowhere to basically glue everything together and make programs at least interoperate.
Such an effort to rethink Linux desktop alone could've been a major project on its own but as having something was necessitated by Wayland all of it has become hurried and lacking control. Anything reminiscent of a bigger and more comprehensive project is in initial stages at best. If Wayland has been coming on for about ten years now I'll give it another ten years until we have some kind of established, consistent desktop API for Linux again.
X11 did offer some very basic features for a desktop environment so that programs using different toolkits could work together, and enough hooks you could implement stuff in window managers etc. Yet there was nothing like the more complete interfaces of the desktops of other operating systems that tied everything together in a central, consistent way. So, Linux desktop interface was certainly in need for a rewrite but the way it's happening is just disheartening.
Nobody has a user-space stick big enough to force things in the Linux world.
When Apple dropped the old audio APIs of classic macOS and introduced CoreAudio, they pissed off a lot of developers, but those developers had no choice. In the GUI realm, they only deprecated HIKit for a decade or two before removing it (if they've even done that), but they made it very clear that CoreFoo was the API you should be using and that was that.
In Linux-land, nobody has that authority. Nobody can come up with an equivalent to Core* for Linux and enforce its use. Consequently, you're going to continue to see the Qt/GTK/* splits, where the only commonality is at the lowest level of the window system (though, to Qt's credit, optionally also the event loop).
GNOME has enough weight to at least force most projects to accommodate them. But unfortunately this has mostly been for the worst, as GNOME is usually the odd one out with most matters of taste and design.
Maybe to some degree that's true. But let's take an example: GNOME is the only (afaik) desktop that requires client-side decorations. They've been like that for years, but nobody else is following them on that. Yes, the toolkits and a number of toolkit-less apps have added support for them. But it's not like they were actually able to employ their gravity to change the world over to CSD (thank goodness).
I don't think GP claimed that everyone copied everything about Gnome, just that every toolkit/program has to implement Gnomes way of doing things even if they continue to support others so you have that as a common (but often bad) interface. CSD is a good example of that - implementations of it have reached libraries like SDL that would rather not care about the desktop user interface at all but because of Gnome they have to.
You say that like it's a bad thing. If you have have an actually good design then you can convince people with those advantages instead of forcing them with a stick.
I think that's the main reason many of us use Linux actually - because we didn't like what the big stick corpos wanted to force on us.
But both Qt and GTK are entirely as well designed as, say, Apple's Core* frameworks for GUI development, yet neither has become the singular GUI toolkit on Linux.
One can view this as a benefit of Linux or as a disadvantage. Both are true.
Ah, if only! GNOME and even to an extent KDE both depend on systemd components, to the point that systemd-free distros are compelled to fork it if they want a GUI: https://wiki.gentoo.org/wiki/Elogind
Only yesterday I was wondering how it is that my brightness keys work in my desktop environment, when /sys/class/backlight/intel_backlight/brightness is only writeable by root. The (somewhat horrifying) answer is that applications can send a request to logind over DBUS, which checks the request against opaque and arbitrarily byzantine Polkit rules, and then writes to the sysfs file on the application's behalf, which it can do because it runs as root. It's unclear quite what this achieves that simply making the file writeable by the "video" group does not, but hey at least systemd gets to be involved.
Incidentally, the correct command to change the brightness as a normal user from the command line is as follows:
So simple, so easy to remember, so superior to "echo <brightness> > /sys/class/backlight/intel_backlight/brightness". Google it for a fun thread on why the --timeout=1 is neccessary (it won't work without it!) - although I suppose I should be thankful for that little foible, as without it the thread wouldn't exist and I would never have figured out the command in the first place.
As noted by others below, this has nothing to do with GUI desktop applications.
Sure, systemd is involved in running the system on which those applications run, but the discussion was about some sort of equivalent to the unified GUI stack offered by macOS (the Core* frameworks) which are used by essentially every GUI application on that platform. Linux doesn't have that, and there's nobody in a position to force that on developers. systemd has nothing to do with this.
Not exactly. Desktop environments (or whatever the program is that launches the application) decides to use systemd to run each application in its own cgroup.
Systemd is certainly relevant to the Linux desktop as a whole, especially regarding logind. But there's no specific relation to GUI desktop applications that I'm aware of at least.
As time goes on, we will see more implementations that will compete with each other on quality and features. This will drive the entire ecosystem forward.
Unfortunately there aren't enough developers to maintain all those duplicate implementations to the level users expect so a lot of features will be missing and a lot of maintainers will burn out. Not having a libcompositor remains Wayland's biggest mistake.
The other key element with Wayland is that the kernel does a ton of the work for you. There s GEM buffer management and DMA-BUF to manage and move around video & regular memory, there's kernel mode setting, there's incredibly good mesa drivers.
X didn't have any of that to build from. It basically was a second kernel, was the OS that dealt with the video card atop the OS actual. It talked to the PCI device & did everything.
Part of the glory of Wayland is that we have fantastic really good OS abstractions & drivers. When we go to make a display server, we start at such a different level now. Trying to layer X's abstractions atop is messy & ugly & painful, because it mostly inhibits devs from being able to use the hardware in neat efficient clean direct modern ways. You have to write an X extension that coexists with a patchwork of other extensions that slots into the X way, that can figure out how to leverage the hardware. With Wayland, most compositors just use the kernel objects. There's much less intermediary, much less cruft, much less wild indirection & accretion to cut a path for.
And as you beautifully state, competing libraries can decide what abstractions & techniques work for them. There's an ecosystem of ideas, a flux to optimize hone & improve, on a variety of different dimensions. The Bazaar free to find its way vs the one giant ancient Cathedral. It's just so so so good we're finally not all trapped inside.
Tl;dr: Wayland has a much higher level that it can start from. And trying to use gpu's & hardware well in X was a nightmare because X has a sea of abstractions - extensions that you had to target & develop around, making development in X a worst of both worlds low level but having to cope with a so many high level constructs you had to navigate through.
> On Wayland, you in theory have to do a late more...
This is vaguely a double-edged sword. Yes, more code duplication across disparate projects - but that also allows people who _really care_ (such as the xfce team) to roll up their sleeves and do more. Any WM will only ever be as good as the X11 baseline, Wayland servers have the opportunity to compete on this front.
Although I'm probably permanently stuck with the Niri workflow, I am looking forward to seeing what the xfce developers come up with.
By the time we get to that utopia someone will declare Wayland obsolete and we'll all be arguing over how Nextfad is the best/worst thing ever.
And technically, nothing has been stopping the xfce devs or anyone from making their own X11 server / X.org fork if the window manager interface was too limiting.
I have no doubt about it, but for my use-cases Wayland definitely is a step up. It's definitely a first-world-problem, but somehow typing feels more enjoyable at low latency - back when I still had a backup X11 session, I could instantly tell that I had left it on: the mouse cursor, input, everything felt like soup.
This is the same logic that led to rails being shoehorned into every company in 2006-2010, which spawned a whole ecosystem of people who specialized in rewriting Rails projects back to Java/C#.
Yes, the stack gets you most of the way there. No, you won't be happy if you need to actually make changes to any part of that other than the top layer.
The move from kernel 2.4.x to 2.6.x was pretty painful. The absolute slog from 2.6 to 3.0 and a development model that a least somewhat resembles the model used today was exhausting.
In case you weren't there, the "even" kernels (e.g. 2.0, 2.2, 2.4, and 2.6) were the stable series while the "odd" kernels (e.g. 2.1, 2.3, 2.5) were the development series, the development model was absolutely mental and development moved at a glacial pace compared to today's breakneck speed.
The pre-git days were less than ideal. The BitKepper years were... interesting, politically and philosophically speaking.
To me the most painful switch was Gnome 2 to Gnome 3. I still miss Gnome 2.
I left Gnome 3 for other WMs (eventually settled on cinnamon), but every once in a while I decided to give Gnome 3 a try, just to be disappointed again. I felt like those people in abusive romantic relationships that keep coming back and divorcing over and over again. "Oh, Gnome has really changed now, he won't beat me again this time!".
Systemd was easy for me. All things worked in transition and have the big advantage that don't need shell scripts for create services. Wayland..., is slow, buggy, applications close without reason...
Fully-featured DEs like Gnome and KDE work a lot worse when doing everything in software rendering. If you're working on a device with subpar/nonexistent GPU driver support (i.e. Nvidia hardware for years on end), the experience is absolutely awful.
Nvidia's driver do something weird on Wayland when my laptop is connected to HDMI, probably something funky with the iGPU<->dGPU communication. Everything works, but at the whims of Nvidia an update reduces the maximum FPS I can achieve over HDMI to about 30-45fps. Jittery and painful, even on a monitor that supposedly supports VRR.
That's not really Wayland's fault of course, but in the same way Linux is broken because Photoshop doesn't work on it, Wayland is broken for many users because their desktop is weird on it.
I still have a choice to not use systemd. The systemd people didn't inhabit and then try to kill sysvinit or runit or any of the other competing technologies.
Depending on your DE, you have a choice not to use Wayland. Like, yes, if you use GNOME then you don't get choices but that's their whole ethos, and unfortunately I've heard about KDE dropping X, but there are other options and as I type this comment in i3 I can assure you Xorg still works.
systemd was a problem for early adopters (e.g., Fedora). Distros like Debian joined the party later and, as a result, got things way more stable. I never had any systemd-related problem in Debian, while for Fedora (some years earlier) I had some bugs affecting my ability to work. They all seem to work very fine now. Things took a while to mature, but it just works now.
It was a similar story with Pulseaudio - it caused pain for early adopters but, by the time that Debian stable switched to it by default, almost all of the issues and corner cases had long since been worked out and it was almost completely trouble-free.
Mind you, the libc5 -> glibc2 upgrade was pretty horrible in Debian land, so they didn't always get it right in the early days...
I've used Smithay's Rust client toolkit for a few months now. For making apps it is still sometimes have unsafe wrappers disguised as safe. It has a lot of internals wrapped in Arc<>, but in my tests, the methods are not safe to call from different threads anyhow, you will get weird crashes if done so.
I will seek to dive-in to how Wayland API actually works, because I'd really like to know what not to do, when the wrappers used 'wrong' can crash.
Could you expand on why you describe Hyprland and XFCE4 as "a cursed combination"? Might provide some insight as to why the official XFCE project decided to create their own compositor.
I resisted Wayland for a longtime, but I'm sold now that I see how well it does on old hardware.
I have an old Thinkpad. Firefox on X is slow and scrolls poorly. On wayland, the scrolling is remarkably smooth for 10 y/o hardware, and the addition of touchpad gestures is very nice. Yes, there's more configuration overhead for each compositor, but I'm now accepting this trade.
Wayland works pretty well on FreeBSD and I know at least wlroots compositors work a bit on OpenBSD (though, I suspect anyone on OpenBSD would prefer to use their homegrown Xenocara). There are Wayland compositors for Mac, the youtuber Brodie Robertson did a good overview of them a few days ago
Rather than going fully protocol-based (like Waypipe), they used Weston to render to RDP. Using RDP's "remote apps" functionality, practically any platform can render the windows. I think it's a pretty clever solution, one perhaps even better than plain X11 forwarding (which breaks all kinds of things like GPU acceleration).
I don't know if anyone has messed with this enough to get it to work like plain old RemoteApps for macOS/BSD/Windows/Linux, but the technology itself is clearly ready for it.
It depends on what you mean by send. Wayland doesn't have network transparency, there's a bit of a song and dance you have to do to get that working properly. I'm not sure the state of that or of Wayland compositors in general on Mac.
For xeyes that works. It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it.
X's network transparency was made at a time when we drawn two lines as UI, and for that it works very well. But today even your Todo app has a bunch of icons that are just bitmaps to X, and we can transfer those via much better means (that should probably not be baked into a display protocol).
I think Wayland did the correct decision here. Just be a display protocol that knows about buffers and that's it.
User space can then just transport buffers in any way they seem fit.
Also, another interesting note, the original X network transparency's modern analogue might very well be the web, if you look at it squinted. And quite a few programs just simply expose a localhost port to avoid the "native GUI" issue wholesale.
> For xeyes that works. It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it.
I used run and use diskless SparcStation 5s with remote X on 10BASE2 network with the binaries running on Sun E3500s: it worked well enough for non-video web sites running Netscape 3.x. Also Matlab, Octave, Emacs, Vi(m), etc.
I've used it to run backup application GUIs when I was still on DSL (<25Mbps) displaying at home many years ago, and it worked well then. I now have >100Mbps fibre at home, so doubt that bandwidth (or even latency) is worse.
Well, we are using much higher resolutions with much higher frame rates and with more media-rich content.
You surely agree that not having a good compression here is less than ideal.
And it begs the question whether this is indeed the task of the display manager, or it's packing an unrelated functionality that could be better solved by another software.
And we haven't even gotten to sound - should a display manager now suddenly also handle sound?
Of all the things that seem useful to conflate, audio and video does make sense to me, as they so often need to be synchronized. Hell: many monitors also support audio, all televisions do, and the cables used to connect them carry both signals.
>It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it.
This is extremely misleading. Web browsers (and games) are the worst case for X11's network transparency. The overwhelming majority of applications belong in the same category as xeyes.
> the original X network transparency's modern analogue might very well be the web
It's Arcan, which solved this problem without sacrificing network transparency at the altar.
> The overwhelming majority of applications belong in the same category as xeyes.
Well, I'm not sure you are using that many xmotif apps. Most of the GUI programs are gtk/qt (and let's be honest, electron) - and they are mostly bitmaps to X's eyes (pun not intended). They don't use draw commands with such a small granularity that network transparency would benefit.
And Arcan is so many things at once I'm not convinced it is a good alternative to Wayland. It has good ideas, but they sort of require the whole package. Meanwhile Wayland is just a minimal API over the Linux kernel API for managing display buffers, that can be extended with additional protocols.
>And Arcan is so many things at once I'm not convinced it is a good alternative to Wayland. It has good ideas, but they sort of require the whole package.
That's a bit of a double edged sword, it's the exact reason why I don't think Wayland is a good alternative to X. Wayland's minimalist attitude towards responsibility is good for one thing, and that's implementing new compositors from scratch. The bare bones compositor will be a long way from usable, but it will be technically complete. The question is, does it matter to me that there are 30 different compositors? Each in various states with their own eclectic featureset with no guarantees given, a la USB-C? Not really. In effect, it did present me with the conundrum of choosing between a half-baked compositor (dwl) or a desktop experience I have literally zero interest in (Gnome/KDE) which left me with a sour taste in the mouth.
Moving beyond that, a real problem with Wayland's architectural minimalism is that a display server does more than simply abstract a single API. It provides a lot of rather complex features, from accessibility to input handling. Not every compositor is capable of handling that kind of complexity, especially if it's to work well. What we will find going forward are two possible futures:
1. The future resembles the present status quo of fragmentation, made worse by time. The compositor archipelago is here to stay, and deploying software in this environment has become excessively annoying. There are 10 different competing libraries for any given category of basic infrastructure, and each library in each category has their own ideas and idiosyncrasies that have to be worked around. Most of them are buggy and incomplete.
2. Smaller compositors effectively die off, and we are left with a single monolithic compositor, back to the modular Window Manager/Desktop Environment. This monster implements the defacto Extended Wayland protocol, where all of the different parts don't quite match each other very well because that's the cost gained from not having vertical integration of complicated components. There's no cohesive rhyme or reason to the design of anything. Thus, the exercise in minimalism has wrought an uglier and more complicated beast than Xorg itself.
I think it's clear Wayland is going to continue to sweep the Linux desktop given its massive corporate backing. But I'm not really compelled to run a bare Wayland compositor under any circumstances, because my Arcan server already works perfectly fine as a Wayland compositor. It works as any number of Wayland compositors running whatever extensions they implement. In effect, no matter which future we end up in, by using Arcan I'm in a much better position than someone running a normal compositor. This fact alone makes me favor Arcan, even before we get into its unique merits.
Watching a video will be the same as a on Wayland, just sending a video buffer, no?
The icons: you allocate memory on server for that and do not transfare the icon everytime. I think x11 works like that, not sure.
I know GUI lib that you can still compile with freetype disabled. Not everyone need the GUIs you talking about. Everyone is using cars, so lets ban bikes.. it does not need to be like that.
I find X11 RPC useful, simple UI is ok.. you can write programs that will run on any slow or not computer, remotely. Web is not that simple, it is different way of programming, it is not transparent. Web is useful for commerce, but not for controlling machines at factories or pilot cabins. IMO.
I don't really get your first 2 paragraphs. We are talking about connecting remotely to another computer, you can't do much at the other end of a network call with a server allocated buffer - at most you can cache stuff there. But that ain't helping with a video or any kind of fancier than a solid rectangle graphics.
And sure, simple UIs have their place - but they will also work just as well with a proper transport protocol, hell, they would compress even better. So just waypipe that simple UI as you see it fit.
You can cache icons on the server, you do not need to send them over a network, that is it. With video, I'm saying it is a case where wayland is not better, it is just the same.
So you say compression of said icons, etc, is better than caching them on the server? No.. You've mentioned web, but no one does that on the web.
I mean, no one does what you suggest on the web. You do not render a web page to an image and send that to a browser.
To summarize. No one wants X11 transparency to run a web browser. But ok, if someone wants to do that.. X11 still can be more advantegeous over waypipe.
Because on the web we have a very very complex protocol(s) built up over decades to tell a client what to draw locally. That's html/css/js and its scope is far larger than of x draw commands (it's also an application model).
But again, GUI apps don't use X draw commands for the most part, so they are effectively a bitmap/video stream to X's eyes. And what's better to transport a video stream than a format designed for efficient transport of video streams.
Idk given there is no concept of cache. But also I'm looking at GTK menu, it is a simple menu, white bg. May be it can be rendered using draw calls. May be the complex UIs is just fashion and will be gone in a few years. The GUIlib could detect if program is running on a remote computer and reduce the effects, but they will need a concept of network for that.
Also the font rendering. The client could then just send text to the x11 server if it was not vector fonts.
x11 xrdb. With it you can configure say font size on your computer, not on the computer where program is running. Say comp1: 10pt, comp2: 20pt.
It's not "complex UI", it's what programs are generally used. It's gtk, qt, and a bunch of other cross-platform platforms all doing their own thing. They simply render (in a hardware-accelerated way) to a local buffer and that's the only commonality.
Could random draw calls be transported over the network? Sure, and for certain kinds of GUIs it is definitely more efficient than rendering and sending some compressed artifact.
Will XMotif suddenly change the world and apps will be written in it? Absolutely not. It's not even a thing on the minuscule Linux desktop, let alone elsewhere. We are running electron apps and whatnot.
And as I said, this "send draw commands" exists: SVGs are possibly the closest thing, but the web as a whole is literally this with a couple of more features.
You need waypipe installed on both machines. For the Mac, I guess you'll need something like cocoa-way (https://github.com/J-x-Z/cocoa-way). Some local Wayland compositor, anyway.
If wayland support was there already I would be using xfce. I truly admire it, it's great to see this happening and I hope the project continues in great speed. With DE's requiring hard system-d support, I would rather have something like xfce
I see the words "feature parity". I hope those words are taken seriously. I feel like most Wayland advocates would do well to take those words seriously.
Absolutely seriously. To me, a big part of what makes Xfce is xfwm4's behavior. Even though most of the other Xfce components will run decently well on wlroots-based compositors, I don't really have an interest in using them, as that's not "Xfce" to me.
But it's not going to be perfect, though, as some things that we take for granted on x11 still just do not have Wayland protocols to enable them. This will take a long time. Alex's blog post says a developer preview around the middle of this year, and I expect I can deliver on that, and maybe (maybe!) even a stable release by next year (maybe!), but full feature parity will take years.
As someone that is sensitive to displays, one of the best features of XFCE, unlike others desktops, is that it doesn't cause eye strain, probably because it doesn't play tricks - a pixel at a certain color is stable, and not dithered(if you choose) and higher level primitives are also stable and don't play time/frequency based games.
I hope XFCE preserves this, it is a killer feature in today's world.
I started off using twm / olwm / vtwm in 1991. Then FVWM and Afterstep / WindowMaker. I've been using XFCE since around 2007. As long as it functions similarly I'll be happy.
The more wayland compositors the better. It will force developers to actually abide by the specification instead of creating single implementation hacks like in the webbrowser ecosystem.
I guess at this point it is safe to say that whenever you see "rewrite in Rust", it simply means there is no one to maintain the software anymore. They are saying this pretty openly that they weren't able to patch xfwm4.
I only fear that this is manifestation of a wider phenomenon when new software developers are unable to maintain software created by old software developers. If that is so, they will try to simplify the software to what they can actually maintain and rewrite it into a form in which they can maintain it.
If i assume this is true, then all of this is annoying, but actually makes sense: Wayland is simpler than X11, so people will tend to maintain Wayland-related software rather than X11-related. Rust won't let unskilled coders to make some mistakes, so from their point of view it is going to be simpler to rewrite something in Rust.
Although, goodbye network-transparency, goodbye performance, goodbye stability. Oh well, but it's that time of the year.
This bullet point from the reason to chose one library over another is a prime example of what I love about XFCE:
• smithay has great documentation.
Not only are they considering it, but they're expressly calling it out. I'm convinced that the publication of the Agile Manifesto was an exercise in Cunningham's Law, and to that end the XFCE team has produced something great by doing the opposite.
Not the whole codebase, only the window manager (compositor is the Wayland equivalent). Other components are written in C and will remain so for the foreseeable future. Those components gained Wayland support in the last couple of years, you can try Xfce in a labwc session, there are of course several things to improve, but the compositor is the last big piece missing.
I spent a month or so in 2024 attempting to refactor xfwm4 so it could serve dual purpose as both an X11 window manager and Wayland compositor, and ended up abandoning the idea. It was just getting ugly and hard to read and understand, and I wasn't confident that I could continue to make changes without introducing bugs (crashers, even). We want X11 users to be unaffected by this, and introducing bugs in xfwm4 wouldn't achieve that goal.
Note that we don't have to rewrite all of Xfce: xfce4-session, xfce4-panel, xfdesktop, etc. will all run on Wayland just fine (there are some rough edges that need to be ironed out for full Wayland support, but they're already fairly usable on wlroots-based compositors). This is just (heh, "just") building a compositor and porting xfwm4's WM behavior and UI elements over to it. Not a small task, to be sure, but much smaller than "rewriting all of Xfce".
It was originally named XFce after the XForms library. As of Xfce 3, it uses GTK though, so it could be called GTKce, but renaming the project every time you change widget toolkits is probably not a good idea.
I suspect many of us still using X, are xfce users waiting for an alternative; I've heard very mixed things about current Fedora xfce wayland setups from different people.
If they do not mind introducing C++ (they're introducing Rust so i guess multilanguage development isn't out of the question) then FLTK could be an option, though it'd probably need to improve its theming support.
They both have kinda similar roots in that XFCE originally used XForms which was an open source replacement of the SGI Forms library while FLTK also started as a somewhat compatible/inspired opensource replacement of SGI Forms in C++.
If they ever move away from GTK (due to the GNOME shenanigans GNOME-izing GTK) I wish Englightenment and Xfce were together a single thing. But that's if I could ask the Tux genie three wishes.
GTK4 is still pretty usable without libadwaita and all its Gnome-isms.
But frankly I think forking and maintaining GTK3 is preferable to moving to EFL or Qt. GIMP is still on GTK3. MATE is still on GTK3. Inkscape is still on GTK3 (but GTK4 work is in progress). Evolution is still on GTK3.
I don’t see much Wayland hype. It’s boring plumbing for most people, isn’t it? Most of us are just going along with whatever the volunteer plumbing community decided to put together.
I'm also not a big fan of Wayland, to be honest. But that's the way the winds are blowing. X11 has its problems, but even if they are fixable, no one seems to want to work on Xorg anymore. I'm certainly not prepared to maintain it and push it forward. Are you?
Depending on Xorg today is more or less ok, but I do expect distros will stop shipping it eventually.
Are you willing to write accessibility support for the new xfce only wayland compositor? How will you get every other wayland compositor to support your non-'wayland core' accessibility extension?
People like to frame things like the waylands are some sort of default and nothing is being lost and no one is being excluded.
Everyone has settled on an accessibility standard (Matt Campbell's). So it's not "your" accessibility protocol, it's already "the" accessibility protocol. This is working as intended IMO: allow things to compete and future in the wild and then pick the fittest.
Right. The push based accessibility that is only supported by GNOME's compositor, mutter, and GNOME's DE's userland as of this last 6 months. I would very happy to hear about even this extension supported under other wayland compositors and software. Do you know of any?
Since you seem informed perhaps you can clear something up for me, when Cambpell says "push full accessibility tree to trusted clients" does that mean you get the entire desktop tree, or only for that application?
Because if you don't get the entire window tree, because you only get the single windows information when that application provides it, it is highly incompatible with existing solutions. They say it is compatible because application developers can create a new virtualized thing themselves. But that's not compatible. And beyond that, it is a "solution" that prevents me from controlling my own computer. I understand GNOME is targeting everyone not just power users. But as a power user I am someone. I am a human being.
And Campbell's assertions that push is more performant than pull and full tree are being backed by arguments informed from problems that don't even apply generally. GTK 4 broke this, not GTK 3. It's not a push versus pull thing. It's wayland architecture focused Gtk4 causing the problem when things are fine in X11 focused GTK 3. ref: https://gitlab.gnome.org/GNOME/gtk/-/issues/6269 a11y: No API for supporting a11y Selection interface , https://gitlab.gnome.org/GNOME/gtk/-/issues/6204 a11y AT-SPI: get_child_count implementation iterating over all children causes freeze for objects with many a11y children
If the XLibre project appears to be making enough fairly-consistent progress for you to be comfortable tossing around some cash, then do gather up some likeminded folks to hire a dev to follow the guidance here [0] and help out!
Do note that I've never tried to croudfund a programmer, but that's something that I have to believe is possible to do.
Given that FDO [0] has been screaming about how Xorg is dead and Wayland is (despite plenty of evidence to the contrary) ready for everyone and every use case for the past like ten+ years, I remain somewhat wary about their opinions regarding Xorg development.
Maybe XLibre will be a damn trainwreck, or maybe it'll be to xorg what xorg was to XFree86. I intend to find out through the testimony of users of XLibre.
[0] ...or maybe just a very vocal subset of the folks at FDO...
Some cognitive dissonance going on here. The vast majority of current Linux Desktop users are on Wayland, and X11 is phased out across the board. Calling it hype is absurd.
Wow, this is annoying. I really like Xfce, but there are plenty of minor things which would need improvements. Instead of fixing all these minor things, they waste a lot of their donations on a rewrite for Wayland / Rust - apparently for exactly the same reason as all the other Wayland stuff and Rust reworks. Developers like to write new code more than actually maintaining / improving fixing existing things and finds some excuses to do this.
That's a fair criticism sometimes, but, frankly, if you want things the way you want them, learn to code and dig in. Otherwise it's not really fair of you to complain about stuff that people have built for you for free, in their spare time.
In this particular case, it's not fully a "new and shiny, must play!" situation. I personally am not even a big fan of Wayland, and I'm generally highly critical of it. But Xorg is more or less unmaintained, and frankly, if we don't have a Wayland compositor, we'll become obsolete eventually. That's just the way the wind is blowing.
I am not complaining about what people do in their spare time. If the blog post said "someone does this because he likes to spend his own time on it", I would not complain. I am complaining about a) the justifications given which I think are all nonsense IMHO and rationalizations for something which some likes to do, and b) the use of donations which should be better used to improve the software instead of creating more rewrites.
I also do not agree with the Wayland is inevitable sentiment. There are non-systemd distros, there will also be non-Wayland distros. The idea is that only those things survive which are pushed into the ecosystem by the cooperate bullies is wrong, otherwise Linux would not exist.
The Linux desktop was essentially fine already two decades ago and instead of the needed refinements, bug fixing, and polishments, we get random changes in technology after the other, so nothing ever really improves but we incrementally lose applications which do not keep up, break workflows, sometimes even regress in technology (network transparency),
and discourage people from investing into applications because the base is not stable. My hope was that Xfce4 is different, but apparently this was unfounded.
> I am not complaining about what people do in their spare time.
Re-read your original post. You are absolutely complaining about what we do in our spare time.
> If the blog post said "someone does this because he likes to spend his own time on it", I would not complain.
I mean, that's part of it. I wouldn't do it if I wasn't interested in doing it. I have my own long list of Wayland criticisms, but I think it's interesting.
> I also do not agree with the Wayland is inevitable sentiment.
I think that's where we'll be at an impasse.
There are non-systemd distros because there are viable alternatives. Xorg (the server implementation, I mean, not X11 the protocol/system) is dead. I don't like saying that. I've invested a lot of time into X11 and understanding how it works, and how Xorg works. But no one wants to maintain it. There is the XLibre fork, and I wish them well, and do want them to succeed, but sustaining a fork is hard, and only time will tell if that works out.
But I don't think X11 has a future, unfortunately. And that really does make me sad. You're free to disagree with that, but... well, so what.
> The Linux desktop was essentially fine already two decades ago and instead of the needed refinements
That's a view through rose-tinted glasses if I ever saw one.
> we get random changes in technology after the other
Jamie Zawinski called this the "Cascade of Attention-Deficit Teenagers", and he's right. I do think some of these changes are an earnest and honest attempt to make things better, but yes, people just want to work on what interests them, and what makes them feel good and accomplished.
When we work for a corporation we don't really get to do that, but when it's unpaid, spare-time volunteer work, we have the freedom to do whatever makes us happy, even if it makes other people mad or disappointed or annoyed, or isn't the most "productive" use of our time (whatever that means).
> > I am not complaining about what people do in their spare time.
> Re-read your original post. You are absolutely complaining about what we do in our spare time.
Then I am not sure how I have to understand this sentence: "After careful consideration, we’ve decided on a meaningful way to use the generous donations from our community: funding longtime Xfce core developer Brian Tarricone to create xfwl4, a brand-new Wayland compositor for Xfce."
I trust you understand that some readers may not find (to paraphrase) "I don't like it either but it is what it is." a compelling reason to fix something that is not broken.
I also do not use free software to then have to use something I do not like because the "this is the way the wind is blowing" (just becomes some parts of the industry wants something re-engineered in their interests)
My response to the Wayland/X11 nonsense bickering has always been that I'll switch to Wayland when xfce does. I usually eyeroll when I see "in Rust" but the developers writeup in the linked article and their comments here are very reassuring and I look forward to their success!
i'm trying to build a Linux desktop and the first thing I got stuck at is X11 versus Wayland for greetd. Next thing Il got stuck at his XFCE4 doesn't exist for Wayland. What the shit. if we want to tell me wayland is the future, fine. sure. great. Tt's been 11 years!
If you're just trying to run Linux you're better off either using one of the many read-made distributions or going with X11 since that works just about everywhere and has done so for decades.
THanks for the encouragement. I'm trying to get Debian Linux to run on a Chromebook and it's been no shortage of frustration, especially because ChromeOS is Linux and ostensibly open source, but just getting the kernel booted was an ordeal and a half. I'm currently stuck at suspend not working because something something EC, for which ChromeOS has a userland program to coax it into working right.
ChromeOS and devices it was made for are not the best start in Linux-land since it is Linux just like Android is, i.e. it is based on a Linux kernel but for the rest quite different from 'standard' (GNU-) Linux distributions like Debian + derivatives, Arch, Fedora etc. Maybe you can get that userland tool from ChromeOS to work in Debian, maybe not.
Even though you're trying to get Debian installed on the thing I'd also refer to the Arch wiki for information on how to get things working right:
Arch being what it is it has attracted a host of knowledgeable users who have collected their information about how to get things working on different systems in an organised and usually comprehensive way on that wiki. Much if not most of what is written there is also applicable to getting non-Arch distributions running on those systems.
>The goal is, that xfwl4 will offer the same functionality and behavior as xfwm4 does...
I wonder how strictly they interpret behavior here given the architectural divergence?
As an example, focus-stealing prevention. In xfwm4 (and x11 generally), this requires complex heuristics and timestamp checks because x11 clients are powerful and can aggressively grab focus. In wayland, the compositor is the sole arbiter of focus, hence clients can't steal it, they can only request it via xdg-activation. Porting the legacy x11 logic involves the challenge of actually designing a new policy that feels like the old heuristic but operates on wayland's strict authority model.
This leads to my main curiosity regarding the raw responsiveness of xfce. On potato hardware, xfwm4 often feels snappy because it can run as a distinct stacking window manager with the compositor disabled. Wayland, by definition forces compositing. While I am not concerned about rust vs C latency (since smithay compiles to machine code without a GC), I am curious about the mandatory compositing overhead. Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?
(xfwl4 author here.)
> I wonder how strictly they interpret behavior here given the architectural divergence?
It's right there in the rest of the sentence (that you didn't quote all of): "... or as much as possible considering the differences between X11 and Wayland."
I'll do my best. It won't be exactly the same, of course, but it will be as close as I can get it.
> As an example, focus-stealing prevention.
Focus stealing prevention is a place where I think xfwl4 could be at an advantage over xfwm4. Xfwm4 does a great job at focus-stealing prevention, but it has to work on a bunch of heuristics, and sometimes it just does the wrong thing, and there's not much we can do about it. Wayland's model plus xdg-activation should at least make the focus-or-don't-focus decision much more consistent.
> I am curious about the mandatory compositing overhead. Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?
I'm not sure yet, but I suspect your fears are well-founded here. On modern (and even not-so-modern) hardware, even low-end GPUs should be fine with all this (on my four-year-old laptop with Intel graphics, I can't tell the difference performance-wise with xfwm4's compositor on or off). But I know people run Xfce/X11 on very-not-modern hardware, and those people may unfortunately be left behind. But we'll see.
If xfwl4 plans to implement something like sway output max_render_time, then input to pixel output latency should be same or even lower than x11
At least they are honest regarding the reasons, not a wall of text to justify what bails down to "because I like it".
Naturally these kinds of having a language island create some attrition regarding build tooling, integration with existing ecosystem and who is able to contribute to what.
So lets see how it evolves, even with my C bashing, I was a much happier XFCE user than with GNOME and GJS all over the place.
You know that all the Wayland primitives, event handling and drawing in gnome-shell are handled in C/native code through Mutter, right ? The JavaScript in gnome-shell is the cherry on top for scripting, similar to C#/Lua (or any GCed language) in game engines, elisp in Emacs, event JS in QtQuick/QML.
It is not the performance bottleneck people seem to believe.
I can dig out the old GNOME tickets and related blog posts...
Implementation matters, including proper use of JIT/AOT toolchains.
>I can dig out the old GNOME tickets and related blog posts...
That's the easiest way you can win any argument on gnome. You're going straight for the nuclear option.
It has been the case that stalls in the GJS land can stall the compositor though, especially if it's during a GC cycle.
is GJS in the compositor?
> ...or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?
I think I know what "frame perfect" means, and I'm pretty sure that you've been able to get that for ages on X11... at least with AMD/ATi hardware. Enable (or have your distro enable) the TearFree option, and there you go.
I read somewhere that TearFree is triple buffering, so -if true- it's my (perhaps mistaken) understanding that this adds a frame of latency.
> I read somewhere that TearFree is triple buffering, so -if true- it's my (perhaps mistaken) understanding that this adds a frame of latency.
True triple buffering doesn't add one frame of latency, but since it enforces only whole frames be sent to the display instead of tearing, it can cause partial frames of latency. (It's hard to come up with a well-defined measure of frame latency when tearing is allowed.)
But there have been many systems that abused the term "triple buffering" to refer to a three-frame queue, which always does add unnecessary latency, making it almost always the wrong choice for interactive systems.
only on the primary display. once you had more than one display there were only workarounds.
I don't know what "workarounds" you're talking about, or what unwanted behavior that I presume you're talking about. Would you be more specific?
I ask because just a few minutes ago, I ran VRRTest [0] on my dual-monitor machine and saw no screen tearing on either monitor. Because VRR is disabled in multi-monitor setups, I saw juddering on both monitors when I commanded VRRTest render rates that weren't a multiple of the monitor's refresh rate, but no tearing at all.
My setup:
* Both monitors hooked up via DisplayPort
* Radeon 9070 (non-XT)
* Gentoo Linux, running almost all ~amd64 packages.
* x11-base/xorg-server-21.1.20
* x11-drivers/xf86-video-amdgpu-25.0.0-r1
* x11-drivers/xf86-video-ati-22.0.0
* sys-kernel/gentoo-sources-6.18.5
* KDE and Plasma packages are either version 6.22.0 or 6.5.5. I CBA to get a complete list, as there are so many relevant packages.
[0] <https://github.com/Nixola/VRRTest>
(I'm posting in a reply in part because the edit window is long since past.)
Yeah. I'm actually quite interested in hearing what "workarounds" and/or misbehavior you're talking about. 'amdgpu(4)' says this about the TearFree property:
The explicit mention that the "auto" enables TearFree only for secondary outputs and rotated and/or transformed outputs if 'VariableRefresh' is disabled seems to directly contradict what I think you're saying. And if "auto" enables TearFree on secondary displays, my recommendation of "on" certainly also does. But, yeah. I await clarification.One thing to keep in mind is that composition does not mean you have to do it with vsync, you can just refresh the screen the moment a client tells you the window has new contents.
Compositor overhead even with cheapo Intel laptop graphics is basically a non-issue these days. The people still rocking their 20 year old thinkpads might want to choose something else, but besides that kind of user I don't think it's worth worrying too much about.
It isn't always pure overhead, but also jitter, additional delays and other issues caused by the indirection. Most systems have a way to mostly override the compositor for fullscreen windows and for games and other applications where visible jitter and delays are an issue you want that even on modern hardware.
> Most systems have a way to mostly override the compositor for fullscreen windows and for games
No, they don't. I don't think Wayland ever supported exclusive fullscreen, MacOS doesn't, and Windows killed it a while back as well (in a Windows 10 update like 5-ish years ago?)
Jitter is a non-issue for things you want vsync'd (like every UI), and for games the modern solution is gsync/freesync which is significantly better than tearing.
> I don't think Wayland ever supported
Isn't that true for even the most basic features you expect from a windowing system? X11 may have come with everything and the kitchen sink, Wayland drops all that fun on the implementations.
GNOME does unredirect on Wayland since 2019: https://www.reddit.com/r/linux/comments/g2g99z/wayland_surfa...
> Windows killed it
They replaced it with "Fullscreen Optimisations", which is mostly the same, but more flexible as leaves detection of fullscreen exclusive windows to the window manager.
https://devblogs.microsoft.com/directx/demystifying-full-scr...
As far as I can find the update removed the option to turn this of.
In both the GNOME and Windows "Fullscreen Optimizations" it's the compositor doing an internal optimzation to avoid a copy when it's not necessary. In neither scenario is the system nor applications "overriding" or bypassing the compositor. The compositor still has exclusive ownership of the display. And the application's swapchain is still configured as if it was going through a composition pass (eg, it's probably not double-buffered)
> it's the compositor doing an internal optimzation to avoid a copy when it's not necessary.
Yeah, it avoids doing the compositing part of being a compositor. It bypasses the entire pipeline.
"Fullscreen Optimisations" is how X11 has always worked.
Window's actual exclusive fullscreen always caused tons of issues with Alt+TAB because it was designed for a time when you couldn't fit both a game and the desktop in VRAM.
X11 doesn't have an exclusive fullscreen mode either. [*] It's always has relied on compositors and drivers to detect when fullscreen windows can be unredirected. Some programs chose to implement behavior like minimizing on focus loss or grabbing input that is closer to Windows's exclusive fullscreen mode but the unredirecting of the display pipeline doesn't depend on that.
[*] Well, there was an extension (can't recall the name right now) but not much used it and support was dropped at some point.
That matches what I recall too, back when I ran a very cheap integrated intel (at least that's what I recall) card on my underpowered laptop. I posted a few days ago with screenshots of my 2009 setup with awesome+xcompmgr, and I remember it being very snappy (much more so than my tuned Windows XP install at the time). https://news.ycombinator.com/item?id=46717701
I ran xfwm's compositor back when it was first introduced on a 400 MHz Pentium II with a GeForce 2. It was fully fine.
The compositing tax is just waiting for vsync; unless your machine is, like, a Pentium Classic, compositing itself isn't a problem.
> As an example, focus-stealing prevention. In xfwm4 (and x11 generally), this requires complex heuristics and timestamp checks because x11 clients are powerful and can aggressively grab focus. In wayland, the compositor is the sole arbiter of focus, hence clients can't steal it, they can only request it via xdg-activation. Porting the legacy x11 logic involves the challenge of actually designing a new policy that feels like the old heuristic but operates on wayland's strict authority model.
Not that that's necessarily the best way to do it but nothing stops xfwl4 from simply granting every focus request and then applying their existing heuristics on the result of that.
> Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?
I think this is ultimately correct. The compositor will have to render a frame at some point after the VBlank signal, and it will need to render with it the buffers on-screen as of that point, which will be from whatever was last rendered to them.
This can be somewhat alleviated, though. Both KDE and GNOME have been getting progressively more aggressive about "unredirecting" surfaces into hardware accelerated DRM planes in more circumstances. In this situation, the unredirected planes will not suffer compositing latency, as their buffers will be scanned out by the GPU at scanout time with the rest of the composited result. In modern Wayland, this is accomplished via both underlays and overlays.
There is also a slight penalty to the latency of mouse cursor movement that is imparted by using atomic DRM commits. Since using atomic DRM is very common in modern Wayland, it is normal for the cursor to have at least a fraction of a frame of added latency (depending on many factors.)
I'm of two minds about this. One, obviously it's sad. The old hardware worked perfectly and never had latency issues like this. Could it be possible to implement Wayland without full compositing? Maybe, actually. But I don't expect anyone to try, because let's face it, people have simply accepted that we now live with slightly more latency on the desktop. But then again, "old" hardware is now hardware that can more often than not, handle high refresh rates pretty well on desktop. An on-average increase of half a frame of latency is pretty bad with 60 Hz: it's, what, 8.3ms? But half a frame at 144 Hz is much less at somewhere around 3.5ms of added latency, which I think is more acceptable. Combined with aggressive underlay/overlay usage and dynamic triple buffering, I think this makes the compositing experience an acceptable tradeoff.
What about computers that really can't handle something like 144 Hz or higher output? Well, tough call. I mean, I have some fairly old computers that can definitely handle at least 100 Hz very well on desktop. I'm talking Pentium 4 machines with old GeForce cards. Linux is certainly happy to go older (though the baseline has been inching up there; I think you need at least Pentium now?) but I do think there is a point where you cross a line where asking for things to work well is just too much. At that point, it's not a matter of asking developers to not waste resources for no reason, but asking them to optimize not just for reasonably recent machines but also to optimize for machines from 30 years ago. At a certain point it does feel like we have to let it go, not because the computers are necessarily completely obsolete, but because the range of machines to support is too wide.
Obviously, though, simply going for higher refresh rates can't fix everything. Plenty of laptops have screens that can't go above 60 Hz, and they are forever stuck with a few extra milliseconds of latency when using a compositor. It is unideal, but what are you going to do? Compositors offer many advantages, it seems straightforward to design for a future where they are always on.
Love your post. So, don’t take this as disagreement.
I’m always a little bewildered by frame rate discussions. Yes, I understand that more is better, but for non-gaming apps (e.g. “productivity” apps), do we really need much more than 60 Hz? Yes, you can get smoother fast scrolling with higher frame rate at 120 Hz or more, but how many people were complaining about that over the last decade?
I enjoy working on my computer more at 144Hz than 60Hz. Even on my phone, the switch from 60Hz to a higher frame rate is quite obvious. It makes the entire system feel more responsive and less glitchy. VRR also helps a lot in cases where the system is under load.
60Hz is actually a downgrade from what people were used to. Sure, games and such struggled to get that kind of performance, but CRT screens did 75Hz/85Hz/100Hz quite well (perhaps at lower resolutions, because full-res 1200p sometimes made text difficult to read on a 21 inch CRT, with little benefit from the added smoothness as CRTs have a natural fuzzy edge around their straight lines anyway).
There's nothing about programming or word processing that requires more than maybe 5 or 6 fps (very few people type more than 300 characters per minute anyway) but I feel much better working on a 60 fps screen than I do a 30 fps one.
Everyone has different preferences, though. You can extend your laptop's battery life by quite a bit by reducing the refresh rate to 30Hz. If you're someone who doesn't really mind the frame rate of their computer, it may be worth trying!
CRT screens did 75Hz/85Hz/100Hz quite well, but rendered only one pixel/dot at a time. This is in no way equivalent to 60Hz on a flat panel!
It isn't equivelent in the sense that the progressive scanout on CRTs resulted in near-zero latency and with minimal image persistance, versus flat panels which are global refresh adding latency and worsening motion clarity. So it isn't really a "but", it's a "made even better by being rendered only one pixel/dot at a time".
Motion clarity yes, but it's zero latency in the least useful way possible, only true when you're rendering the top and bottom of the screen at different points in time. And scanout like that isn't unique to CRTs, many flat panels can do it too.
When rendering a full frame at once and then displaying it, a modern screen is not only able to be more consistent in timing, it might be able to display the full frame faster than a CRT. Let's say 60Hz, and the frame is rendered just in time to start displaying. A CRT will take 16 milliseconds to do scanout. But if you get a screen that supports Quick Frame Transport, it might send over the frame data in only 3 milliseconds, and have the entire thing displayed by millisecond 4.
I never complained about 60, then I went to 144 and 60 feels painful now. The latency is noticable in every interaction, not just gaming. It's immediately evident - the computer just feels more responsive, like you're in complete control.
Even phones have moved in this direction, and it's immediately noticable when using it for the first time.
I'm now on 240hz and the effect is very diminished, especially outside of gaming. But even then I notice it, although stepping down to 144 isn't the worst. 60, though, feels like ice on your teeth.
Did you use the same computer at both 60 and 144? I have no doubt that 144 feels smoother for scrolling and things like that. It definitely should. But if you upgraded your system at the same time you upgraded your display, much of the responsiveness would be due to a faster system.
I have a projector that can project 4k at 60hz or 1080p at 240, and I can really notice it by just moving the cursor around. I don’t need to render my games anywhere near 240 to notice that too. Same with phones - moving from pixel 3 to pixel 5, scrolling through settings or the home screen was a palpable difference. Pixel 3 now feels broken. It is not.m, it just renders at 60 instead of 90 fps.
Yes same system, then again at 240hz. Realistically I think just about any modern GPU can composite at 240 fps, although I see what you mean if I did an SSD upgrade or something, but I didn't.
> how many people were complaining about that over the last decade?
Quite a few. These articles tend to make the rounds when it comes up: https://danluu.com/input-lag/ https://lwn.net/Articles/751763/ Perception varies from person to person, but going from my 144hz monitor to my old 60hz work laptop is so noticeable to me that I switched it from a composited wayland DE to an X11 WM.
Input lag is not the same as refresh rate. 60 Hz is 16.7 ms per frame. If it takes a long time for input to appear on screen it’s because of the layers and layers of bloat we have in our UI systems.
Refresh rate directly affects one of the components of total input lag, and increasing refresh rate is one of the most straightforward ways for an end user to chip away at that input lag problem.
Well, sure. But so is buying a faster processor.
Empirically latency has gone up instead of down with faster processors.
Naive triple buffering shall not be defeated by a faster CPU.
If our mouse cursors are going to have half a frame of latency, I guess we will need 60Hz or 120Hz desktops, or whatever.
I dunno. It does seem a bit odd, because who was thinking about the framerates of, like, desktops running productivity software, for the last couple decades? I guess I assumed this would never be a problem.
Mouse cursor latency and window compositing latency are two separate things. I probably did not do a good enough job conveying this. In a typical Linux setup, the mouse cursor gets its own DRM plane, so it will be rendered on top of the desktop during scanout right as the video output goes to the screen.
There are two things that typically impact mouse cursor latency, especially with regards to Wayland:
- Software-rendering, which is sometimes used if hardware cursors are unavailable or buggy for driver/GPU reasons. In this case the cursor will be rendered onto the composited desktop frame and thus suffer compositor latency, which is tied to refresh rate.
- Atomic DRM commits. Using atomic DRM commits, even the hardware-rendered cursors can suffer additional latency. In this case, the added latency is not necessarily tied to frame times or refresh rates. Instead, its tied to when during the refresh cycle the atomic commit is sent; specifically, how close to the deadline. I think in most cases we're talking a couple milliseconds of latency. It has been measured before, but I cannot find the source.
Wayland compositors tend to use atomic DRM commits, hence a slightly more laggy mouse cursor. I honestly couldn't tell you if there is a specific reason why they must use atomic DRM, because I don't have knowledge that runs that deep, only that they seem to.
Mouse being jumpy shouldn’t be related to refresh rate. The mouse driver and windowing system should keep track of the mouse position regardless of the video frame rate. Yes, the mouse may jump more per frame with a lower frame rate, but that should only be happening when you move the mouse a long distance quickly. Typically, when you do that, you’re not looking at the mouse itself but at the target. Then, once you’re near it, you slow down the movement and use fine motor skills to move it onto the target. That’s typically much slower and frame rate won’t matter much because the motion is so much smaller.
I agree. Keyboard-action-to-result-on-screen latency is much more important, and we are typically way above 17 ms for that.
Yep, agreed, though it’s not just keyboard to screen. It’s also mouse click to screen. Really, any event to screen.
Initially I wrote “input device”, but since mouse movements aren’t generally a problem, I narrowed it to “keyboard”. ;) Mouse clicks definitely fall into the same category, though.
Essentially, the only reason to go over 60 Hz for desktop is for a better "feel" and for lower latency. Compositing latency is mainly centered around frames, so the most obvious and simplest way to lower that latency is to shorten how long a frame is, hence higher frame rates.
However, I do think that high refresh rates feel very nice to use even if they are not strictly necessary. I consider it a nice luxury.
Fair
I couldn't find ready stats on what percentage of displays are 60 hz but outside of gaming and high end machines I suspect 60 hz is still the majority of of machines used by actual users meaning we should evaluate the latency as it is observed by most users.
The point is that we can improve latency of even old machines by simply attaching a display output that supports a higher refresh rate, or perhaps even variable refresh rate. This can negate most of the unavoidable latency of a compositor, while other techniques can be used to avoid compositor latency in more specific scenarios and try to improve performance and frame pacing.
A new display is usually going to be cheaper than a new computer. Displays which can actually deliver 240 Hz refresh rates can be had for under $200 on the lower end, whereas you can find 180 Hz displays for under $100, brand new. It's cheap enough that I don't think it's even terribly common to buy/sell the lower end ones second-hand.
For laptops, well, there is no great solution there; older laptops with 60 Hz panels are stuck with worse latency when using a compositor.
Plenty of brand new displays are still sold that only go up to 60hz, especially if you want high quality IPS panels.
They aren't as common now, but when making a list of screens to replace my current one, I am limiting myself to IPS panels and quite a few of the modern options are still 60hz.
Yeah, I personally still have a lot of 60 Hz panels. One of my favorites is a 43" 4K IPS. I don't think I will be able to get that at 120+ Hz any time soon.
Of course, this isn't a huge deal to me. The additional latency is not an unusable nightmare. I'm just saying that if you are particularly latency sensitive, it's something that you can affordably mitigate even when using a compositor. I think most people have been totally fine eating the compositor latency at 60 Hz.
> Can the compositor replicate the input-to-pixel latency of uncomposited x11 on low-end devices or is that a class of performance we just have to sacrifice for the frame-perfect rendering of wayland?
well, the answer is just no, wayland has been consistently slower than X11 and nothing running on top can't really go around that
Can you cite any sources for that claim? I found this blog post that says wayland is pretty much on par with X11 except for XWayland, which should be considered a band-aid only anyways: https://davidjusto.com/articles/m2p-latency/
Here's one article: https://mort.coffee/home/wayland-input-latency/
It's specifically about cursor lag, but I think that's because it's more difficult to experimentally measure app rendering latency.
[dead]
> wayland has been consistently slower than X11
Wayland is a specification, it has an inability to be "faster" than other options. That's like saying JSON is 5% slower than Word.
And as for the implementations being slower than X, that also doesn't reflect reality.
https://www.phoronix.com/review/ubuntu-2504-x11-gaming
There is no Wayland to run on top of as its a standard to implement rather than a server to talk to.
Xfce / xfwm4 doesn't offer focus stealing prevention.
Settings -> Window Manager Tweaks -> Focus -> Activate focus stealing prevention
https://gitlab.xfce.org/xfce/xfwm4/-/blob/master/settings-di...
I hope that XFCE remains a solid lightweight desktop option. I've become a huge fan of KDE over the past couple of years, but it certainly isn't what you would consider lightweight or minimal.
Personally, I'm a big proponent of Wayland and not big Rust detractor, so I don't see any problem with this. I do, however, wonder how many long-time XFCE fans and the folks who donated the money funding this will feel about it. To me the reasoning is solid: Wayland appears to be the future, and Rust is a good way to help avoid many compositor crashes, which are a more severe issue in Wayland (though it doesn't necessarily need to be fatal, FWIW.) Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary.
Of course, if they made the right choice, it should be apparent in relatively short order, so I wish them luck.
> Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary.
Very long time (since 2007) XFCE user here. I don't think this is accurate. We want things to "just work" and not change for no good reason. Literally no user cares what language a project is implemented in, unless they are bored and enjoy arguing about random junk on some web forum. Wayland has the momentum behind it, and while there will be some justified grumbling because change is always annoying, the transition will happen and will be fairly painless as native support for it continues to grow. The X11 diehards will go the way of the SysV-init diehards; some weird minority that likes to scream about the good old days on web forums but really no one cares about.
There are good reasons to switch to Wayland, and I trust the XFCE team to handle the transition well. Great news from the XFCE team here, I'm excited for them to pull this off.
I used XFCE for a long time and I very much agree. it just works, and is lightweight. I use KDE these days but XFCE would be my second choice.
> The X11 diehards will go the way of the SysV-init diehard
I hope you are not conflating anti-systemD people with SysV init diehards? As far as I can see very few people want to keep Sysv init, but there are lots who think SystemD init is the wrong replacement, and those primarily because its a lot more than an init system.
In many ways the objects are opposite. People hate system D for being more than init, people hate Wayland for doing less than X.
Edit: corrected "Wayland" to "XFCE" in first sentence!
It is refreshing to see somebody else notice that the complaints about systemd and Wayland are philosophically incompatible.
Systemd is creating the same kind of monolith monoculture that Xorg represented. Wayland is far more modular.
Regardless of your engineering preferences, rejecting change is the main reason to object to both.
> Wayland is far more modular.
Not sure I agree here, assuming you mean "... than X11". With Wayland, you put your display code, input-handling code, compositor code, session-handling code, and window-management code all in the same process. (Though there is a Wayland protocol being worked on to allow moving the WM bits out-of-process.)
With X11, display and input-handling are in the X server, and all those other functions can be in other processes, communicating over standard interfaces.
> you put your display code, input-handling code, compositor code, session-handling code, and window-management code all in the same process
That's an implementation detail. You can absolutely separate one out from the other and do IPC - it just doesn't make much sense to do so for most of these.
The only one where I see it making sense is the window manager, which can simply be an extension/plugin either in a scripting language or in wasm or whatever.
It's not an implementation detail that X11 specifies interfaces between those separate components and Wayland does not - X11 is designed for for the window manager being separate from the display server, Wayland is designed for them being the same.
Wayland simply leaves it up to the implementor - ergo, an implementation detail.
Sure if you want to water down the meaning of words to uselessness then you do you.
I do not have a strong opinion about Xorg vs Wayland. My only real concern is that it might make it harder for the BSDs but that seems to be being dealt with. I do like being able to use X over the nextwork but that is a problem that can be solved.
I do dislike System D for two reasons. One is exactly because it s a monolith and, in effect, an extension of the OS. The other is the attitude of the developers which becomes very evident if you browser the issues.
> I do like being able to use X over the nextwork but that is a problem that can be solved.
And in fact has been: https://github.com/wayland-transpositor/wprs
> My only real concern is that it might make it harder for the BSDs
Our OpenBSD packager has already said in our Matrix channel that he'll be testing here and there in order to keep me honest ;)
How is Wayland more modular? It conflates the window manager, the compositor, and the display server, all into a single component that must be replaced as a single unit. This kind of new conflation is exactly what people dislike about systemd.
It's less monolithic in the sense that instead of one creaky unmaintainable ancient mass of software doing the actual rendering gruntwork there are now five (and counting) somewhat incompatible slick untested new masses of software doing it in slightly different ways that application developers have to worry about. It's kind of a pick your poison situation.
IME it's always best to read any claims of "unmaintainable" as "not as fun as designing something new". Nothing is truly unmaintainable if the will is there.
I know OpenBSD's fork of it is being maintained just fine even though they've declared it feature-complete (which for some reason is anathema to a lot of people).
> It is refreshing to see somebody else notice that the complaints about systemd and Wayland are philosophically incompatible.
Only in reductio ad absurdum.
Nitpick, it's "systemd" not "SystemD"
If Rust has one weakness right now, it's bindings to system and hardware libraries. There's a massive barrier in Rust communicating with the outside ecosystem that's written in C. The definitive choice to use Rust and an existing Wayland abstraction library narrows their options down to either creating bindings of their own, or using smithay, the brand new Rust/Wayland library written for the Cosmic desktop compositor. I won't go into details, but Cosmic is still very much in beta.
It would have been much easier and cost-effective to use wlroots, which has a solid base and has ironed out a lot of problems. On the other hand, Cosmic devs are actively working on it, and I can see it getting better gradually, so you get some indirect manpower for free.
I applaud the choice to not make another core Wayland implementation. We now have Gnome, Plasma, wlroots, weston, and smithay as completely separate entities. Dealing with low-level graphics is an extremely difficult topic, and every implementor encounters the same problems and has to come up with independent solutions. There's so much duplicated effort. I don't think people getting into it realize how deceptively complex and how many edge-cases low-level graphics entails.
(xfwl4 author here.)
> using smithay, the brand new Rust/Wayland library
Fun fact: smithay is older than wlroots, if you go by commit history (January 2017 vs. April 2017).
> It would have been much easier and cost-effective to use wlroots
As a 25+ year C developer, and a ~7-year Rust developer, I am very confident that any boost I'd get from using wlroots over smithay would be more than negated by debugging memory management and ownership issues. And while wlroots is more batteries-included than smithay, already I'm finding that not to be much of a problem, given that I decided to base xfwl4 on smithay's example compositor, and not write one completely from scratch.
Thanks for the extra info. I'm glad it hasn't turned out to be much of an issue. I've looked at your repository and it seems to be off to a great start.
Personally, I'm anxious to do some bigger rust projects, but I'm usually put off by the lack of decent bindings in my particular target area. It's getting better, and I'm sure with some time the options will fill out more.
There really isn't a "massive barrier" to FFI. Autogenerate the C bindings and you're done. You don't have to wrap it in a safe abstraction, and imo you shouldn't.
This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem. Keeping the whole “it’s funded by the Government/Google etc” nonsense aside: I personally wish that at least a feeble attempt would be made to actually use the FFI capabilities that Rust and its ecosystem has before folks form an opinion. Personally - and I’m not ashamed to state that I’m an early adopter of the language - it’s very good. Please consider that the Linux kernel project, Google, Microsoft etc went down the Rust path not on a whim but after careful analysis of the pros and cons. The pros won out.
> This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem.
I have done it and it left a bad taste in my mouth. Once you're doing interop with C you're just writing C with Rust syntax topped off with a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer. It's unergonomic and you lose the differentiating features of Rust. Writing safe bindings is painful, and using community written ones tends to pull in dozens of dependencies. If you're interfacing a C library and want some extra features there are many languages that care far more about the developer experience than Rust.
> a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer
You just have to get over that. `unsafe` means "compiler cannot prove this to be safe." FFI is unsafe because the compiler can't see past it.
> Once you're doing interop with C you're just writing C with Rust syntax
Just like C++, or go, or anything else. You can choose to wrap it, but that's just indirection for no value imo. I honestly hate seeing C APIs wrapped with "high level" bindings in C++ for the same reason I hate seeing them in Rust. The docs/errors/usage are all in terms of the C API and in my code I want to see something that matches the docs, so it should be "C in syntax of $language".
> a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer
That's bizarrely emotional. It's a language feature that allows you to do things the compiler would normally forbid you from doing. It's there because it's sometimes necessary or expedient to do those things.
My point is that using C FFI is "the things the compiler would normally forbid you from doing" so if that's a major portion of your program then you're better off picking a different language. I don't dislike rust, but it's not the right tool for any project that relies heavily on C libraries.
> The X11 diehards will go the way of the SysV-init diehards; some weird minority
I upvoted your general response but this line was uncalled for. No need to muddy the waters about X11 -> Wayland with the relentlessly debated, interminable, infernal init system comparison.
Just wait for systemd-wayland.
Systemd does not have to force Wayland as it is already going the other way. Both GNOME and KDE are requiring systemd now.
KDE support doesn't even require Linux, let alone Systemd: https://community.kde.org/FreeBSD/Setup
GNOME, on the other hand, practically wants everything running on the exact same software stack, so it requiring a package means nothing.
This discussion is originally about xfce, which does not require systemd now.
Gnome?
> Literally no user cares what language a project is implemented in
This is only true most of the time - some languages have properties which "leak" to user.
Like if it's Java process, then sooner or later user will have to mess with launchers and -Xmx option.
Or if it's a process which has lots of code and must not crash, language matters. C or C++ would segfault on any sneeze. Python or Ruby or even Java would stay alive (unless they run out of memory, or hang due to a logic bug)
> even Java
That "even Java" that runs half of the internet and most fortune 500 companies business critical infrastructure..
And 70% of mobile market share, that people forget about, even if isn't the proper coffee flavour.
> The X11 diehards will go the way of the SysV-init diehards; some weird minority that likes to scream about the good old days on web forums but really no one cares about.
Being proud of how you are uncaring towards others is a sad state of affairs.
> Literally no user cares what language a project is implemented in
I think this is true but also maybe not true at the same time.
For one thing, programming languages definitely come with their own ecosystems and practices that are common.
Sometimes, programming languages can be applied in ways that basically break all of the "norms" and expectations of that programming language. You can absolutely build a bloated and slow C application, for example, so just using C doesn't make something minimal or fast. You can also write extremely reliable C code; sqlite is famously C after all, so it's clearly possible, it just requires a fairly large amount of discipline and technical effort.
Usually though, programs fall in line with the norms. Projects written in C are relatively minimal, have relatively fewer transitive dependencies, and are likely to contain some latent memory bugs. (You can dislike this conclusion, but if it really weren't true, there would've been a lot less avenues for rooting and jailbreaking phones and other devices.)
Humans are clearly really good at stereotyping, and pick up on stereotypes easily without instruction. Rust programs have a certain "feel" to them; this is not delusion IMO, it's likely a result of many things, like the behaviors of clap and anywho/Rust error handling leaking through to the interface. Same with Go. Even with languages that don't have as much of a monoculture, like say Python or C, I think you can still find that there are clusters of stereotypes of sorts that can predict program behavior/error handling/interfaces surprisingly well, that likely line up with specific libraries/frameworks. It's totally possible to, for example, make a web page where there are zero directly visible artifacts of what frameworks or libraries were used to make it. Yet despite that, when people just naturally use those frameworks, there are little "tells" that you can pick up on a lot of the time. You ever get the feeling that you can "tell" some application uses Angular, or React? I know I have, and what stuns me is that I am usually right (not always; stereotypes are still only stereotypes, after all.)
So I think that's one major component of why people care about the programming language that something is implemented in, but there's also a few others:
- Resources required to compile it. Rust is famously very heavy in this regard; compile times are relatively slow. Some of this will be overcome with optimization, but it still stands to reason that the act of compiling Rust code itself is very computationally expensive compared to something as simple as C.
- Operational familiarity. This doesn't come into play too often, but it does come into play. You have to set a certain environment variable to get Rust to output full backtraces, for example. I don't think it is part of Rust itself, but the RUST_LOG environment variable is used by multiple libraries in the ecosystem.
- Ease of patching. Patching software written in Go or Python, I'd argue, is relatively easy. Rust, definitely can be a bit harder. Changes that might be possible to shoehorn in in other languages might be harder to do in Rust without more significant refactoring.
- Size of the resulting programs. Rust and Go both statically link almost all dependencies, and don't offer a stable ABI for dynamic linking, so each individual Rust binary will contain copies of all of their dependencies, even if those dependencies are common across a lot of Rust binaries on your system. Ignoring all else, this alone makes Rust binaries a lot larger than they could be. But outside of that, I think Rust winds up generating a lot of code, too; trying to trim down a Rust wasm binary tells you that the size cost of code that might panic is surprisingly high.
So I think it's not 100% true to say that people don't care about this at all, or that only people who are bored and like to argue on forums ever care. (Although admittedly, I just spent a fairly long time typing this to argue about it on a forum, so maybe it really is true.)
[flagged]
I know, I know! Change is hard and scary. To be honest, while I am glad they're finally tackling this, I'm also expecting to have a pretty annoying couple of weeks whenever they ship this support and I finally decide to make the switch. There will be things to learn and new behaviors to understand and, yes, new bugs and annoyances to learn to work around. But I think if we both put our big boy pants on, keep a positive and friendly attitude, and help each other out, we can make it through these difficult times and come out the other side with proper high DPI support, sane multi-monitor handling and hot-swapping, and maybe even some wild new stuff like high color depth options.
[flagged]
Aren't you a little young to be on here? Do your parents know you're online?
You -uh- need to learn to troll better, my dude.
Kids these days... trolling used to require what's now called effortposts.
[flagged]
Why does Wayland "feel like the future?" It feels like a regression to me and a lot of other people who have run into serious usability problems.
At best, it seems like a huge diversion of time and resources, given that we already had a working GUI. (Maybe that was the intention.) The arguments for it have boiled down to "yuck code older than me" from supposed professionals employed by commercial Linux vendors to support the system, and it doesn't have Android-like separation — a feature no one really wants.
The mantra of "it's a protocol" isn't very comforting when it lacks so many features that necessitate workarounds, leading to fragmentation and general incompatibility. There are plenty of complicated, bad protocols. The ones that survive are inherently "simple" (e.g., SMTP) or "trivial" (e.g., TFTP). Maybe there will be a successor to Wayland that will be the SMTP to its X400, but to me, Wayland seems like a past compromise (almost 16 years of development) rather than a future.
Wayland supports HDR, it's very easy to configure VRR, and it's fractional scaling (if implemented properly) is far superior to anything X11 can offer.
Furthermore, all of these options can be enabled individually on multiple screens on the same system and still offer a good mix-used environment. As someone who has been using HiDPI displays on Linux for the past 7 years, wayland was such a game changer for how my system works.
Fractional scaling for wayland is broken on a per app basis which feels strictly worse to me than it was before. Libre office currently is broken on wayland and works in x11
LibreOffice works for me on wayland lol. I don't know why you would wanna do fractional scaling on a per app basis whenever you got one screen. But, for your libreoffice woes, try using a different backend?
Libreoffice includes support for gtk3, gtk4, Qt6, and other backends: https://github.com/LibreOffice/core/blob/master/vcl/README.m...
Maybe you need to try wayland with an alternative backend?
> Maybe you need to try wayland with an alternative backend?
And this is the inherent problem with Wayland. Now we have to deal with a combinatorial explosion of things to try to get something that "just works."
Which, because we're talking rendering and GPU and drivers, is incredibly frustrating, because if we're here, it's because the system doesn't have working GPU drivers, at which point, a misconfiguration is a crash and a power cycle and a "hope pstore managed to save something", and the hardware/software cursor settings getting lost somewhere-how.
More like some toolkits have really poor wayland support (cough anything GTK/Gnome cough)
I'm not trying to do it on a per app basis. I mean that some apps work and some don't. I should not be playing with rendering backends per app to get them working. If thats needed its broken.
People keep pushing KDE+Wayland to beginners either through recommendations or preconfigured stuff like bazzite. My experience is that the defaults in such a setup are broken and frustrating.
X11 can be made to support HDR as well.
VRR works on X11 without manual configuration.
Fractional scaling can be implemented in the compositor or applications.
Even if you dislike Wayland, forwards-going development is clearly centred around it.
Development of X11 has largely ended and the major desktop environments and several mainstream Linux distributions are likewise ending support for it. There is one effort I know of to revive and modernize X11 but it’s both controversial and also highly niche.
You don’t have to like the future for it to be the future.
Actually multiple including Phoenix a re-implementation, running an x wm under Wayland via Wayback in addition to xlibre
It's mostly coz nobody really wants to improve X11. I don't think there is many wayland features that would be impossible to implement in X11 it's just nobody wants to dig into crusty codebase to do it.
And sadly wayland decided to just not learn any lessons from X11 and it shows.
What do you mean nobody wants to improve X11? There were developers with dozens of open merge requests with numerous improvements to X11 that were being actively ignored/held back by IBM/Red Hat because they wanted Wayland, their corporate project, to succeed instead.
Reviewing PRs and merging them requires great effort, especially in case of a non-trivial behemoth like X. Surely if all these merge requests were of huge value, someone could have forked the project and be very happy with all the changes, right?
Not having enough maintainers, and some design issues that can't be solved are both reasons why X was left largely unmaintained.
> Surely if all these merge requests were of huge value
There were a lot of MRs with valuable changes however Red Hat wanted certain features to be exclusive to Wayland to make the alternative more appealing to people so they actively blocked these MRs from progressing.
> someone could have forked the project and be very happy with all the changes, right?
That's precisely what happened, one of the biggest contributors and maintainers got bullied by Red Hat from the project for trying to make X11 work and decided to create X11Libre (https://github.com/X11Libre/xserver) which is now getting all these fancy features that previously were not possible to get into X11 due to Red Hat actively sabotaging the project in their attempt to turn Linux into their own corporate equivalent of Windows/macOS.
My understanding is that the founder of X11Libre was removed from the X.Org project for demonstrated incompetence.
https://www.phoronix.com/news/X.Org-Server-Lots-Of-Reverts
We’re accustomed to "the future" connoting progress and improvement. Unfortunately, it isn’t always so (no matter how heavily implied). Just that it’s literally expected to be the future state if matters.
Wayland was the first display system on Linux I've used that just worked perfectly right out of the box on a bog standard Intel iGPU across several machines. I think that is a big draw for a lot of people like myself who just want to get things done. For me X11 represents the past through experience I had when I had to tinker with the X11 config file to get basic stuff like video playback to work smoothly without tearing. My first Wayland install was literally a "wow this is the future of Linux" for me quite honestly when I realised everything just worked without even a single line of config. I would recommend a Wayland distro like Debian to the average computer user knowing Wayland just works -- prior to Wayland I'd be like "well Linux is great but if you like watching YouTube you'll need to add a line to your xorg config to trun on the thingy that smoothes out video playback on Intel iGPUs". Appreciate others have different perpectives -- I come from the POV of someone who likes to install a OS and have all the basic stuff working out of the box.
Xorg.conf has worked out of the box with no or minimal configuration for the past 20 years or so.
It's nowhere near the modline hell of XFree86.
It is many years, I guess close to a decade, since I needed to change X config manually. I still find the odd rough edge in Wayland (the most recent was failing screenshots with KDE).
> It is many years, I guess close to a decade, since I needed to change X config manually.
Making manual changes in 2015+, for a protocol released in 1987, that's a long time having rough edges..
Sorry, to clarify, I am not making making manual changes to Wayland config. I have stopped needing to make manual changes to X config.
Until recently i just switched back to X whenI had problems with Wayland. The last time the issues fixed itself on the next update.
Because X is not getting much development at this point (personally I still use i3, haven’t switched to Sway, the present works fine for me).
This argument is actually backwards: one of the goals of the wayland project is to draw development away from X. If wayland didn't exist, people would have worked on X11 a lot more.
It's not an argument in the first place: it's describing the current situation. Wayland does exist, and did draw development away from X.
Not quite. Wayland was created in part to draw developers away from X. Seeking buy-in from Xorg developers specifically was a big part of it.
This seems to be implying that the creation of Wayland had some motivation that was essentially malicious toward X. Is that right?
This question sounds to me like you suspect some outright evil getting projected here. That would go too far. The wayland project tried to get the support of X developers early so that they could become a sort of "blessed" X successor early on. Plenty of earlier replacement attempts have failed because they couldn't get bigger community support, so this had to be part of a successful strategy. Any detrimental effects on X from that move were never a direct goal, as far as I am aware, just a consequence.
This isn't quite right? Wayland was literally created by an X11 developer who got two more main X11 developers in. It's a second system, not a competitor as such.
Yes, I do interpret your “draw development away from X” as suggesting an attempt to damage X (sorry if I misinterpreted your post, but I do think my interpretation was not really that unreasonable).
This “blessed successor” without and detrimental effects as a main goal: that’s pretty close to my understanding of the project. IIRC some X people were involved from the beginning, right?
Wanting developers to switch projects doesn't have to be malicious, in fact personally i doubt there were any bad intentions in place, the developers of Wayland most likely think they're doing the right thing.
Hmm? Seems to be getting plenty of development.
https://github.com/X11Libre/xserver/activity
That’s a fork, which is fine. But for example, users from most mainstream distros will have to compile it themselves.
I guess we’ll see if that development is ever applied to the main branch, or if it supplants the main X branch. At the moment, though… if that’s the future of X, then it is fair to be a little bit unsure if it is going to stick, right?
the kind that introduces regressions?
there is a reason lead developer of X11Libre left Xorg project, they did not like broken code: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1760 (and many more if you search)
That's X.org, which is controlled by the Free Desktop Foundation.
The OpenBSD people are still working on Xenocara, and it introduces actual security via pledge system calls.
That seems pretty interesting. I guess it relies on BSD plumbing though?
Funny enough, the my first foray into these sort of operating systems was BSD, but it was right when I was getting started. So I don’t really know which of my troubles were caused by BSD being tricky (few probably), and which were caused by my incompetence at the time (most, probably). One of these days I’ll try it again…
Yup, "pledge" is one of my BSD envies. Namespaces and unshare are significantly more complex and we're still told not to use them as a security barrier (which is explicitly in scope for pledge).
I've been on and off linux desktops since the advent of Wayland. Unsure of the actual issues people run into at this point outside of very niche workflows or applications, to which, there are X11 fallbacks for.
Also, by "commercial linux vendors", you do realize Wayland is directly supported (afaik, correct me if wrong) by the largest commercial linux contributors, Red Hat, Canoncial. They're not simply 'vendors'.
> Unsure of the actual issues people run into at this point outside of very niche workflows or applications, to which, there are X11 fallbacks for.
I don't know if others have experienced this but the biggest bug I see in Wayland right now is sometimes on an external monitor after waking the computer, a full-screen electron window will crash the display (ie the display disconnects).
I can usually fix this by switching to another desktop and then logging out and logging back in.
Such a strange bug because it only affects my external monitor and only affects electron apps (I notice it with VSCode the most but that's just cause I have it running virtually 24/7)
If anyone has encountered this issue and figured out a solution i am all ears.
This is probably worth reporting. I don't think I've ever heard or ran into something like that before. Most issues I ran into during the early rollout of Wayland desktop environments was broken or missing functionality in existing apps.
Is it gnome or kde or what?
That's like saying "the website doesn't work", without saying what browser you are using.
Happens on any DE running Wayland. Ive gotten it to happen on both Gnome and KDE.
It is also used on ChromeOS, and on WSL.
> it doesn't have Android-like separation — a feature no one really wants.
It's certainly a feature I want. Pretty sure I'm not alone in wanting isolation between applications--even GUI ones. There's no reason that various applications from various vendors shouldn't be isolated into their own sandboxes (at least in the common case).
There is a big reason: It impedes usability, extensibility and composability. If you sandbox GUI applications then the sandbox needs to add support for any interaction between them or they will just not be possible - and to fully support many advanced interactions like automation you will essentially have to punch huge holes in the sandbox anyway.
Meanwhile the advantages of sandboxing are pretty much moot in an open source distro where individual applications are open and not developed by user hostile actors.
Yes, sandboxing impedes those things. But I assume you're not advocating against sandboxing in general, right?
Starting with a sandbox and poking holes/whitelisting as-needed is a good way to go. Whitelisting access on a per-application basis is a pragmatic way to do this, and Flatpak with Wayland gives a way to actually implement this. It's imperfect, but it's a good start.
Preventing keylogging is a good, concrete example here. There's no reason some random application should be able to see me type out the master password in my password manager.
Likewise, there is no reason that some other application should be able to read ~/.bash_history or ~/.ssh/. The browser should limit itself to ~/Downloads. Etc.
> Meanwhile the advantages of sandboxing are pretty much moot in an open source distro where individual applications are open and not developed by user hostile actors.
Defense in depth. Belt and suspenders. I do trust the software I run to some degree, and take great care in choosing the software. But it's not perfect. Likewise, I take care to use sandboxing features whenever I can, acknowledging that they sometimes must have holes poked in them. But the Swiss cheese model is generally a good lens: https://en.wikipedia.org/wiki/Swiss_cheese_model
If we weren't concerned with belt and suspenders and could rely on applications being developed by non-hostile actors, then we could all run as root all the time! But we don't do that--we try to operate according to least-privilege and isolate separate tasks as much as is practical. Accordingly, technologies which allow improved isolation with zero or minimal impact to functionality are strictly a good thing, and should be embraced as such.
> given that we already had a working GUI. (Maybe that was the intention.)
Neither X11 nor Wayland provide a GUI. Your GUI is provided by GTK or QT or TCL or whatever. X11 had primitive rendering instructions that allowed those GUIs to delegate drawing to a central system service, but very few things do that anymore anyway. Meaning X11 is already just a dumb compositor in practice, except it's badly designed to be a dumb compositor because that wasn't its original purpose. As such, Wayland is really just aligning the protocol to what clients actually want & do.
> "yuck code older than me"
You mean like the code that the Manchester Baby, ENIAC, the Manchester Mark 1, EDSAC and EDVAC ran? Or maybe Plankalkül...
Here's my PoV:
- Having a single X server that almost everyone used lead to ossification. Having Wayland explicitly be only a protocol is helping to avoid that, though it comes with its own growing pains.
- Wayland-the-Protocol (sounds like a Sonic the Hedgehog character when you say it like that) is not free of cruft, but it has been forward-thinking. It's compositor-centric, unlike X11 which predates desktop compositing; that alone allows a lot of clean-up. It approaches features like DPI scaling, refresh rates, multi-head, and HDR from first principles. Native Wayland enables a much better laptop docking experience.
- Linux desktop security and privacy absolutely sucks, and X.org is part of that. I don't think there is a meaningful future in running all applications in their own nested X servers, but I also believe that trying to refactor X.org to shoehorn in namespaces is not worth the effort. Wayland goes pretty radical in the direction of isolating clients, but I think it is a good start.
I think a ton of the growing pains with Wayland come from just how radical the design really is. For example, there is deliberately no global coordinate space. Windows don't even know where they are on screen. When you drag a window, it doesn't know where it's going, how much it's moving, anything. There isn't even a coordinate space to express global positions, from a protocol PoV. This is crazy. Pretty much no other desktop windowing system works this way.
I'm not even bothered that people are skeptical that this could even work; it would be weird to not be. But what's really crazy, is that it does work. I'm using it right now. It doesn't only work, but it works very well, for all of the applications I use. If anything, KDE has never felt less buggy than it does now, nor has it ever felt more integrated than it does now. I basically have no problems at all with the current status quo, and it has greatly improved my experience as someone who likes to dock my laptop.
But you do raise a point:
> It feels like a regression to me and a lot of other people who have run into serious usability problems.
The real major downside of Wayland development is that it takes forever. It's design-by-committee. The results are actually pretty good (My go-to example is the color management protocol, which is probably one of the most solid color management APIs so far) but it really does take forever (My go-to example is the color management protocol, which took about 5 years from MR opening to merging.)
The developers of software like KiCad don't want to deal with this, they would greatly prefer if software just continued to work how it always did. And to be fair, for the most part XWayland should give this to you. (In KDE, XWayland can do almost everything it always could, including screen capture and controlling the mouse if you allow it to.) XWayland is not deprecated and not planned to be.
However, the Wayland developers have taken a stance of not just implementing raw tools that can be used to implement various UI features, but instead implement protocols for those specific UI features.
An example is how dragging a window works in Wayland: when a user clicks or interacts with a draggable client area, all the client does is signal that they have, and the compositor takes over from there and initiates a drag.
Another example would be how detachable tabs in Chrome work in Wayland: it uses a slightly augmented invocation of the drag'n'drop protocol that lets you attach a window drag to it as well. I think it's a pretty elegant solution.
But that's definitely where things are stuck at. Some applications have UI features that they can't implement in Wayland. xdg-session-management for being able to save and restore window positions is still not merged, so there is no standard way to implement this in Wayland. ext-zones for positioning multi-window application windows relative to each-other is still not merged, so there is no standard way to implement this in Wayland. Older techniques like directly embedding windows from other applications have some potential approaches: embedding a small Wayland compositor into an application seems to be one of the main approaches in large UI toolkits (sounds crazy, but Wayland compositors can be pretty small, so it's not as bad as it seems) whereas there is xdg-foreign which is supported by many compositors (Supported by GNOME, KDE, Sway, but missing in Mir, Hyprland and Weston. Fragmentation!) but it doesn't support every possible thing you could do in X11 (like passing an xid to mpv to embed it in your application, for example.)
I don't think it's unreasonable that people are frustrated, especially about how long the progress can take sometimes, but when I read these MRs and see the resulting protocols, I can't exactly blame the developers of the protocols. It's a long and hard process for a reason, and screwing up a protocol is not a cheap mistake for the entire ecosystem.
But I don't think all of this time is wasted; I think Wayland will be easier to adapt and evolve into the future. Even if we wound up with a one-true-compositor situation, there'd be really no reason to entirely get rid of Wayland as a protocol for applications to speak. Wayland doesn't really need much to operate; as far as I know, pretty much just UNIX domain sockets and the driver infrastructure to implement a WSI for Vulkan/GL.
Thanks a lot for an actually constructive comment on Wayland! The information tends to be lost in all the hate.
I understand the frustration, but I see a lot of "it's completely useless" and "it's a regression", though to me it really sounds like Wayland is an improvement in terms of security. So there's that.
The fact that this post is downvoted into grayness while lazy hateful rants aren't shows just how rotten HN community has gotten around opensource these days :/
> xdg-session-management for being able to save and restore window positions > is still not merged, so there is no standard way to implement this in Wayland
For me, this is a real reason not to want to be forced to use Wayland. I'm sure the implementation of Wayland in xfce is a long time off, and the dropping of Xwindows even further off, so hopefully this problem will have been solved by then.
Yeah, this is a feature I use a lot. If it was no longer there I would need to switch to a scriptable window manager and manually script positions.
You seen to know your Waylands.
Do you know if global shortcuts are solved in a satisfactory way, and if there easy mechanism for one application to query wayland about other applications.
One hack I've made a while ago was to bind win+t command to a script that queried the active window in the current workspace, and based on a decision opened up a terminal at the right filesystem location, with a preferred terminal profile.
All I get from llms is that dbus might be involved in gnome for global shortcuts, and when registering global shortcuts in something like hyperland app ids must be passed along, instead of simple scripts paths.
Currently, the Wayland protocol itself doesn't have a standard solution to global shortcuts. Instead, it's being pushed to the XDG Desktop Portal API, under the org.freedesktop.portal.GlobalShortcuts service:
https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.fr...
This should work with Hyprland provided that you are using xdg-desktop-portal-hyprland, as it does indeed have an implementation of GlobalShortcuts.
I'm not sure if this API is sufficient for your needs, or if it is too much of a pain to use. Like many Wayland things, it prescribes certain use cases and doesn't handle others. The "configure" call seems to rely on xdg-foreign-unstable-v2 support, but AFAIK Hyprland doesn't support this protocol, so I have no idea what you're supposed to do on Hyprland for this case.
I am sorry to see developers have to deal with things in a relatively unfinished state, but such is the nature of the open source desktop.
Thanks for the insight, I really appreciate it. I don't use hyperland (just what came up as brief research). Xfce generally has simple and legible code, hopefully this wayland compositor will be just as hackable and tweakable for my needs.
It's a downgrade that we have no choice but to accept in order to continue using our machines. Anyone familiar with Microsoft or Apple already knows that's the future.
> It's a downgrade that we have no choice but to accept in order to continue using our machines.
Odd. Xorg still works fine [0], and we'll see how XLibre pans out.
[0] I'm using it right now, and it's still getting updates.
They're trying to "nudge" everyone. Major desktop environments and entire distributions are removing X11 support to varying degrees. A lot of this is because they can't get their adoption rates above about half due to various broken workflows or simply user preference.
They intentionally don't want you to keep using X11, and they'll keep turning up the heat on the pot until we're all boiling.
Gnome just removed the middle-click paste option. Is that because they fixed the clipboard situation on Linux, and there's a universal, unambiguous way of cut and paste that works across every application? No. It's because middle-click to paste is an "X-ism." This is just demagoguery and unserious.
> Gnome just removed the middle-click paste option. Is that because they fixed the clipboard situation on Linux, and there's a universal, unambiguous way of cut and paste that works across every application? No. It's because middle-click to paste is an "X-ism." This is just demagoguery and unserious.
They disabled it by default. You can enable it if you want.
We all know that that's a precursor to removing a feature entirely because "telemetry shows it isn't being used".
> They're trying to "nudge" everyone.
Once again, Gentoo Linux proves (somewhat regrettably) to be one of the best Linux distros out there. OpenRC and Xorg as defaults, with SystemD and Wayland as supported options is quite a lovely way to do things.
> Gnome just removed the middle-click paste option.
Gnome removes useful things all the time. "The Gnome folks do something user-hostile just because they feel like it" isn't news; that's been going on for decades. This habit of theirs is a big reason why I've been using KDE for a very long time.
Unfortunately I don't think Gentoo will keep X11 support in e.g. KDE once its dropped upstream (which is already announced), they don't have the manpower for that.
And KDE itself is also not the bastion of user choice it once was, even if they haven't yet gone quite as hostile as Gnome.
> Unfortunately I don't think Gentoo will keep X11 support in e.g. KDE once its dropped upstream...
IIRC, the only part that's dropping X11 support is Plasma. From [0]:
I don't really care about Plasma; a taskbar to house a system tray and clock is nice, as is desktop wallpaper, but I don't particularly care about that stuff. I use very little of KDE: kwin, krunner, kmix, kcalc, okular, dolphin (rarely), and whatever handles the global keyboard shortcuts.Hell, on my ~twenty-year-old computer I don't use Plasma because it's a resource hog, but I still use KDE.
[0] <https://blogs.kde.org/2025/11/26/going-all-in-on-a-wayland-f...>
That's fair, but I would also read it as a sign of things to come for the rest. If you can't run full KDE on X11 there will not be many KDE developers caring about X11 support. KWin for example has already gained many bugs on X11 that I expect to never be fixed. And now KWin for X11 is split into a separate project which will hopefully mean fewer further regressions but probably also not much further development which means bitrot as things around it change.
> That's fair, but I would also read it as a sign of things to come for the rest.
Given this statement from the announcement that I linked to previously
I expect that I will get at least a year's notice before they stop actively working on the rest of the parts of KDE that interact with X11... whenever that ends up being. A year is more than enough time to find replacements for things that might eventually stop working one day.Were I sixteen, I'd be very excited to preemptively move to something else. Now? The folks who work on it say that they'll keep it working for the forseeable future, and their behavior suggests that I'll get ample notice before they stop working on it.
The software in question works now (AFAICT) and will continue to work for quite a while. I am likely to get a significant amount of warning before they stop working on the software. I see no reason to switch. I have much better things to do with my time.
[flagged]
Amen brother
Yeah, I am staunch proponent of "don't try to fix what is not broken". Current XFCE is fast, light-weight, usable and works fine without major issues. While I don't fully understand the advantages / disadvantages of XFCE using Wayland instead of X, if, as someone else pointed out here on HN, running XFCE on Wayland is going to make it slower, it means these developers will be crippling one of XFCE's strongest feature. In that case other minor advantages seems pointless to users like me.
> running XFCE on Wayland is going to make it slower
Citation. None of the other desktops have slowed with Wayland, and gaming is as fast as, if not marginally faster on KDE/Gnome with Wayland vs LXDE on X.
https://www.phoronix.com/review/ubuntu-2504-x11-gaming
I based it on this thread - https://news.ycombinator.com/item?id=46780901
Latency and throughput are very different things. However, it's worth noting that the comparison here is with and without compositing. If you were using compositing already on X11 (I believe XFCE offers it with "Desktop Effects" or something to that tune) then you've already been eating compositing latency, and you should actually get less latency in some situations.
But as far as it performing worse overall, I don't think that would be expected. Compositing itself does lean more on hardware acceleration to provide a good experience, though, so if you compare it on a machine that has no hardware accelerated graphics with compositing disabled, then it really would be worse, yeah.
Little misconception here (beware i'm using xlibre and causal user). On X11 you can find two mechanisms which can be called compositor :
1st: "enable display compositing" option - this one increases latency as every window draw need go though compositor application (in nutshell it exchanging opengl textures - only synchronization messages goes over "wire")
2nd: the Xserver rendering pipeline compositor, this one goes with modesetting (intel, amdgpu) driver TearFree option - almost everything inside X11 server in OpenGL textures and compositor perform direct blending to screen (including direct scanout).
What I want to tell, on modern X (there are merge requests for Xorg server to modesetting driver, amdgpu have this code) with TearFree enabled you by default optimal hardware acceleration - there comes lower latency
I don't see any evidence on that thread for anything you said.
Long-time XFCE user here. We care that stuff works the same, we appreciate how much work it is to achieve that when the world is changing out from under you, and we appreciate that XFCE understands this and cares about it. Being in Rust is not a concern.
I don't think this will be a quick transition.
Wayland has lots of potential, but it's far from ready to replace X11, especially in multitasking environments. XFCE is taking their time, because their community is more very concerned stability.
I predict that XFCE will default to X11 until Wayland has reached broad feature parity, then default to Wayland but keep X11 support until the last vestages of incompatibility are delt with.
There's no reason that this wouldn't be accepted by their community, and it should be lighter weight, in the end.
My watch from 8 years ago runs Wayland. Nothing written in Rust as far as I can tell, though.
With that knowledge, I'm certain that XFCE will remain lightweight. It can be done, so I feel confident that the XFCE folks will get it done.
I am an XFCE user since many years, and am pretty decidedly in the "traditional and conservative about technologies" camp, and I think this is neat and just fine and dandy -- as long as they're not in a hurry to depreciate X11. Whenever I eventually have to go Wayland I would like to continue to use XFCE, so thumbs up for doing the work.
Then the future is full of high latency.
Long-time xfce fan here, I trust the team to make the right decisions of what to do with their copious spare time and insane amounts of funding </s>
(Instead of seeing this as "xfce jumps on bandwagon", I'm seeing it more as "bandwagon finally stable enough for xfce".)
Afaik there exists only X11 and Wayland, and X11 is dying if not dead. And for rust I don't see why a desktop user would be concerned by the language used as long as it is good enough.
In my view, this project itself shows some of the reasons why Wayland is the right path forward.
On X, we had Xorg and that is it. But at least Xorg did a lot of the work for you.
On Wayland, you in theory have to do a lot more of the work yourself when you build a compositor. But what we are seeing is libraries emerge that do this for you (wlroots, Smithay, Louvre, aquamarine, SWC, etc). So we have this one man project expecting to deliver a dev release in just a few months (mid-2026 is 4 months from now).
But it is not just that we have addressed the Wayland objection. This project was able to evaluate alternatives and decide the smithay is the best fit both for features and language choice. As time goes on, we will see more implementations that will compete with each other on quality and features. This will drive the entire ecosystem forward. That is how Open Source is supposed to work.
Because Wayland only does essential low-level stuff such as display and graphics it forced people to start coming up with a common Linux desktop (programming) interface out of nowhere to basically glue everything together and make programs at least interoperate.
Such an effort to rethink Linux desktop alone could've been a major project on its own but as having something was necessitated by Wayland all of it has become hurried and lacking control. Anything reminiscent of a bigger and more comprehensive project is in initial stages at best. If Wayland has been coming on for about ten years now I'll give it another ten years until we have some kind of established, consistent desktop API for Linux again.
X11 did offer some very basic features for a desktop environment so that programs using different toolkits could work together, and enough hooks you could implement stuff in window managers etc. Yet there was nothing like the more complete interfaces of the desktops of other operating systems that tied everything together in a central, consistent way. So, Linux desktop interface was certainly in need for a rewrite but the way it's happening is just disheartening.
Nobody has a user-space stick big enough to force things in the Linux world.
When Apple dropped the old audio APIs of classic macOS and introduced CoreAudio, they pissed off a lot of developers, but those developers had no choice. In the GUI realm, they only deprecated HIKit for a decade or two before removing it (if they've even done that), but they made it very clear that CoreFoo was the API you should be using and that was that.
In Linux-land, nobody has that authority. Nobody can come up with an equivalent to Core* for Linux and enforce its use. Consequently, you're going to continue to see the Qt/GTK/* splits, where the only commonality is at the lowest level of the window system (though, to Qt's credit, optionally also the event loop).
GNOME has enough weight to at least force most projects to accommodate them. But unfortunately this has mostly been for the worst, as GNOME is usually the odd one out with most matters of taste and design.
Maybe to some degree that's true. But let's take an example: GNOME is the only (afaik) desktop that requires client-side decorations. They've been like that for years, but nobody else is following them on that. Yes, the toolkits and a number of toolkit-less apps have added support for them. But it's not like they were actually able to employ their gravity to change the world over to CSD (thank goodness).
I don't think GP claimed that everyone copied everything about Gnome, just that every toolkit/program has to implement Gnomes way of doing things even if they continue to support others so you have that as a common (but often bad) interface. CSD is a good example of that - implementations of it have reached libraries like SDL that would rather not care about the desktop user interface at all but because of Gnome they have to.
You say that like it's a bad thing. If you have have an actually good design then you can convince people with those advantages instead of forcing them with a stick.
I think that's the main reason many of us use Linux actually - because we didn't like what the big stick corpos wanted to force on us.
It's not necessarily a bad thing.
But both Qt and GTK are entirely as well designed as, say, Apple's Core* frameworks for GUI development, yet neither has become the singular GUI toolkit on Linux.
One can view this as a benefit of Linux or as a disadvantage. Both are true.
systemd comes close, and can be viewed as an attempt to create such a stick...
Sorry, but systemd has absolutely nothing, or even less than nothing to do with user-space GUI desktop applications.
Ah, if only! GNOME and even to an extent KDE both depend on systemd components, to the point that systemd-free distros are compelled to fork it if they want a GUI: https://wiki.gentoo.org/wiki/Elogind
Only yesterday I was wondering how it is that my brightness keys work in my desktop environment, when /sys/class/backlight/intel_backlight/brightness is only writeable by root. The (somewhat horrifying) answer is that applications can send a request to logind over DBUS, which checks the request against opaque and arbitrarily byzantine Polkit rules, and then writes to the sysfs file on the application's behalf, which it can do because it runs as root. It's unclear quite what this achieves that simply making the file writeable by the "video" group does not, but hey at least systemd gets to be involved.
Incidentally, the correct command to change the brightness as a normal user from the command line is as follows:
So simple, so easy to remember, so superior to "echo <brightness> > /sys/class/backlight/intel_backlight/brightness". Google it for a fun thread on why the --timeout=1 is neccessary (it won't work without it!) - although I suppose I should be thankful for that little foible, as without it the thread wouldn't exist and I would never have figured out the command in the first place.As noted by others below, this has nothing to do with GUI desktop applications.
Sure, systemd is involved in running the system on which those applications run, but the discussion was about some sort of equivalent to the unified GUI stack offered by macOS (the Core* frameworks) which are used by essentially every GUI application on that platform. Linux doesn't have that, and there's nobody in a position to force that on developers. systemd has nothing to do with this.
Systemd runs each userspace desktop application in it's own control group.
Not exactly. Desktop environments (or whatever the program is that launches the application) decides to use systemd to run each application in its own cgroup.
Systemd is certainly relevant to the Linux desktop as a whole, especially regarding logind. But there's no specific relation to GUI desktop applications that I'm aware of at least.
No it doesn't. It could, but as far as I know this is not used at all.
There are user services, but that's a separate concept.
As time goes on, we will see more implementations that will compete with each other on quality and features. This will drive the entire ecosystem forward.
Unfortunately there aren't enough developers to maintain all those duplicate implementations to the level users expect so a lot of features will be missing and a lot of maintainers will burn out. Not having a libcompositor remains Wayland's biggest mistake.
The other key element with Wayland is that the kernel does a ton of the work for you. There s GEM buffer management and DMA-BUF to manage and move around video & regular memory, there's kernel mode setting, there's incredibly good mesa drivers.
X didn't have any of that to build from. It basically was a second kernel, was the OS that dealt with the video card atop the OS actual. It talked to the PCI device & did everything.
Part of the glory of Wayland is that we have fantastic really good OS abstractions & drivers. When we go to make a display server, we start at such a different level now. Trying to layer X's abstractions atop is messy & ugly & painful, because it mostly inhibits devs from being able to use the hardware in neat efficient clean direct modern ways. You have to write an X extension that coexists with a patchwork of other extensions that slots into the X way, that can figure out how to leverage the hardware. With Wayland, most compositors just use the kernel objects. There's much less intermediary, much less cruft, much less wild indirection & accretion to cut a path for.
And as you beautifully state, competing libraries can decide what abstractions & techniques work for them. There's an ecosystem of ideas, a flux to optimize hone & improve, on a variety of different dimensions. The Bazaar free to find its way vs the one giant ancient Cathedral. It's just so so so good we're finally not all trapped inside.
Tl;dr: Wayland has a much higher level that it can start from. And trying to use gpu's & hardware well in X was a nightmare because X has a sea of abstractions - extensions that you had to target & develop around, making development in X a worst of both worlds low level but having to cope with a so many high level constructs you had to navigate through.
> On Wayland, you in theory have to do a late more...
This is vaguely a double-edged sword. Yes, more code duplication across disparate projects - but that also allows people who _really care_ (such as the xfce team) to roll up their sleeves and do more. Any WM will only ever be as good as the X11 baseline, Wayland servers have the opportunity to compete on this front.
Although I'm probably permanently stuck with the Niri workflow, I am looking forward to seeing what the xfce developers come up with.
By the time we get to that utopia someone will declare Wayland obsolete and we'll all be arguing over how Nextfad is the best/worst thing ever.
And technically, nothing has been stopping the xfce devs or anyone from making their own X11 server / X.org fork if the window manager interface was too limiting.
I have no doubt about it, but for my use-cases Wayland definitely is a step up. It's definitely a first-world-problem, but somehow typing feels more enjoyable at low latency - back when I still had a backup X11 session, I could instantly tell that I had left it on: the mouse cursor, input, everything felt like soup.
This is the same logic that led to rails being shoehorned into every company in 2006-2010, which spawned a whole ecosystem of people who specialized in rewriting Rails projects back to Java/C#.
Yes, the stack gets you most of the way there. No, you won't be happy if you need to actually make changes to any part of that other than the top layer.
I've been using Xfce as a daily driver in one machine for about a decade now.
Great to know there's work on the wayland support front.
Also, writing it in Rust should help bring more contributors to the project.
If you use Xfce I urge you to donate to their Open Collective:
https://opencollective.com/xfce
https://opencollective.com/xfce-eu
I've been using xfce for about five years. I just setup my monthly donation last month and saw this good news today:)
Isn't the switch from X11 to Wayland the most painful switch that happened in the linux world ? Even going from python 2 to 3 was not as bad
The move from kernel 2.4.x to 2.6.x was pretty painful. The absolute slog from 2.6 to 3.0 and a development model that a least somewhat resembles the model used today was exhausting.
In case you weren't there, the "even" kernels (e.g. 2.0, 2.2, 2.4, and 2.6) were the stable series while the "odd" kernels (e.g. 2.1, 2.3, 2.5) were the development series, the development model was absolutely mental and development moved at a glacial pace compared to today's breakneck speed.
The pre-git days were less than ideal. The BitKepper years were... interesting, politically and philosophically speaking.
Also, KDE4 was a dark, dark period.
To me the most painful switch was Gnome 2 to Gnome 3. I still miss Gnome 2.
I left Gnome 3 for other WMs (eventually settled on cinnamon), but every once in a while I decided to give Gnome 3 a try, just to be disappointed again. I felt like those people in abusive romantic relationships that keep coming back and divorcing over and over again. "Oh, Gnome has really changed now, he won't beat me again this time!".
Kde 3 to 4 for me. I still miss you amarok 1.4.10.
But don't you love plasma applets in your media player that now requires a MySQL server instance and randomly deletes your collection metadata???
Just wait. In 8 years, Wayland will be as old as X11 was when Wayland was created.
Then we'll make Wayland 2.
X11 was basically used everywhere when it was released
X11 to Wayland was painless for me. I guess it depends on what you need from it.
What about systemd?
Systemd was easy for me. All things worked in transition and have the big advantage that don't need shell scripts for create services. Wayland..., is slow, buggy, applications close without reason...
I still want my /var/log/messages back. The new system just doesn't seem to work correctly.
How on earth would Wayland be slow? Like it's literally an IPC on top of the lowest level Linux kernel API (DRM), displaying buffers.
It was partially made for car infotainment systems that are knowingly weak hardware.
Fully-featured DEs like Gnome and KDE work a lot worse when doing everything in software rendering. If you're working on a device with subpar/nonexistent GPU driver support (i.e. Nvidia hardware for years on end), the experience is absolutely awful.
Nvidia's driver do something weird on Wayland when my laptop is connected to HDMI, probably something funky with the iGPU<->dGPU communication. Everything works, but at the whims of Nvidia an update reduces the maximum FPS I can achieve over HDMI to about 30-45fps. Jittery and painful, even on a monitor that supposedly supports VRR.
That's not really Wayland's fault of course, but in the same way Linux is broken because Photoshop doesn't work on it, Wayland is broken for many users because their desktop is weird on it.
I still have a choice to not use systemd. The systemd people didn't inhabit and then try to kill sysvinit or runit or any of the other competing technologies.
> I still have a choice to not use systemd.
Depending on your DE, you have a choice not to use Wayland. Like, yes, if you use GNOME then you don't get choices but that's their whole ethos, and unfortunately I've heard about KDE dropping X, but there are other options and as I type this comment in i3 I can assure you Xorg still works.
The X people are the Wayland people, it's not an external occupying force.
The Wayland people are not the people that created X, those are for the most part retired.
systemd was a problem for early adopters (e.g., Fedora). Distros like Debian joined the party later and, as a result, got things way more stable. I never had any systemd-related problem in Debian, while for Fedora (some years earlier) I had some bugs affecting my ability to work. They all seem to work very fine now. Things took a while to mature, but it just works now.
It was a similar story with Pulseaudio - it caused pain for early adopters but, by the time that Debian stable switched to it by default, almost all of the issues and corner cases had long since been worked out and it was almost completely trouble-free.
Mind you, the libc5 -> glibc2 upgrade was pretty horrible in Debian land, so they didn't always get it right in the early days...
I haven't had a single issue with Systemd and the transition was measured in years, not decades.
I think Python 2 to 3 was the by far worst.
Cries in KDE3 -> KDE4
Not really, /lib -> /usr/lib was worse for me
How? At worst the user can just add their own symlink or the developer may need to recompile the app.
This is nothing like wayland where the APIs to do what you want may not even exist, or may not exist in some random compositor a user is using.
I've used Smithay's Rust client toolkit for a few months now. For making apps it is still sometimes have unsafe wrappers disguised as safe. It has a lot of internals wrapped in Arc<>, but in my tests, the methods are not safe to call from different threads anyhow, you will get weird crashes if done so.
I will seek to dive-in to how Wayland API actually works, because I'd really like to know what not to do, when the wrappers used 'wrong' can crash.
FYI, you can currently use most wlroots-based compositors with XFCE. I myself am running Hyprland + XFCE on Gentoo. https://github.com/bergutman/dots
I like the retro theme.
Could you expand on why you describe Hyprland and XFCE4 as "a cursed combination"? Might provide some insight as to why the official XFCE project decided to create their own compositor.
I resisted Wayland for a longtime, but I'm sold now that I see how well it does on old hardware.
I have an old Thinkpad. Firefox on X is slow and scrolls poorly. On wayland, the scrolling is remarkably smooth for 10 y/o hardware, and the addition of touchpad gestures is very nice. Yes, there's more configuration overhead for each compositor, but I'm now accepting this trade.
Does Wayland work on non-Linux systems (e.g. *BSD)?
If an application is written for Wayland, is there a way to send its windows to (e.g.) my Mac, like I can with X11 to XQuartz?
Wayland works pretty well on FreeBSD and I know at least wlroots compositors work a bit on OpenBSD (though, I suspect anyone on OpenBSD would prefer to use their homegrown Xenocara). There are Wayland compositors for Mac, the youtuber Brodie Robertson did a good overview of them a few days ago
Microsoft's WSL2 GUI integration works based on Wayland (and XWayland): https://github.com/microsoft/wslg
Rather than going fully protocol-based (like Waypipe), they used Weston to render to RDP. Using RDP's "remote apps" functionality, practically any platform can render the windows. I think it's a pretty clever solution, one perhaps even better than plain X11 forwarding (which breaks all kinds of things like GPU acceleration).
I don't know if anyone has messed with this enough to get it to work like plain old RemoteApps for macOS/BSD/Windows/Linux, but the technology itself is clearly ready for it.
It depends on what you mean by send. Wayland doesn't have network transparency, there's a bit of a song and dance you have to do to get that working properly. I'm not sure the state of that or of Wayland compositors in general on Mac.
> It depends on what you mean by send.
Currently I can:
and get a window on macOS.For xeyes that works. It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it.
X's network transparency was made at a time when we drawn two lines as UI, and for that it works very well. But today even your Todo app has a bunch of icons that are just bitmaps to X, and we can transfer those via much better means (that should probably not be baked into a display protocol).
I think Wayland did the correct decision here. Just be a display protocol that knows about buffers and that's it.
User space can then just transport buffers in any way they seem fit.
Also, another interesting note, the original X network transparency's modern analogue might very well be the web, if you look at it squinted. And quite a few programs just simply expose a localhost port to avoid the "native GUI" issue wholesale.
> For xeyes that works. It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it.
I used run and use diskless SparcStation 5s with remote X on 10BASE2 network with the binaries running on Sun E3500s: it worked well enough for non-video web sites running Netscape 3.x. Also Matlab, Octave, Emacs, Vi(m), etc.
I've used it to run backup application GUIs when I was still on DSL (<25Mbps) displaying at home many years ago, and it worked well then. I now have >100Mbps fibre at home, so doubt that bandwidth (or even latency) is worse.
Well, we are using much higher resolutions with much higher frame rates and with more media-rich content.
You surely agree that not having a good compression here is less than ideal.
And it begs the question whether this is indeed the task of the display manager, or it's packing an unrelated functionality that could be better solved by another software.
And we haven't even gotten to sound - should a display manager now suddenly also handle sound?
Of all the things that seem useful to conflate, audio and video does make sense to me, as they so often need to be synchronized. Hell: many monitors also support audio, all televisions do, and the cables used to connect them carry both signals.
>It is absolutely an inferior and chatty protocol for any other application though, like try to watch a youtube video in chrome through it.
This is extremely misleading. Web browsers (and games) are the worst case for X11's network transparency. The overwhelming majority of applications belong in the same category as xeyes.
> the original X network transparency's modern analogue might very well be the web
It's Arcan, which solved this problem without sacrificing network transparency at the altar.
> The overwhelming majority of applications belong in the same category as xeyes.
Well, I'm not sure you are using that many xmotif apps. Most of the GUI programs are gtk/qt (and let's be honest, electron) - and they are mostly bitmaps to X's eyes (pun not intended). They don't use draw commands with such a small granularity that network transparency would benefit.
And Arcan is so many things at once I'm not convinced it is a good alternative to Wayland. It has good ideas, but they sort of require the whole package. Meanwhile Wayland is just a minimal API over the Linux kernel API for managing display buffers, that can be extended with additional protocols.
>And Arcan is so many things at once I'm not convinced it is a good alternative to Wayland. It has good ideas, but they sort of require the whole package.
That's a bit of a double edged sword, it's the exact reason why I don't think Wayland is a good alternative to X. Wayland's minimalist attitude towards responsibility is good for one thing, and that's implementing new compositors from scratch. The bare bones compositor will be a long way from usable, but it will be technically complete. The question is, does it matter to me that there are 30 different compositors? Each in various states with their own eclectic featureset with no guarantees given, a la USB-C? Not really. In effect, it did present me with the conundrum of choosing between a half-baked compositor (dwl) or a desktop experience I have literally zero interest in (Gnome/KDE) which left me with a sour taste in the mouth.
Moving beyond that, a real problem with Wayland's architectural minimalism is that a display server does more than simply abstract a single API. It provides a lot of rather complex features, from accessibility to input handling. Not every compositor is capable of handling that kind of complexity, especially if it's to work well. What we will find going forward are two possible futures:
1. The future resembles the present status quo of fragmentation, made worse by time. The compositor archipelago is here to stay, and deploying software in this environment has become excessively annoying. There are 10 different competing libraries for any given category of basic infrastructure, and each library in each category has their own ideas and idiosyncrasies that have to be worked around. Most of them are buggy and incomplete.
2. Smaller compositors effectively die off, and we are left with a single monolithic compositor, back to the modular Window Manager/Desktop Environment. This monster implements the defacto Extended Wayland protocol, where all of the different parts don't quite match each other very well because that's the cost gained from not having vertical integration of complicated components. There's no cohesive rhyme or reason to the design of anything. Thus, the exercise in minimalism has wrought an uglier and more complicated beast than Xorg itself.
I think it's clear Wayland is going to continue to sweep the Linux desktop given its massive corporate backing. But I'm not really compelled to run a bare Wayland compositor under any circumstances, because my Arcan server already works perfectly fine as a Wayland compositor. It works as any number of Wayland compositors running whatever extensions they implement. In effect, no matter which future we end up in, by using Arcan I'm in a much better position than someone running a normal compositor. This fact alone makes me favor Arcan, even before we get into its unique merits.
Watching a video will be the same as a on Wayland, just sending a video buffer, no?
The icons: you allocate memory on server for that and do not transfare the icon everytime. I think x11 works like that, not sure.
I know GUI lib that you can still compile with freetype disabled. Not everyone need the GUIs you talking about. Everyone is using cars, so lets ban bikes.. it does not need to be like that.
I find X11 RPC useful, simple UI is ok.. you can write programs that will run on any slow or not computer, remotely. Web is not that simple, it is different way of programming, it is not transparent. Web is useful for commerce, but not for controlling machines at factories or pilot cabins. IMO.
I don't really get your first 2 paragraphs. We are talking about connecting remotely to another computer, you can't do much at the other end of a network call with a server allocated buffer - at most you can cache stuff there. But that ain't helping with a video or any kind of fancier than a solid rectangle graphics.
And sure, simple UIs have their place - but they will also work just as well with a proper transport protocol, hell, they would compress even better. So just waypipe that simple UI as you see it fit.
You can cache icons on the server, you do not need to send them over a network, that is it. With video, I'm saying it is a case where wayland is not better, it is just the same.
So you say compression of said icons, etc, is better than caching them on the server? No.. You've mentioned web, but no one does that on the web.
I mean, no one does what you suggest on the web. You do not render a web page to an image and send that to a browser. To summarize. No one wants X11 transparency to run a web browser. But ok, if someone wants to do that.. X11 still can be more advantegeous over waypipe.
Because on the web we have a very very complex protocol(s) built up over decades to tell a client what to draw locally. That's html/css/js and its scope is far larger than of x draw commands (it's also an application model).
But again, GUI apps don't use X draw commands for the most part, so they are effectively a bitmap/video stream to X's eyes. And what's better to transport a video stream than a format designed for efficient transport of video streams.
Idk given there is no concept of cache. But also I'm looking at GTK menu, it is a simple menu, white bg. May be it can be rendered using draw calls. May be the complex UIs is just fashion and will be gone in a few years. The GUIlib could detect if program is running on a remote computer and reduce the effects, but they will need a concept of network for that.
Also the font rendering. The client could then just send text to the x11 server if it was not vector fonts.
x11 xrdb. With it you can configure say font size on your computer, not on the computer where program is running. Say comp1: 10pt, comp2: 20pt.
It's not "complex UI", it's what programs are generally used. It's gtk, qt, and a bunch of other cross-platform platforms all doing their own thing. They simply render (in a hardware-accelerated way) to a local buffer and that's the only commonality.
Could random draw calls be transported over the network? Sure, and for certain kinds of GUIs it is definitely more efficient than rendering and sending some compressed artifact.
Will XMotif suddenly change the world and apps will be written in it? Absolutely not. It's not even a thing on the minuscule Linux desktop, let alone elsewhere. We are running electron apps and whatnot.
And as I said, this "send draw commands" exists: SVGs are possibly the closest thing, but the web as a whole is literally this with a couple of more features.
Today you would do:
`$ waypipe ssh somehost foot`
You need waypipe installed on both machines. For the Mac, I guess you'll need something like cocoa-way (https://github.com/J-x-Z/cocoa-way). Some local Wayland compositor, anyway.
Yes, but still kind of WIP.
https://docs.freebsd.org/en/books/handbook/wayland/
It is in freebsd's official handbook, and the openbsd folks have been playing around with it since 2023 at least https://xenocara.org/Wayland_on_OpenBSD.html
I'm not sure how much farther along they are than that post though.
If wayland support was there already I would be using xfce. I truly admire it, it's great to see this happening and I hope the project continues in great speed. With DE's requiring hard system-d support, I would rather have something like xfce
I see the words "feature parity". I hope those words are taken seriously. I feel like most Wayland advocates would do well to take those words seriously.
(xfwl4 author here.)
Absolutely seriously. To me, a big part of what makes Xfce is xfwm4's behavior. Even though most of the other Xfce components will run decently well on wlroots-based compositors, I don't really have an interest in using them, as that's not "Xfce" to me.
But it's not going to be perfect, though, as some things that we take for granted on x11 still just do not have Wayland protocols to enable them. This will take a long time. Alex's blog post says a developer preview around the middle of this year, and I expect I can deliver on that, and maybe (maybe!) even a stable release by next year (maybe!), but full feature parity will take years.
As someone that is sensitive to displays, one of the best features of XFCE, unlike others desktops, is that it doesn't cause eye strain, probably because it doesn't play tricks - a pixel at a certain color is stable, and not dithered(if you choose) and higher level primitives are also stable and don't play time/frequency based games.
I hope XFCE preserves this, it is a killer feature in today's world.
I started off using twm / olwm / vtwm in 1991. Then FVWM and Afterstep / WindowMaker. I've been using XFCE since around 2007. As long as it functions similarly I'll be happy.
Can relate, however I had Unity in between, and some Enlightment as well.
GNOME was cool during the sawfish days.
As an Xfce4 user my priorities for a WM are in diminishing importance:
- speed
- memory consumption
- simplicity to use
- customisability
- if it's X11 or Wayland
If everything above the last remains the same in the Wayland version, I stay, else there is LXDM.
I certainly hope they support themes. I have been using a Mac OS 7 Platinum theme on all my XFCE desktops for years and I want to keep doing so :)
The more wayland compositors the better. It will force developers to actually abide by the specification instead of creating single implementation hacks like in the webbrowser ecosystem.
So long as I can windowshade things and it doesn't end up making things a blurry mess, cool.
Now the last 3 times I tried Wayland everything ended up a blurry mess and some windows just ended up the wrong size, so.
I suppose I'll just keep holding out hope.
I guess at this point it is safe to say that whenever you see "rewrite in Rust", it simply means there is no one to maintain the software anymore. They are saying this pretty openly that they weren't able to patch xfwm4.
I only fear that this is manifestation of a wider phenomenon when new software developers are unable to maintain software created by old software developers. If that is so, they will try to simplify the software to what they can actually maintain and rewrite it into a form in which they can maintain it.
If i assume this is true, then all of this is annoying, but actually makes sense: Wayland is simpler than X11, so people will tend to maintain Wayland-related software rather than X11-related. Rust won't let unskilled coders to make some mistakes, so from their point of view it is going to be simpler to rewrite something in Rust.
Although, goodbye network-transparency, goodbye performance, goodbye stability. Oh well, but it's that time of the year.
This bullet point from the reason to chose one library over another is a prime example of what I love about XFCE:
Not only are they considering it, but they're expressly calling it out. I'm convinced that the publication of the Agile Manifesto was an exercise in Cunningham's Law, and to that end the XFCE team has produced something great by doing the opposite.Very interesting that they opted for a rewrite in Rust instead of adjusting the existing codebase.
I wonder how long it'll take them writing a compositor from scratch.
Not the whole codebase, only the window manager (compositor is the Wayland equivalent). Other components are written in C and will remain so for the foreseeable future. Those components gained Wayland support in the last couple of years, you can try Xfce in a labwc session, there are of course several things to improve, but the compositor is the last big piece missing.
Thanks for the context!
(xfwl4 author here.)
I spent a month or so in 2024 attempting to refactor xfwm4 so it could serve dual purpose as both an X11 window manager and Wayland compositor, and ended up abandoning the idea. It was just getting ugly and hard to read and understand, and I wasn't confident that I could continue to make changes without introducing bugs (crashers, even). We want X11 users to be unaffected by this, and introducing bugs in xfwm4 wouldn't achieve that goal.
Note that we don't have to rewrite all of Xfce: xfce4-session, xfce4-panel, xfdesktop, etc. will all run on Wayland just fine (there are some rough edges that need to be ironed out for full Wayland support, but they're already fairly usable on wlroots-based compositors). This is just (heh, "just") building a compositor and porting xfwm4's WM behavior and UI elements over to it. Not a small task, to be sure, but much smaller than "rewriting all of Xfce".
Great to see xfce continue on into the next age.
I've been using popos for a while, but xfce will always have a place in my heart.
If it had tiling support I'd probably use it still. Being so lightweight is a massive boon.
So will it be renamed to Wfce in the end?
It was originally named XFce after the XForms library. As of Xfce 3, it uses GTK though, so it could be called GTKce, but renaming the project every time you change widget toolkits is probably not a good idea.
And what was XForms named after?...
It seems I will require a microsoft rust compiler and won't be able to use a small alternative plain and simple C compiler for xfce.
The beginning of the end, or are there plain and simple alternative microsoft rust compilers? Is microsoft rust syntax at least as simple than C?
Or the right way will be to use an alternative wayland compositor with the rest of xfce?
I suspect many of us still using X, are xfce users waiting for an alternative; I've heard very mixed things about current Fedora xfce wayland setups from different people.
I’ll switch to Wayland as soon as I can use xscreensaver with it, preferably as the screen locker.
I love XFCE, with the move to wayland I hope they start thinking about abandoning GTK though
Why do you hope they abandon GTK?
What would you have them replace it with?
If they do not mind introducing C++ (they're introducing Rust so i guess multilanguage development isn't out of the question) then FLTK could be an option, though it'd probably need to improve its theming support.
They both have kinda similar roots in that XFCE originally used XForms which was an open source replacement of the SGI Forms library while FLTK also started as a somewhat compatible/inspired opensource replacement of SGI Forms in C++.
Enlightenment. No, really.
If they ever move away from GTK (due to the GNOME shenanigans GNOME-izing GTK) I wish Englightenment and Xfce were together a single thing. But that's if I could ask the Tux genie three wishes.
GTK4 is still pretty usable without libadwaita and all its Gnome-isms.
But frankly I think forking and maintaining GTK3 is preferable to moving to EFL or Qt. GIMP is still on GTK3. MATE is still on GTK3. Inkscape is still on GTK3 (but GTK4 work is in progress). Evolution is still on GTK3.
I think GTK3 will be around for a long time.
+1...
Hell I wish EFL was more used in general. I was thinking QT (mainly because I forgot about EFL) but that's much better
If you are wishing they used QT instead the fact that they chose Rust only makes that less likely.
Am I the only one who's not buying into the Wayland hype? I just want X11 support not to fall into disrepair, as I see nothing wrong with it.
I don’t see much Wayland hype. It’s boring plumbing for most people, isn’t it? Most of us are just going along with whatever the volunteer plumbing community decided to put together.
(xfwl4 author here.)
I'm also not a big fan of Wayland, to be honest. But that's the way the winds are blowing. X11 has its problems, but even if they are fixable, no one seems to want to work on Xorg anymore. I'm certainly not prepared to maintain it and push it forward. Are you?
Depending on Xorg today is more or less ok, but I do expect distros will stop shipping it eventually.
> I just want X11 support not to fall into disrepair
Are you also willing to maintain it?
Are you willing to write accessibility support for the new xfce only wayland compositor? How will you get every other wayland compositor to support your non-'wayland core' accessibility extension?
People like to frame things like the waylands are some sort of default and nothing is being lost and no one is being excluded.
Everyone has settled on an accessibility standard (Matt Campbell's). So it's not "your" accessibility protocol, it's already "the" accessibility protocol. This is working as intended IMO: allow things to compete and future in the wild and then pick the fittest.
Right. The push based accessibility that is only supported by GNOME's compositor, mutter, and GNOME's DE's userland as of this last 6 months. I would very happy to hear about even this extension supported under other wayland compositors and software. Do you know of any?
Since you seem informed perhaps you can clear something up for me, when Cambpell says "push full accessibility tree to trusted clients" does that mean you get the entire desktop tree, or only for that application?
Because if you don't get the entire window tree, because you only get the single windows information when that application provides it, it is highly incompatible with existing solutions. They say it is compatible because application developers can create a new virtualized thing themselves. But that's not compatible. And beyond that, it is a "solution" that prevents me from controlling my own computer. I understand GNOME is targeting everyone not just power users. But as a power user I am someone. I am a human being.
And Campbell's assertions that push is more performant than pull and full tree are being backed by arguments informed from problems that don't even apply generally. GTK 4 broke this, not GTK 3. It's not a push versus pull thing. It's wayland architecture focused Gtk4 causing the problem when things are fine in X11 focused GTK 3. ref: https://gitlab.gnome.org/GNOME/gtk/-/issues/6269 a11y: No API for supporting a11y Selection interface , https://gitlab.gnome.org/GNOME/gtk/-/issues/6204 a11y AT-SPI: get_child_count implementation iterating over all children causes freeze for objects with many a11y children
Honestly at this point, I would be willing to pay $10-20 a month just for someone to maintain Xorg and xfree86. I really doubt I am the only one.
If the XLibre project appears to be making enough fairly-consistent progress for you to be comfortable tossing around some cash, then do gather up some likeminded folks to hire a dev to follow the guidance here [0] and help out!
Do note that I've never tried to croudfund a programmer, but that's something that I have to believe is possible to do.
[0] <https://github.com/X11Libre/xserver?tab=readme-ov-file#i-wan...>
Given that all their patches were reverted in upstream X11 due to quality issues [0], I wouldn't put too much trust into that project.
[0] https://www.phoronix.com/news/X.Org-Server-Lots-Of-Reverts
Given that FDO [0] has been screaming about how Xorg is dead and Wayland is (despite plenty of evidence to the contrary) ready for everyone and every use case for the past like ten+ years, I remain somewhat wary about their opinions regarding Xorg development.
Maybe XLibre will be a damn trainwreck, or maybe it'll be to xorg what xorg was to XFree86. I intend to find out through the testimony of users of XLibre.
[0] ...or maybe just a very vocal subset of the folks at FDO...
Some cognitive dissonance going on here. The vast majority of current Linux Desktop users are on Wayland, and X11 is phased out across the board. Calling it hype is absurd.
> Some cognitive dissonance going on here.
The cognitive dissonance I perceive goes like "No one is being paid to work on X11, therefore I should volunteer to work on Wayland."
So I guess Windows is actually the future then by your argument because that's used by even more users.
It's wild this is what you took from that, but no. My issue was with the word 'Hype'. Would you call windows Hype because it's bigger?
Sure, but do you have any facts to backup that assertion?
Ubuntu and Fedora dropping X11:
https://www.theregister.com/2025/06/12/ubuntu_2510_to_drop_x...
https://itsfoss.com/news/fedora-43-wayland-only/
Kde Plasma 6.8 dropping X11:
https://itsfoss.com/news/kde-plasma-to-drop-x11-support/
Suse dropping X11:
https://documentation.suse.com/releasenotes/sles/html/releas...
Yes, you are the only one in the entire world who hasn't fallen for it. Well done.
Rust is not GNU
Neither is xfce
daily drive xfce4, best DE ever, simple and complete.
Wow, this is annoying. I really like Xfce, but there are plenty of minor things which would need improvements. Instead of fixing all these minor things, they waste a lot of their donations on a rewrite for Wayland / Rust - apparently for exactly the same reason as all the other Wayland stuff and Rust reworks. Developers like to write new code more than actually maintaining / improving fixing existing things and finds some excuses to do this.
(xfwl4 author here.)
That's a fair criticism sometimes, but, frankly, if you want things the way you want them, learn to code and dig in. Otherwise it's not really fair of you to complain about stuff that people have built for you for free, in their spare time.
In this particular case, it's not fully a "new and shiny, must play!" situation. I personally am not even a big fan of Wayland, and I'm generally highly critical of it. But Xorg is more or less unmaintained, and frankly, if we don't have a Wayland compositor, we'll become obsolete eventually. That's just the way the wind is blowing.
I am not complaining about what people do in their spare time. If the blog post said "someone does this because he likes to spend his own time on it", I would not complain. I am complaining about a) the justifications given which I think are all nonsense IMHO and rationalizations for something which some likes to do, and b) the use of donations which should be better used to improve the software instead of creating more rewrites.
I also do not agree with the Wayland is inevitable sentiment. There are non-systemd distros, there will also be non-Wayland distros. The idea is that only those things survive which are pushed into the ecosystem by the cooperate bullies is wrong, otherwise Linux would not exist.
The Linux desktop was essentially fine already two decades ago and instead of the needed refinements, bug fixing, and polishments, we get random changes in technology after the other, so nothing ever really improves but we incrementally lose applications which do not keep up, break workflows, sometimes even regress in technology (network transparency), and discourage people from investing into applications because the base is not stable. My hope was that Xfce4 is different, but apparently this was unfounded.
> I am not complaining about what people do in their spare time.
Re-read your original post. You are absolutely complaining about what we do in our spare time.
> If the blog post said "someone does this because he likes to spend his own time on it", I would not complain.
I mean, that's part of it. I wouldn't do it if I wasn't interested in doing it. I have my own long list of Wayland criticisms, but I think it's interesting.
> I also do not agree with the Wayland is inevitable sentiment.
I think that's where we'll be at an impasse.
There are non-systemd distros because there are viable alternatives. Xorg (the server implementation, I mean, not X11 the protocol/system) is dead. I don't like saying that. I've invested a lot of time into X11 and understanding how it works, and how Xorg works. But no one wants to maintain it. There is the XLibre fork, and I wish them well, and do want them to succeed, but sustaining a fork is hard, and only time will tell if that works out.
But I don't think X11 has a future, unfortunately. And that really does make me sad. You're free to disagree with that, but... well, so what.
> The Linux desktop was essentially fine already two decades ago and instead of the needed refinements
That's a view through rose-tinted glasses if I ever saw one.
> we get random changes in technology after the other
Jamie Zawinski called this the "Cascade of Attention-Deficit Teenagers", and he's right. I do think some of these changes are an earnest and honest attempt to make things better, but yes, people just want to work on what interests them, and what makes them feel good and accomplished.
When we work for a corporation we don't really get to do that, but when it's unpaid, spare-time volunteer work, we have the freedom to do whatever makes us happy, even if it makes other people mad or disappointed or annoyed, or isn't the most "productive" use of our time (whatever that means).
::shrug::
> > I am not complaining about what people do in their spare time.
> Re-read your original post. You are absolutely complaining about what we do in our spare time.
Then I am not sure how I have to understand this sentence: "After careful consideration, we’ve decided on a meaningful way to use the generous donations from our community: funding longtime Xfce core developer Brian Tarricone to create xfwl4, a brand-new Wayland compositor for Xfce."
> That's just the way the wind is blowing.
I trust you understand that some readers may not find (to paraphrase) "I don't like it either but it is what it is." a compelling reason to fix something that is not broken.
I also do not use free software to then have to use something I do not like because the "this is the way the wind is blowing" (just becomes some parts of the industry wants something re-engineered in their interests)
This is great news! If anyone from the Team reds these comments, Thank you people so much for XFCE4!
My response to the Wayland/X11 nonsense bickering has always been that I'll switch to Wayland when xfce does. I usually eyeroll when I see "in Rust" but the developers writeup in the linked article and their comments here are very reassuring and I look forward to their success!
Until I can still compile xfce with an small and simple C compiler or even a simpler SDK.
what no fuckin xbindkeys?
i'm trying to build a Linux desktop and the first thing I got stuck at is X11 versus Wayland for greetd. Next thing Il got stuck at his XFCE4 doesn't exist for Wayland. What the shit. if we want to tell me wayland is the future, fine. sure. great. Tt's been 11 years!
If you're just trying to run Linux you're better off either using one of the many read-made distributions or going with X11 since that works just about everywhere and has done so for decades.
THanks for the encouragement. I'm trying to get Debian Linux to run on a Chromebook and it's been no shortage of frustration, especially because ChromeOS is Linux and ostensibly open source, but just getting the kernel booted was an ordeal and a half. I'm currently stuck at suspend not working because something something EC, for which ChromeOS has a userland program to coax it into working right.
ChromeOS and devices it was made for are not the best start in Linux-land since it is Linux just like Android is, i.e. it is based on a Linux kernel but for the rest quite different from 'standard' (GNU-) Linux distributions like Debian + derivatives, Arch, Fedora etc. Maybe you can get that userland tool from ChromeOS to work in Debian, maybe not.
Even though you're trying to get Debian installed on the thing I'd also refer to the Arch wiki for information on how to get things working right:
https://wiki.archlinux.org/title/Chrome_OS_devices
Arch being what it is it has attracted a host of knowledgeable users who have collected their information about how to get things working on different systems in an organised and usually comprehensive way on that wiki. Much if not most of what is written there is also applicable to getting non-Arch distributions running on those systems.
in the time it took me to complain about xfce4, three other complaints popped up! so I guess I'm not alone