It depends on whether their reasons for "absolutely having to have X11" hinge on actual compatibility with e.g. old binaries or wanting full remoting without streaming pixels.
This project would satisfy people who really actually want Wayland, but were upset by transitional pains or interactions they had around it and want to stick with X11 just-cause while getting some similar benefits. This arguably does describe some people but not sure it's a whole lot in the long run.
But who knows, maybe this could also make an easier to maintain XWayland some day, or a nice basis for implementing more esoteric X11 bits down the road vs. the older Xorg codebase.
From my perspective X just got to the point where it just works for me few years ago and Wayland is just introducing more issues than it solves (to be clear it solves no current issue for me, only one that I think might be better for me is handling different refresh rate displays and maybe fractional scaling... and that could probably be done within X11)
Like, why simple "copy the screen" got suddenly so complicated? Why every WM suddenly needs a bunch of features that before were just handled by display server, where they belong ? Why some(most) WMs handle title bars but GNOME doesn't ? Why someone decided title bar management is optional to window manager ?
X11 might need to go but Wayland have learned no lessons from it. It's just knee-jerk "if X11 done it this way, let's do it differently"
Whatever the issues with X11, it was properly designed. Wayland is the kind of software that adds features with nobody looking at the consequences. Who knows what they will break next version.
From all the criticisms leveled at Wayland, this is definitely the strangest I've ever heard.
I really cannot thing of any existing functionality ever broken by a new release of wayland-protocols, neither by a plain bug nor by a bad interaction. No doubt someone else will be able to recall an example, but it's really not a common thing.
This is partially because the governance model and community mindset is the opposite of what you describe. Inclusion of new protocols in the stable release requires existing, proven implementations and consensus across multiple implementors, making it a high bar. New proposals run a gauntlet where pretty much everyone is looking at the consequences in detail.
In fact a more common criticism of Wayland is that the focus on high quality and the consensus requirement are too strict and have slowed down filling in feature gaps users need filled faster. This argument I think can be successfully defended against - mainly, that it helps avoid the mess X11 became over time -, but at least has some basic merit in reality and is an avatar for genuine user pain.
As for X11, as someone who had to implement a lot of X11 specs over the years, I can tell you that their provenance between X11 itself as well as ICCCM and EMWH had plenty of super dumb ideas and cruft and inconsistencies from lack of foresight and eventually datedness. You don't want to see the towering stack of hacks and heuristics we used to have to ship to make X11 behave somewhat consistently and sane :)
In short, with all due respect, but I think you really don't know what you're talking about. We really should resist this type of narrative reality distortion field on an engineering forum.
> making it a high bar
That high bar is GNOME having an uppity whenever a Wayland protocol is suggested they don't like, that even if is accepted, if Mutter doesn't implement it then its dead in the water given its the de facto default compositor on unfortunately what people consider "Linux", aka Ubuntu.
e.g. DRM leases that only got changed because Valve has the bigger underwear. Expecting games to implement DBUS (incl. when running under Wine) to access VR headsets just for GNOME is nuts.
The government model needs a change that stakeholders who ship devices to the end users that rely on them have more of a say, whether that's Google, Valve etc. Valve is now backing and pushing KDE into average joe end users is a telling.
Wayland design choices are heavily influenced by automotive and TV where it has been industry standard way before it became mostly usable as a desktop. And that has lead to design compromises that look odd on desktop.
But hey, you can probably run automotive UIs with your desktop compositor.
And Gnome devs are just being silly at this point.
This car runs KDE Plasma's KWin, along with many other Mercedes-Benz models currently launching:
https://youtu.be/wo5As8et1G8
https://youtu.be/pqJ-9SUPFwY
Notably this deployment doesn't use any of the old-gen automotive Wayland cruft like ivi-shell though. It's pretty much the desktop stack now.
I miss the 1990s Benz 190E I used to drive: the only electronics in sight were the tape deck/radio. Even the door locks ran off a vacuum system.
I will never buy a car that runs an X-windows server.
It's a Wayland compositor, not an X-windows server!
and even if it wasn't Wayland, it would be an X Window server.
> Why someone decided title bar management is optional to window manager?
Are you implying title bars should be mandatory in all WMs? I'm using DWM on X and I love that I have no title bars. If a program tries to force one on me I disable it or use something else if that's not possible.
It should be mandatory wherein the title bar is expected/desired by the user and not inherently the responsibility of each individual app by default. The wm should have the capability of drawing a titlebar for each app and do so by default unless the app opts to draw its own OR the user configures the system to not do so.
Yes, and that's how it's handled by the desktop environments I've used. Many programs have the option to use the system, program or no title bar. But should it be mandatory for every DE/WM or can the user choose one that satisfies whatever preferences the user has?
This way people like me still have the option to use window managers that don't have title bars. Title bars are useless for power users that know what program they're in and don't need them. To me they're in the way.
I don't "actually want Wayland" because I want the simplicity of X and the ability to run my own wm, but I have no need for legacy X11 requests, for some values of "legacy". Whether this will become viable for me remains to be seen, but I need very little from my X11 server.
Fair! Though I'm actually not sure I understand what you mean with simplicity. X11 is so vastly more complicated than Wayland.
For the server/compositor.
Not for the client, or if you want to write a wm and is forced to write a compositor.
And actually I'm not even even convinced about the server if talking about a minimal server like this that insists on DRI/GBM, and ditches all the old rendering cruft.
Well, you are not really forced to write a compositor these days as there are libraries that do all the heavy lifting for you.
Check out Louvre for example. Or Smithay if you like Rust. And if you want a bit more depth, there is wlroots of course (or the hyprland version). It is not really any harder than writing an X11 WM.
Yeah, no I have my own wm in Ruby that is fewer lines of code than a typical Wayland Hello World, and that does what I want. I have no reason to want to throw that away for something that doesn't offer me any features I care about, and removes features I do. Such as the ability to just restart my wm if I make a change to it without affecting my current session at all.
Unless you can show me a solution that lets me replace my tiling and floating wm in ca 1500 lines of Ruby, what you're offering me is inferior to what I have with X
It's called an extension. What's the point of mandating a (bad) IPC API?
Th point is that with X I could start with less than 100 lines and switch to using my wm, and stepwise refine it while using it.
You might consider that a bad API, but to me any solution without it is massively inferior and not something I will ever consider.
wlroots and smithay (I'm not familiar with louvre) do a lot of the difficult work for you, that most compositors will do without much variation but there's still a lot that compositor writers still have to do. It's still a significantly larger task than, for example, writing an X11 WM.
(Well, writing an X11 WM that also includes a built-in compositor is a bit more than just the WM, but I'd say still less than writing a Wayland compositor using wlroots or smithay. For example, xfwm4's compositor is around 5300 lines of C, which is... not nothing, but not crazy either.)
https://github.com/CuarzoSoftware/Louvre
So build on top of wlroots or something. DWL for example is super small...
Current status:
> 2025-08-16: dwl IS CURRENTLY UN-MAINTAINED. AT THE PRESENT TIME, I (@fauxmight) DO NOT HAVE THE TIME OR CAPACITY TO KEEP UP WITH wlroots CHANGES.
https://codeberg.org/dwl/dwl
I said build on top of wlroots, not DWL. And I only brought it up as an example of a small Wayland compositor/window manager because the poster I was replying to wants to build their own anyway. DWL is more interesting as a learning exercise than something to use.
The -IMO- important part of that quote is "NOT HAVE THE TIME OR CAPACITY TO KEEP UP WITH wlroots CHANGES".
X11 is backwards compatible, you do not have to "keep up" with its changes.
wlroots seemingly isn't. This is a significant issue when it comes to relying on most 3rd party libraries.
> X11 is backwards compatible, you do not have to "keep up" with its changes.
That's certainly one way to say "no longer developed".
When things work further development is not always a positive.
That was also true back when it was actively developed though. X apps compiled a long time ago still run fine today.
Xorg is still being under development, there is another fork in development too (XLibre) and you're in the comment thread for a project about a brand new X server written from scratch.
Usually things which are "no longer developed" do not have (at least) three implementations in development.
Mature projects often don't change much or quickly even when actively maintained or improved.
(i worked a _little bit_ on dwl) each wlroots upgrade is a pretty small diff on the dwl source. the annoying part is, as dwl is configured with patches, every patch author has to update their patch to the new 0.x, as dwl is quite minimal, and thus has no stable api. that being said, obviously, dwm doesn't have this problem :)
also, for dwl, the issue is that the initial author (not the guy that wrote that notice) is sorta mia, and he has control of the repo on codeberg, so we'd probably need to fork to be safe, and he may not want to take on project lead. (he checks every patch for merge conflicts with one another and upgrade breakages, god bless him lol)
> I said build on top of wlroots, not DWL.
Turns out, the wlroots API is so volatile atm that even the developer of the super small compositor DWL has to throw in the towel for now.
> DWL is more interesting as a learning exercise than something to use.
The same is said about DWM, its xorg counterpart, but I, for one, am a happy user of DWM.
Nearly every Wayland compositor is built on wlroots. Somehow they manage. But yeah, of course it's going to change more than X11, which is older than I am and more or less abandoned...
It's actively maintained by projects like RHEL which still have versions which are supported which in turn support X11.
Others are looking to run X11 wm under wayland with wayback, xlibre wants to keep it moving forward, and phoenix wants to replace it with a modern version.
This isn't what abandoned means.
No, I do not. I pointed out that with Wayland I'd be forced to. And DWL is an illustration of how much work that is relative to an X11 wm.
Why would I?
And DWL is not super small. It's hundreds of times larger than a minimal X wm, and couple of times as big as the wm I used.
And it's C. And it'd mean I would lose my session if I want to make changes and restart it.
What you're suggesting would be to put significant effort into replacing something that works with something that in terms of features I care about is strictly inferior.
Afaik Xorg is 'only' like ~500k lines of code, which is not huge by the standards of large porjects. In fact, one of the major counter arguments against Wayland, is that the compositor + a few core libs, like wlroots necessary to provide a similar set of functionalities, is already larger that the equivalent X11 code (which has a ton of unused cruft).
> like wlroots necessary to provide a similar set of functionalities, is already larger that the equivalent X11 code
I absolutely don't buy this.
You shouldn't, cause it's wrong.
libwayland is 40k lines of code. wlroots is 60k loc.
And just to check, sway is about 49k loc.
What's the simple way for a bash script to get the title of the currently focused window? In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please.
It shouldn't be hard, all I want to do is fuzzy match window titles to named audio streams in pipewire, but "Oohh noo that's a security flaw!" say the patronizing Wayland developers who care more about making their own lives as developers simple than supporting basic desktop functionality.
> all I want to do is fuzzy match window titles to named audio streams in pipewire,
> basic desktop functionality
I feel your pain, but find your idea of "basic" functionality amusing.
That said, `pw-dump` / `pactl` will give you client names, which often match the window titles.
I know how to get the audio stream names, the problem is the window titles. With X it's easy, just call xdotool. I'm sure it's probably easy enough on Windows and MacOS too. Wayland is the weird one for making focused window titles privileged information.
Anyway, I do think I've created what should be considered basic desktop functionality here, a simple hotkey that mutes or otherwise changes the volume only of the focused window. Every desktop should have it.
This is just one of the tools I've made for myself with X which I do not want to do without and this makes Wayland a non-option for me. If I can't use X and can't replicate things like this with Wayland, then maybe I should switch to MacOS at that point because the dream of controlling my own computer seems like it's dying anyway.
Wayland is approximately correct in this case and Windows and Mac are behind the security curve for bincompat reasons; window titles certainly leak PII. There should be a way to do it, but it is sensitive information.
You are aware that by default programs you run have access to your entire home directory, right? Applying any restrictions to them in the windowing protocol is security theater.
Sure, but again there's no interest in actually making a standard way to do it. I can understand it being something that arbitrary applications probably shouldn't be able to access, but that somehow turns into no way to do it, or complete fragmentation where every DE does it with arbitrary differences (or, more realistically, some DEs support it and others don't).
Is there any documented attack on macOS or Windows that utilized window title information?
Never in history. If you have software running on your system attacking you then you have so many more issues than the adversary knowing your window titles.
Okay; is there a way to do it? Can I, the user, decide that I do actually want a program to see titles? Or is it still impossible because 17 years isn't enough to implement utterly trivial APIs that people want?
> In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please.
I don't know what you expect people to prove other than that X and Wayland both have the same problem but since X is so complicated there is only one implementation to begin with, which makes it look like X has solved the problem even though it suffers from exactly the same problem.
There are in fact multiple implementations of X and xdotool works with all of them. Typical Wayland advocate, doesn't know what the fuck he's talking about while telling people to just ignore the problems they have with Wayland, probaby because you don't even understand the problem in the first place. Why did you even respond to me? To insult me? To waste my time?
> There are in fact multiple implementations of X and xdotool works with all of them
Are there non-Xorg X servers for Linux that are usable? Asking because I'd like to try them if they exist
I remember Wayland scared me off of Linux when I tried to switch to Ubuntu a few years ago. I couldn’t watch a movie without jiggling my mouse every few minutes. At the time I feel like it was like “yeah that feature doesn’t exist yet” or something. So I switched back to Windows. It looks like there’s workarounds now but I’ve mostly switch to my fantastic M1 MacBook Air at this point.
Wayland still doesn't support screensavers last I checked, which is wild to me. Truly bizarre that such longstanding feature is just absent.
It's a matter of designing and proprosing a protocol for it. X11's screensaver support was also a protocol extension.
There probably hasn't been much interest in it because screens can easily be powered off remotely, which was not the case in 1992.
Yeah, most of those real gaps have been solved at this point. I'd encourage you to give it a shot now with Avahi
Look into river. It has the window management and keybindings able to be offered by other tools (I have an idea to implement one using XMonad's layouts).
It also vastly improved battery on my Dell Pro laptop. 58% battery used in 7h45m (light compilation day, but no suspend).
That sounds cool, but TBQH the last thing I want to do is make myself dependent on some obscure piece of tech I've only heard of once before (just now.) My plan is to keep running X as long as I can manage to make it run. If river finds traction and is well known to me in 10 years then I'll consider it then.
This is one of my big problems with Wayland; the fragmentation of Wayland imposes an unacceptable cost to picking the wrong DE, whereas with X all my tools for X still work regardless of my DE.
I don't have any interest in river. I have my own wm that does exactly what I want, so why would I switch?
Wayland doesn't solve any problems I have, and would create new ones, such as having to adapt to new tools or write my own compositor.
Battery life just isn't a relevant consideration for me.
Wayland made writing WMs needlessly hard, and the benefits of Wayland were frankly not real - most of the reasons given in 2011 were patched in to X11 later. All the Wayland rewrite got us was a situation where Wayland is both bleeding-edge and obsolete simultaneously. Say what you like about X11, but by the time people unironically pushed for mass Wayland adoption, X11 was stable and boringly so.
The future of WMs is, IMO, Arcan - https://arcan-fe.com/ - but that's an ambitious project and I don't blame the main developer for deliberately going out of his way to avoid advertising it before it's ready. In the meanwhile, Wayland and X11 both more-or-less work with the occasional major pain in the ass.
I think the problem is that people wanting to build that and being in position to (being paid for by their employer), are fed up with X11.
It learned no lessons from X11. It made most things harder to write and pushed more things that really every WM needs and doesn't care much to implement differently to WMs making them harder.
For example, stuff like "WM need to manage raw inputs, so they can have more power over them" is cute on paper but in reality most of them don't want to because there is no benefit to reinventing that part. Sure, that part in X11 could be better, maybe it should have better interface for WMs to configure common options in common way without getting into input-driver-specific options, but that just required rework of the idea, not throwing it into the bin and replacing with near entirely worse framework that wastes everyone time.
Tech is full of examples of 'successor' technologies, that were aiming to provide a clean rewrite without legacy, which then got bogged down with supporting a bunch of corner cases and accumulated their own share of cruft and could be no longer be considered a cleaner alternative. All the while the majority of the userbase being stuck on the old platform because the new one is buggy and doesn't offer anything tangibly better.
Vulkan, various node replacements come to mind.
Wayland at this point has existed almost as long as X11, longer if you only count the Linux years, yet its still not quite there.
Wayland and its various implementations like KDE plasma are 90% ready. Now they just need the other 90% to move from alpha to product. I expect it'll take another decade or two.
The way things are going there might be a third 90% needed.
https://news.ycombinator.com/item?id=46382947
Read this including my response.
A lot of X features are actually Xorg features and they only work because there is a single implementation that everyone tried to integrate with.
Turns out the moment there are two implementations, which is hard on X and easy on Wayland, you can no longer rely on targeting a single implementation for direct integration anymore.
This means a lot of non-X but Xorg features need a protocol extension in Wayland, because things are being standardized that previously were exclusive to Xorg.
Are you saying that you can't get the title of the active window in X11 without using some features specific to the X.Org implementation?
It looks like the core X11 protocol spec [1] defines all that's needed, specifically the GetInputFocus, QueryTree and GetProperty messages. You might also want some things from the EWMH spec [2] (e.g. _NET_WM_NAME for UTF-8 or _NET_WM_WINDOW_TYPE to identify top-level application windows) but none of this seems like an implementation-specific X.Org feature.
[1] https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html
[2] https://specifications.freedesktop.org/wm/latest/
> I think the problem is that people wanting to build that and being in position to (being paid for by their employer), are fed up with X11.
I think one of the intrinsic problems with relying on developers being paid by their employers is they can easily become personally disinvested from the thing they're maintaining; they get paid well, the day-to-day grind gets stale, they get interests and hobbies other than computing but keep working on the thing because it's their job. Eventually they find that just buying a Mac is an easier lifestyle at home, and gradually maintaining X transforms from something they do out of passion for the project into something which is just a job. So they look for ways to make their job easier, hit on the classic "instead of maintaining old thing it'll be more fun to make our own", and because they are now untethered from the needs of real users they only need to make sure the new thing supports the bare minimum to keep their employer happy. They no longer care how real users feel, any use case that isn't required in the checklists approved by management get deliberately abandoned. So we end up with Wayland lacking common sense desktop features in demand by users for years because it's simply not convienent for the developers who are now dispassionate 9-5ers.
I prefer to take my chances with enthusiasts keeping X working on shoestring budgets. Maybe a few more years of development of coding models will make ongoing maintenance easier going forward and I'll never have to switch. I'm willing to make that bet. If it turns out that in 5 years I am forced to switch, at least by then Wayland will be five years more mature, and maybe my cynicism will even be proven wrong by then and Wayland will be good by then (but I'm not holding my breath for that.) Anyway, I have nothing to lose by using X as long as humanly possible.
Replace "X" with anything and this is why i generally try to avoid relying on open source projects where the majority of the development is driven by some company if there is an alternative, even if they're jankier (and often they are).
One example would be Free Pascal and Lazarus, while there is some commercial support, the overwhelming majority of the development is community-driven and ironically both have a much better history of preserving backwards compatibility than most open source projects backed by larger companies.
Of course exceptions exist for both situations, but as a general rule i find if some project makes a big deal about the company behind them (or even worse, there is a company with the same name as the project) then i tend to look for more community-driven alternatives.
Yes, but I think in the case of Wayland also management had other priorities, i.e. GUI for mobile and/or entertainment systems.
But this is all ok, I think the main problem is that somehow too many in Linux community did not see that the technical arguments for Wayland were not actually too convincing and that giving up decades of compatibility across UNIX systems and beyond is a mistake.
It's a tradeoff, to be honest – I think of Valve's involvement with Wine, where a consistent source of $$$ and developer-hours was (and still is) needed to whack away at the open-ended problem of compatibility.
[dead]
> "most of the reasons given in 2011 were patched in to X11 later"
This definitely doesn't match my memory, and I was there :) Most of the good reasons remain unavailable in X11 to this day.
There definitely were some attempts to advance X11 that post-date Wayland, most notably the proposals by Keith Packard, but they never got much traction.
> This definitely doesn't match my memory, and I was there :) Most of the good reasons remain unavailable in X11 to this day.
You two here don't mention any of the reasons. It is hard to discuss this when there are no specifics, so what was needed, and what was not added?
Per-display DPI settings. No snooping on input without permission. Awareness of the lock screen (the compositor can know that the lock screen is active and provide alternate keybindings instead of having to configure the lock application as well). Locking is not blocked by context menus being open.
I ran XMonad for 15 years, but recently switched to river and am loving it.
> Per-display DPI settings
fwiw, Xorg already had this, since you can set the DPI for each display through RandR/xrandr. In both X11 and Wayland it's up to the toolkit to actually detect the setting and rasterise accordingly.
Wayland actually went backwards in this respect by using "integer scales" (eg, 1, 2, 3) instead of fine-grained DPIs (eg, 96, 192, 288), so using a scale of 1.5 would result in downscale blur (toolkit sees scale as 2, then the compositor scales it down to 75%), whereas in Xorg you could just set the DPI to 144, and the toolkit could theoretically render at the correct resolution. As far as I know Qt was the only toolkit to actually do this automatically, but that's not X11's fault.
Wayland has at least since fixed this in the form of "fractional scaling" [1], but here's [0] an old thread on HN where I complained about it and provided screenshots of the resulting blur.
[0] https://news.ycombinator.com/item?id=32021261
[1] Doing some quick searching it seems like this is still unsupported in Gtk3/Gtk4, maybe planned for Gtk5? Apparently Firefox has only just added support (December 2025), 3 years after the fractional scaling protocol was released. Seems ridiculous to me that Wayland failed to get this right from the start.
You can have different dpi and refresh rate per monitor in X, but you cannot do it while having a shared desktop across them.
X11 can do it. It's Xinerama that can't.
These days Xinerama is the only mainstream tool for dual head, but there used to be others. Nvidia Twinview was one. I bought my first dual head box in 1996 with two Matrox Millennium cards (although it mainly ran NT4) and those cards later went into my dual Athlon XP machine. That ran SUSE until Ubuntu came out.
Xinerama isn't a sine qua non. It's just easy so it became ubiquitous. Maybe it's time to replace it.
> As far as I know Qt was the only toolkit to actually do this automatically, but that's not X11's fault.
Well if three independent programs have to coordinate to make it work, then I would state that it do not support it at all.
It's the same on Wayland. The client (usually part of a toolkit like Gtk/Qt) needs to subscribe to notifications [0] from the server so it can decide the raster size of the surface it wants to draw to. Qt does this on X11 by detecting when your window moves to a screen with another DPI and resizing/rescaling.
I guess the "third" program would be something like xrandr, so the Wayland analogue to that would be wlr-randr (for wlroots compositors), or some other DE-specific tool for configuring screen sizes. Again there's no fundamental difference here.
[0] https://wayland.app/protocols/fractional-scale-v1#wp_fractio...
Is that any different from Wayland? I'm not opposed to declaring that Wayland doesn't support mixed DPI, but it is a funny conclusion
You can do per-display DPI just fine on X11 (through xrandr), it's just the major toolkits don't support it. GTK, for example, reads a single global DPI value from XSETTINGS; there's no reason why it has to be that way.
The annoying thing about the other things you mention is that they honestly are not that difficult to fix.
The X server can throw an error (or just silently ignore it) when one client passes the window of another client and button/key events in the mask to XSelectInput(). And the Xinput2 bits that allow for receiving all key and button events can be changed to only send events destined for windows in the same client. There: input snooping is fixed.
Lock screen awareness can be fixed with new requests/events in the MIT-SCREEN-SCREENSAVER extension (or, if that's fraught, a new extension) that allow an app to create a "special" lock-screen window, which the X server will always stack on top, and send all events to. (That new functionality should probably allow for child windows and popups for input methods as well.) This is honestly not hard!
And yes, some applications will break when you do this. But I cannot see how that's not significantly better than creating an entirely new display protocol that everyone has to port to.
There are other issues with X11, of course, mainly in the graphics pipeline (e.g. the compositor should really be in the X server), but it's hard to believe these things couldn't be fixed. It feels like no one really wanted to do that: building something new from scratch that (in theory) didn't have all of the mistakes of X11 would be more fun, and more rewarding. And I get that, I really do. But Wayland has created so much work, so many thousands (tens of thousands? hundreds of thousands? million+?) of developer-hours of work for people that maybe could have been better spent.
So I think Phoenix is a great idea. It's basically "X12"[0]: removing the old cruft and making breaking changes to fix otherwise-unfixable problems. I imagine most modern, toolkit-using X11 applications would work just fine with it, without modification. Some -- perhaps many -- won't... but that's ok. Run a nested, rootless X11 server inside "X12" if they can't be fixed, or until they're fixed.
[0] Yes, I know that an X12-type thing was considered and rejected (https://www.x.org/wiki/Development/X12/), but I still think it's a better idea, after a decade and a half of Wayland still not being able to support everything we need to port Xfce's components and maintain all of their features.
>You can do per-display DPI just fine on X11 (through xrandr), it's just the major toolkits don't support it. GTK, for example, reads a single global DPI value from XSETTINGS; there's no reason why it has to be that way.
I remember people complaining about the GTK file picker not having a preview for more than a decade, and at some point it sort of became a meme.
When it finally got added, the PR was like a 2-300 lines.
And was added after they rewrote everything for the new GTK version when there're functional patches adding thumbnails to previous versions. (Which were rejected/ignored because they didn't feel good.) A situational very in parallel to Xorg/Wayland if consider: https://news.ycombinator.com/item?id=46382940.
Does it really have to be said that a PR is built upon previous work. It was not a 400 line delta for the whole feature.
> It feels like no one really wanted to do that: building something new from scratch that (in theory) didn't have all of the mistakes of X11 would be more fun, and more rewarding.
My understanding from the outside is that this didn't happen, that Wayland is a spec without a reference implementation - that they didn't actually build anything and are leaving the difficult part up to everyone else.
They do have a reference implementation: weston and libweston but as far as I know, third parties don't use. They implement all their own functionality. Weston is confined more as a prototype.
If the issues are trivially resolved, why did the authors of X decided to abandon X? If the issues could be resolved, why were they not resolved? I am using wayland for more than 5 years now, it just works. X did not. Xscreensaver/lock screens on Qubes are still broken.
What features is Wayland the protocol missing to allow supporting Xfce?
> If the issues are trivially resolved, why did the authors of X decided to abandon X?
They convinced their employers Wayland would be better?
> Xscreensaver/lock screens on Qubes are still broken.
Most people aren't nation-state-level targets and don't worry about security to that degree. But they do like global hotkeys.
Even when you are national-state-level target, there are easier ways to grab the screen.
For local state, it's easier to just install a wireless camera and watch your screen from behind: it leaves no trace on your computer (you may spot it wireless connection, if you lucky). Moreover, they are more interested in your communication devices (your smartphone) than in your desktop.
Foreign states may exploit your notebook builtin "anti-theft" system, Intel Management Engine ("intel" is very good name for a CPU ;-), bugs in NVidia firmware (fonts, OpenGL, etc), bugs in hardware (create a second display to mirror image from primary display to, even when physical display is not attached, for example), etc.
However, I saw that my Firefox window was spied by Chromium window few years ago (I recorded it on Youtube), so this problem in X11 is real.
I am not sure what you saw, but on regular Linux processes of the user can spy on each other anyway. In any case, X had the concept of untrusted clients basically forever but nobody cared to invest even the small amount of work necessary to make it work well because nobody thought it would make a different. That this was later used as a major argument against X convinced me that this is not at all about technology.
Yeah, but with how we’re moving towards running each (desktop) application in its own cgroup, thus restricting what syscalls any given application can do, soon any old user process will no longer be able to read any other process’s memory. I don’t believe that the argument about how we need not patch a hole because another one exists right besides it is sound.
> I don’t believe that the argument about how we need not patch a hole because another one exists right besides it is sound.
It is when you are essentially putting bars in front of your windows while leaving the front door unlocked, i.e. you are making things worse in the name of security while not actually providing any additional security.
> Yeah, but with how we’re moving towards running each (desktop) application in its own cgroup, thus restricting what syscalls any given application can do
Who is we? I don't want or need any of that on my free software system.
I agree. My point was only that this hole can easily be patched in X as well. So the argument was essentially "we do not bother to patch it with X, so we must rewrite X".
It was my understanding that changing the original codebase to fix it would’ve been involved enough as to warrant a rewrite.
I think this is nonsense.
I care about being able to use the same password between the display manager, tty and lock screen auth. Yet, I cannot.
I think the original maintainers and developers of Xorg would be the best people to choose if it is worthwhile to continue working around X or do something else. Yes, X provided functionality that now WMs get to implement themselves - since the developers of Xorg worked closer to Gnome and Qt people, and Gnome and Qt people were OK with this, this didn’t feel like a horrible trade off. And given the diversity of Wayland window managers today, I don’t think it mattered all too much.
What? My screensaver password is the same as my login.
> I think the original maintainers and developers of Xorg would be the best people to choose if it is worthwhile to continue working around X or do something else.
"I think the owners of the Internet infrastructure would be the best people to choose what websites I'm allowed to visit"
No, the users have spoken and continue to speak up that Wayland doesn't serve their use cases.
> What? My screensaver password is the same as my login.
It is the same, yet some uppercase characters are not supported when entered via a yubikey. This has been marked as a WONTFIX. This is rather sad, because I can enter the same password in a TTY with no issues.
What employers?
Also, this level of security is wanted even on a "I don't want my sister to look at my stuff" level, no need to go nation-state level.
In that case you can use a normal distro and the lock screen will work just fine.
Kristian Høgsberg, for example, was a Red Hat employee. Then he worked at Intel, where it appears he continued work on Wayland? So Red Hat and Intel at least? People are being paid full-time to work on Wayland, so those companies.
By now I am not sure if these posts can stil be given the benefit of the doubt or are just dishonest. Who were the developers pushing wayland because of their employers? Kristian Høgsberg (who was a significant xorg developer, because people always deny that wayland was written by xorg guys) originally developed wayland in his free time, it then became a freedesktop project (I would argue not a group run by corporates).
The most active implementation (particularly in the early days) is probably wlroots, started by Drew deVault (again in his free time), who is often quite vocal against corporate control.
In fact the large desktop environments, which are much more under "corporate control", were comparitavely slow to adapt wayland IIRC.
So instead of repeating this accusation, maybe actually give some evidence?
> a freedesktop project (I would argue not a group run by corporates)
Then you'd be wrong. Freedesktop is essentially RedHat and friends.
I didn't think my explanation implied how you interpreted it.
I thought everybody knew Wayland was started by some people working on Xorg already; I did not mean to imply otherwise. Many or all were paid for their work. They believed Wayland was a better approach, and, AFAIK, at some point switched to be paid full-time to work on Wayland instead of X. Which, sounds a lot like they convinced their employer (or a new employer) to pay them to work on Wayland instead of X. Do you believe this is a fair summary of the situation?
> I didn't think my explanation implied how you interpreted it. > > I thought everybody knew Wayland was started by some people working on Xorg already; I did not mean to imply otherwise. Many or all were paid for their work. They believed Wayland was a better approach, and, AFAIK, at some point switched to be paid full-time to work on Wayland instead of X. Which, sounds a lot like they convinced their employer (or a new employer) to pay them to work on Wayland instead of X. Do you believe this is a fair summary of the situation?
Sorry for my combatitive before. I definitely interpreted your previous post differently and I think your clarification is a fairer assessment of the situation. I would still argue that the majority of people implementing the wayland protocol are not paid by their employers to do so (this might now have changed a bit with smithay, which is sponsored by system76 I believe).
HDR something that can't be brought to X11 without breaking backwards compatibility.
https://github.com/reaperx7/HDR10-X11
First line of the readme: Non-functional implementation work-in-progress framework code for getting HDR10 working under X11.
The 3 justifications I remember for Wayland were security (isolating windows from each other), multi DPI, and eliminating tearing. All are now features of XLibre.
This is all playing a bit fast and loose with the details.
The "isolating windows from each other" stuff in Xlibre for example is the Xnamespace extension, which requires a static config file up front and lets X clients within the namespace interact as before. This may have some utility for specific scenarios (dunno, kiosks maybe?), but is nothing like Wayland's default security model.
Similarly, enabling TearTree in the modesetting driver and having another backbuffer in the driver is a huge crutch vs. having a proper architecture where the compositor can own presentation timing. For one it makes adaptive sync/VRR a lot trickier.
These things are overall not equivalent.
It isn't clear why any of this would require a rewrite.
At around that time X.org worked entirely fine for me, sans some NVIDIA driver config I had to set up in /etc
few years after even that wasn't required.
Yeah it missed some features I could theoretically use in 2025 but I didn't had different DPI/refresh rate displays back then and those could probably be put into X11 protocol just fine
Let me know when X11 handles fractional scaling across mixed dpi and refresh rate monitors, with HDR and VRR. To me, who has finally been able to drop Windows for gaming in the last 3 months, the benefits of wayland are very real.
Technically Xorg can handle fractional scaling across mixed dpi and refresh rate monitors, but it requires support from toolkits, window managers and applications which means the developers of all of those (or at least toolkits and window managers) need to cooperate. At minimum, you need toolkit support for the most basic. AFAIK Qt6 does have this support and should be able to handle fractional scaling across mixed DPI monitors but not in an ideal way since for better experience you'd need the app/toolkit cooperating with the window manager instead of the toolkit trying to do everything on its own without knowledge of the rest of the desktop. I wrote about it in detail here[0] but the gist is that it is largely an issue of getting the developers of various projects to cooperate than some feature Xorg itself lacks (it doesn't). Wayland had it easier here because it started from scratch and developers had to worry about those things for supporting it. On a more positive note, because of Wayland (and Win32, if a toolkit support scaling there) the the hard part of the work on the toolkit side should already be there.
For VRR the issue is how current desktop compositors render their output, though it should be technically possible to make a Xorg desktop compositor to use separate outputs for each monitor (may need to use Vulkan with custom barriers for vsync though, this is something i've only ). The alternative is to not use a desktop compositor at all, which is what i'm doing (since i also dislike the desktop lag introduced by desktop compositors). I have a 165Hz VRR monitor that i used it for a bit (even connected a separate 60Hz monitor for a bit) and worked fine, though eventually i disabled the VRR functionality since at 165Hz tearing is almost imperceptible (and it never bothered me even on 60Hz monitors anyway) while my monitor is one of those that have some annoying flickering with VRR enabled. In any case, the issue is with the setup and desktop compositor used, not with Xorg itself.
Of course from a user's perspective all these most likely do not make much of a difference.
For HDR there is no support for it Xorg though. Personally, the main use for HDR would be either some movie or playing a game, i.e. fullscreen apps, and switching to another virtual terminal running a Wayland compositor (or just Gamescope) just for those is perfectly fine - having to press ctrl+alt+f1/f2 instead of alt+tab is not a deal big enough to change the entire desktop setup i've been using for many years :-P.
[0] https://news.ycombinator.com/item?id=45858043
HDR support is still a mess with Wayland. Sometimes you can fix it with gamescope but it’s a swiss cheese thing where for example gamescope breaks some controllers in some games with some GPU drivers. Maybe in a couple more years it’ll be “it just works” territory but it’s taking a while to get there.
Thanks for linking Arcan, looks interesting.
After a quick scan, Arcan seems to be pushing a microkernel approach, with some clients providing display server capabilities and others talking to them via shared memory. This will have the same problem as all other microkernels - nice for research, but the extra completely outweights the marginal benefits over a monolithic thing that generally has a smaller API surface to maintain.
First time I've heard of Arcan. Sounds intriguing.
IMO, if you have to rewrite a display server implementation then you're already proving all the protocol advocates right.
Why? People complain that the YAML specification/protocol is too complex. This may be, but I found using YAML much, much easier and nicer than XML. So to me these two things are not necessarily interconnected. You can have a great implementation and a crappy protocol; but also a great protocol and a crappy implementation.
[dead]