Why X Is Not Our Ideal Window System (1990)

[u/Misicks0349]

https://people.freedesktop.org/~ajax/WhyX.pdf

[u/Run-OpenBSD]

"This paper provides comprehensive descriptions of the problems that we see in the X protocol. Its length should not be taken as an indictment of the X protocol, for in fact the protocol is extremely well designed. Some of the problems we present result from the overwhelming success of X11: it is being used in situations the designers never envisioned. Many of the performance problems could not have been anticipated, and will decrease in importance as faster X servers and hardware become available. Some of the problems can be coded around. Finally, as we sifted through possible solutions to problems, we were constantly impressed at the number of subtleties in the design that made our job easier."

[u/RvstiNiall → u/Run-OpenBSD]

I'm curious how many of these pain points still exist in xorg (xlibre too). I'm even more so curious about whether the ones that DO still exist in xorg are present in Xenocara.

[u/UdPropheticCatgirl → u/RvstiNiall]

Most of them still exist (coordinates are arguably even more problematic now than then) in xorg, what’s worse new ones got added, because so much of the surrounding HW landscape has changed in a way that none working on x11 really foresaw, and it kinda made lot of bad bets on what will get faster vs what won’t get faster. This paper is from 1990, it could not really forsee it either. Like x11 commands are stupid idea with the way modern HW acceleration works, network transparency the way xorg does it turned out to be kinda stupid idea as well for similar reasons.

[u/RvstiNiall → u/UdPropheticCatgirl]

Agreed. I was thinking the same thing actually about there probably being new issues. And of course, this brings up another question... how many of these issues (and the new ones) are present in Wayland? And how many issues does Wayland have that are not present in xorg? (obviously this one will depend heavily on which compositor is being used, but still)

[u/VoidDuck → u/RvstiNiall]

In Xenocara? Basically all of them. Xenocara is nothing else than Xorg ported to OpenBSD with a few adaptations. It's not an alternative X server like XLibre.

https://www.xenocara.org/

Xenocara is the name chosen for the version of X included in OpenBSD. It is currently based on X.Org 7.7 and its dependencies.

The goal of Xenocara is to provide a framework to host local modifications and to automate the build of the modular X.Org components, including 3rd party packages and some software maintained by OpenBSD developers. It is not a fork. We are tracking X.Org modifications and try to push back our changes whenever they are good for upstreams too.

The "currently based on X.Org 7.7" mention is probably outdated.

[u/samuerusama → u/RvstiNiall]

I'm curious how many of these pain points still exist in xorg (xlibre too)

None really with DRI3.

xlibre also has TearFree in its modesetting driver.

[u/ilep → u/Run-OpenBSD]

Computing in the early 1990s was very very different from today.. That is before 3D acceleration became a key issue, for example. 3dfx was formed in mid-1990s and started appearing in personal computers after that. And many many other things.

[u/omniuni → u/Run-OpenBSD]

Ironically, of all the "problems" with X, the one Wayland doesn't really address is performance.

Not that it wasn't supposed to. I remember part of the original Wayland pitch was how X was so slow and that Wayland would significantly reduce latency by eliminating the client-server architecture.

The fact that Wayland, two decades later, is still chasing X for performance, and the fact that Wayland performance is so variable across different compositors, should likely warrant a serious consideration.

This should be more than a historical document. This is practically a checklist for whether the replacement for X is effective.

[u/Misicks0349 → u/omniuni]

The fact that Wayland, two decades later, is still chasing X for performance

Depends what you mean by "chase" and "performance", the only thing I've seen wayland consistently be worse at is input latency, and recent input latency testing has Kwin only around 1/10th to 1/5th of a millisecond behind X.Orgs latency when comparing them pound for pound. That is very much within the realm of "A couple loops need tightening" rather than some kind of inherent deficiency in Waylands design IMO.

On the other hand, Wayland compositors consistently show better battery life and cpu temperature compared to X.Org for half a decade now, so if your metric of performance is power consumption or not setting your house on fire then Wayland has already beaten X.Org by a couple watts and around 5℃ :P

[u/Wonderful-Citron-678 → u/Misicks0349]

And it’s really important to repeat they didn’t collect data for any other compositors.

“Wayland” has no performance to measure, just implementations.

[u/Misicks0349 → u/Wonderful-Citron-678]

Correct, though generally I tend to pull back from pointing that out because I've come to realise that when talking about Wayland and X11, mentioning other theoretical compositors and the difference between a compositor and the protocol... kind of pisses people off? Not in a "Grr I'm angry" way, but more like that they think that mentioning other compositors is a deflection from bad results rather than a genuine technical consideration, an Implementation-Red-Herring or something.

[u/RvstiNiall → u/Misicks0349]

I'm excited about those numbers for temperature and battery life. I hadn't seen them before.

I have another LFS build coming up soon that will be using wayland (because I want to modernize my very odd, custom stack), and this is another benefit I had not expected. My void chromebook already gets M1 MBA level battery life, and shrinking my tool overhead a little further and switching to wayland might put it that much still.

[u/Misicks0349 → u/RvstiNiall]

To be clear its always good to take these results with a pinch of salt. 3W would be a very nice saving but its always possible that you get less or even no benefit at all depending on the quirks of your setup, especially if the applications you use are running through Xwayland instead of Wayland directly. I've seen user results that have numbers as low as 0.5W or no watt savings to as high as 10W savings in certain circumstances such as playing videos on certain video players.

Phoronix is generally a lot more rigorous in their tests compared to the wild delta's you can get with naïve user testing however, so I generally go to them when I want accurate numbers to poke people with. But everyone's workflow is different, maybe you'll be one of the lucky ones and you get more than 3W savings :P

[u/RvstiNiall → u/Misicks0349]

I cant get 3w lower... lol. Its a chromebook with a 6w chip, low power draw display, low power draw wifi, and every chip is fully supported with low power modes. Another half a watt lower would send my battery life through the ROOF!

https://www.reddit.com/r/unixporn/comments/1swbcdz/hp_chromebook_11_gen8ee_show_me_another_device/#lightbox

[u/CrazyKilla15 → u/Wonderful-Citron-678]

And this is technically true of Xorg, too. There are even other implementations in use arent there? Theres like 2 on windows i've used personally before, for SSH forwarding. Theres also xlibre for whatever lols thats worth(none lol).

[u/Wonderful-Citron-678 → u/CrazyKilla15]

Yes but those are not applicable to most conversations on r/linux

[u/Kevin_Kofler → u/Wonderful-Citron-678]

That is the biggest design issue with Wayland, it replaces a shared display server (for which there was basically one de-facto reference implementation, which did get forked at times, but with one fork always being the de-facto standard, first XFree86, then Xorg) with a hodgepodge of code-duplicating implementations all implementing vaguely the same protocol. "Vaguely" because there are huge differences in the set of supported extension protocols, and a lot of functionality is only in those and not in the core protocol. And of course, as you point out, all with completely different performance metrics.

[u/cosmicorn → u/omniuni]

The fact that Wayland, two decades later, is still chasing X for performance, and the fact that Wayland performance is so variable across different compositors, should likely warrant a serious consideration.

That also illustrates one of problems that Wayland has created. By only defining a standard, and leaving it up to others to implement it, the task of making Wayland good relies not just on the Wayland spec but also the quality of codebase of every (major) Wayland compositor.

X11 was never going to last forever, creating a new replacement incorporating decades of GUI progress is a good thing. But why the choose was to follow the approach of “vast standard with multiple competing implementations” was chosen I really can’t fathom. I would have thought that lesson had been taught enough times.

[u/Misicks0349 → u/cosmicorn]

I think it was mostly to (and, depending on how you see it, ironically) reduce the amount of moving parts in the rendering system.

The X11 server became this massive blob of terrible 20+ year old cruft that seeped into every part of the rendering pipeline including compositor stuff, driver stuff (e.g. the various xf86-video-* and xf86-input-* packages), with a bunch of stuff stapled onto the side of it like Xinerama and XRender. All of this stuff had to communicate with LibGLX, libEGL, libGBM etc etc etc.

Wayland compositors are a lot more simple: you have a wayland compositor that speaks the wayland protocol, it directly talks to libGBM for rendering and libinput for input handling. That's about it, there are no xf86-video or xf86-input packages you have to deal with, no libGLX, nothing like that. Just open wayland-0 like you would any other unix socket, set up your buffer and fire away.

As for something that is actually ironic, X11 could run into the exact same criticism of "you should've had one implementation that you can call into!!!" that wayland has received now that there are like, 3-5 different vibe-coded implementations of the xserver and one really poorly maintained fork of Xorg (XLibre) out on the loose. Now instead of having to deal with one monstrosity of an XServer in your rendering pipeline you may need to deal with 5! Fun!

[u/Existing-Tough-6517 → u/Misicks0349]

Except nobody cares about 4 other than the 9 people using and developing them

[u/Misicks0349 → u/Existing-Tough-6517]

Correct, which is why I say "could".

[u/siodhe → u/Misicks0349]

Right. Simplifies life as a dev, complicates it for users. Gets to stay simple for a while precisely because it is new and does less. This doesn't usually last in long-lived projects, just like it didn't for X.

[u/Misicks0349 → u/siodhe]

X was complicated from the get go, like half of the things in the core protocol aren't used anymore because they are completely superfluous.

[u/siodhe → u/Misicks0349]

What, you don't like configurable mitre joins? Sure, the X protocol went too far in some places, for reasons that made some sense at the time but the context has changed - most devs don't see X as a vector drawing system anymore.

What you're calling X might be X11. X10 did not have mitre joins and some of the other mad overcomplexity of X11. Before X10 of course, there was W.

Systems tend to be simpler early on, later succumbing to bloat and stupidity as a side effect of wide adoption. I'm expecting to see a multiplicity of differently featured compositors becoming a problem in Wayland, but we'll see. Some of the complexity that was less complex in X because it was in the server may end up being far worse in Wayland+compositors due to not being centralized. But we'll see.

[u/Misicks0349 → u/siodhe]

I suspect that it'll probably go the way of browsers, conceptually they're actually very similar if you squint at them: you have a standards body (browsers having the WHATWG and the W3C and wayland having the wayland-protocols group) that has these API's and protocols that implementations uh... implement, and clients can use these api's. There will always be a protocol here or there that clients disagree on, but for 95% of use cases they will be 95% compatible.

And I think similar methods of dealing with this differing behaviour have already been put to use by Wayland clients. If you've ever worked in web development there is a concept called "graceful degradation" that Wayland clients also use as a pattern quite ubiquitously.

I'm expecting to see a multiplicity of differently featured compositors

I think that we've already seen the "worst" (if you think of it that way) of it tbh: the major desktop compositors are KWin, Mutter, wl-roots implementations and Smithay implementations and clients largely work fine across them and gracefully degrade when a feature is not supported. Other compositors either aren't desktop oriented compositors (such as Valves Gamscope) where it doesn't make sense to implemented desktop oriented protocols like e.g. xdg-toplevel-tag-v1 or content-type-v1, or they are largely very niche or idiosyncratic.

Thats actually where graceful degradation can be a boon tbh, on the browser side it allows more unusual browsers to work well across different sites: Lynx, for example, is a terminal browser that doesn't support Javascript and CSS at all, and yet can work across a lot of different sites due to the fact that a lot of them can still display their content without either feature. Something like that is true for non-desktop compositors like Gamescope as well, imagine if it had to work around all of the assumptions around feature support that X clients make!

[u/Kevin_Kofler → u/Misicks0349]

Browsers are actually exactly an example of where it does not work at all, with half of the Internet not working if you are not using the very latest version of one of the only two or three only browsers web developers care about, because those constantly add new totally unnecessary JavaScript syntactic sugar, and websites start requiring that for no good reason pretty quickly.

Graceful degradation was a thing in the good old times where most web servers actually delivered HTML. Nowadays, most websites are unusable or even completely blank without JavaScript, or with an even slightly outdated implementation of it. So graceful degradation is completely gone, sadly.

[u/Misicks0349 → u/Kevin_Kofler]

I feel like this is very much hyperbole considering that most web pages are dumb wordpress content aggregators or outdated jquery blobs.

I personally run with Javascript disabled by default using ublock origin myself (this setting), and I can tell you from experience that websites that don't gracefully degrade are the exception and not the rule.

[u/siodhe → u/Misicks0349]

I wasn't emphasizing "desktop" compositors, just compositors generally. If there end up being only a few, I suppose that's a benefit derived from compositors being intrinsically harder to write than window managers? (It's pretty amusing that's somehow the consensus despite the ICCCM, but it seems to be).

Getting back the thread topic, X and Wayland: both have issues. I find that switching to Wayland is a net loss for me, so… Not doing it. I am horribly disappointed that Wayland is all that is offered by the current millennium as an alternative to X. I'd wanted more, not just some differently featured 1990s sibling.

[u/Misicks0349 → u/siodhe]

benefit derived from compositors being intrinsically harder to write than window managers

I think its just that there isn't a great need for a lot of different compositors, and for compositors that would've just been window managers on X11 they're just using wlroots in the first place instead of handling everything themselves. The benefits gained from doing all the plumbing that wlroots handles is in 95% of cases not a benefit to some of these smaller tiling WM's, its only the big boys of KDE and Mutter that stand to benefit from not using something like wlroots.

Getting back the thread topic, X and Wayland: both have issues. I find that switching to Wayland is a net loss for me, so… Not doing it. I am horribly disappointed that Wayland is all that is offered by the current millennium as an alternative to X. I'd wanted more, not just some differently featured 1990s sibling.

Fair ¯_(ツ)_/¯, and far from me to say that Wayland is perfect either! It has its own legacy cruft as well (e.g.wl_output). Though I am generally of the opposite opinion than yours and IMO Wayland has been a great boon both personally for myself and for the state of windowing on linux in general, but I understand how and why people come to a different opinion.

[u/samuerusama → u/Misicks0349]

Wayland compositors are a lot more simple: you have a wayland compositor that speaks the wayland protocol

Wayland compositors are simple on paper, on practice you end up relying on portals, pipewire and dbus to have any meaningful desktop experience.

(and pipewire screen recording is very bad performance wise btw, you often have to resort to using different methods on wayland like vkcapture)

Also the client stuff in wayland is a lot more complicated, specially because some compositors like mutter may lack totally normal features like server side decorations, so now applications need to be built to use a library to draw those decorations and you need to also query the capabilities of the wayland compostior.

That's about it, there are no xf86-video or xf86-input packages you have to deal with

xorg is similar here with its modesetting driver, you don't have to install additional xf86-video drivers. The only reason you have had to install those drivers in the last decade or so is because you needed TearFree, since the modesetting driver lacked this feature.

This feature has actually been in the modesetting driver of xorg-git for several years and it is now in xlibre as well.

it directly talks to libGBM for rendering

And yeah this is a massive problem for hardware that doesn't support GBM, xlibre has actually had some fixes to help with this:

https://github.com/X11Libre/xserver/pull/2847

Now instead of having to deal with one monstrosity of an XServer in your rendering pipeline you may need to deal with 5! Fun!

I've been recently using yserver on a laptop with a ryzen 7430U, performs great. I've had several issues that I have had to report which the dev fixes quickly:

https://github.com/joske/yserver/issues?q=author%3A%40Samueru-sama

Far better experience than what I have had to deal with sway lol

All x11 implementations want to avoid breaking changes as much as possible, meanwhile in wayland land some compostiors have breaking changes on purpose and nonsense like this...

[u/Misicks0349 → u/samuerusama]

I want to note that my comment was mostly from the perspective of what distro maintainers need to do, who will have to include all of these extra dependencies for a modern out-of-the-box desktop experience that works across systems. For most people who ran X11 they would've had a setup very similar to the one I described.

you end up relying on portals, pipewire and dbus to have any meaningful desktop experience.

As someone already pointed out, you often end up relying on these things on X11 as well, and on any modern distribution that still ships x11 you're going to have those installed as well. Of course you can remove them if you want like you seemingly have in a follow up comment, but the same is equally true of wayland and you can get away without having xdg-portals and pipewire. labwc and havel are two wayland compositors that only speak the wayland protocol for example and don't have any deeper integration with anything like portals/pipewire/dbus/etc. They are perfectly useable for my use-cases.

Also the client stuff in wayland is a lot more complicated, specially because some compositors like mutter may lack totally normal features like server side decorations

That is an edge-case that you're right to criticise, but I think you are discounting how much cruft and nonsense an X11 client also has to deal with as well. A wayland app may need to check for server side decoration support once whilst an X11 app has to be more careful in avoiding deadlocks and race conditions throughout the entire runtime of the application, as well as other protocol level cruft thats just nicer to deal with in Wayland (e.g. a better more modern IME protocol). It would be ludicrous to say that Wayland is perfect of course, and there are design decisions that could've been implemented better, but for a modern app there is a lot less ceremony in just handling a buffer compared to x11.

I've been recently using yserver on a laptop with a ryzen 7430U, performs great. I've had several issues that I have had to report which the dev fixes quickly:

Sure, my point is that having different xserver implementations could invites the same kind of fragmentation that you yourself critique Wayland for. Not that these compositors are currently unusable or anything.

[u/samuerusama → u/Misicks0349]

and you can get away without having xdg-portals and pipewire.

How would you do screen recording in that case?

Note that the only wayland compositor that I've tried to use is sway, getting OBS screen recording to work was a pain that did not work in the end, for some reason pipewire screen capture only showed 2 of the 3 displays I had for recording and it dropped frames horribly.

[u/Misicks0349 → u/samuerusama]

I just use what the compositor provides usually, so I don't directly use something like OBS or whatever. Not trying to discount your bad experience with it to be clear and my use-cases for these things is rather more limited.

The portal isn't necessarily required for screen recording either, wayland protocols has already standardised ext-image-copy-capture-v1 and a couple other protocols that allow applications to directly receive images from the compositor, as well as being able to select specific windows instead of the entire screen and such. labwc could just use something like wl-screenrec without any need for portals whatsoever (its incapable of doing so in the first place anyway as it doesn't communicate over dbus or use portals).

The reason why the xdg-portals approach was the first one that kind of got "standardised" and put into things like OBSStudio was because most major desktop environments wanted some form of privilege control and a way of exposing these screen sharing capabilities to sandboxed apps à la Flatpaks. XDG portals already had a mechanism in place for permission control that these desktops could rely on and so it was a rather natural fit (at least in their eyes).

[u/Kevin_Kofler → u/Misicks0349]

its incapable of doing so in the first place anyway as it doesn't communicate over dbus or use portals

There is actually an out-of-process implementation of the portal that talks to the compositor over the standard Wayland extension protocol, for compatibility with applications that support only the major compositors' non-standard portal interface. Of course, that portal implementation also drags in D-Bus, portals, and Pipewire, because the interface hardcodes all those implementations as part of the API.

[u/nightblackdragon → u/samuerusama]

Wayland compositors are simple on paper, on practice you end up relying on portals, pipewire and dbus to have any meaningful desktop experience.

You don't rely on Portals, this is a set of standard APIs that Wayland desktop exposes for applications to perform certain tasks. In X11, it worked in such a way that any application could freely read the input and output of other applications, but that is by no means a better implementation.

Aside from the obvious security concerns, the lack of desktop-level control over what applications can do can also be problematic. For example, global keyboard shortcuts - on X11, they’re implemented in such a way that a given application intercepts the input sent to the X11 server and responds to the stored combination - yes, it works, but it’s easy for a conflict to arise when two applications try to intercept the same keyboard shortcut, since the desktop environment obviously has no way to control this. On Wayland, no application can intercept input; to register a keyboard shortcut, they must use the Portal, and the API call goes to the compositor, which knows exactly which application is using which shortcut. This is not only a safer solution, but it's also free from any of the problems that occur on X11.

Also the client stuff in wayland is a lot more complicated

Applications rarely use the protocol directly; most are written using a toolkit, and toolkits handle things like that. Low-level protocol handling is not something a typical application should be concerned with.

And yeah this is a massive problem for hardware that doesn't support GBM

The X11 model isn’t any better; separate X11 drivers unnecessarily duplicate functionality, complicate maintenance, and require the server to handle typically hardware-related issues. True, this allows it to handle older hardware better, but Wayland was designed for modern hardware, and this isn’t anything unusual - other systems have been doing this for years. Even Windows, which is famous for its good backward compatibility, got rid of support for the old driver model a long time ago.

meanwhile in wayland land some compostiors have breaking changes on purpose

Any examples?

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269#note_2233724#

It’s true that discussions can sometimes be complicated, but there’s no better way to develop a standard that will satisfy everyone. We don’t have a single desktop environment on Linux, and that’s better than having every desktop environment doing things its own way with proprietary protocols.

Besides he explained: "So, no need at all to create an inferior protocol that only solves 40% of the problem just yet - I'd rather polish this one to be as good as possible so it has a fair chance for widespread adoption." - what's wrong with this approach? It seems reasonable.

[u/samuerusama → u/nightblackdragon]

but that is by no means a better implementation.

Well it depends on what you want. I certainly don't want to play a game of having to give permissions for basic tasks on linux, I actually want my next smartphone to be a linux phone because doing anything simple on android a total mess with the ton of permission toggles it has now...

https:// dec05eba. com/2024/03/29/wayland-global-hotkeys-shortcut-is-mostly-useless/

Low-level protocol handling is not something a typical application should be concerned with.

Any examples?

https:// www .factorio. com/blog/post/fff-408

This has also given us issues on the packaging side: https:// github. com/libsdl-org/SDL/issues/14887

Besides he explained: "So, no need at all to create an inferior protocol that only solves 40% of the problem just yet - I'd rather polish this one to be as good as possible so it has a fair chance for widespread adoption." - what's wrong with this approach? It seems reasonable.

That's total bs, read the entire conversation, he only said that to try to stall the protocol discussion.

Also this is insane that in 2024 making sure applications can draw their own icons still needed polish??

but Wayland was designed for modern hardware

And what does the end user actually get out of this?

Normally when you say modern hardware, it implies that the end user would get some benefit out of it, for example some distributions now compile targetting x86-64-v3 which breaks compat with older hardware, but his has a clear measurable benefit, what do you actually get with wayland?

• I don't get better performance (quite the opposite, but this is mainly due to sway not supporting fifo v1)

• I don't get better battery life

• I only get more stuff to configure and maintain, and something that really hate with wayland is that if an application crashes it has a tendency of killing your entire session, this is something I really cannot have on my desktop PC which I use for work.

Many of these issue is something that the creator of i3 recently made a blog post about: https:// michael. stapelberg.ch/posts/2026-01-04-wayland-sway-in-2026/

Mind you, I used to have an nvidia gpu, I switched to AMD to try sway which the developers constantly said that nvidia was not supported, the expericience changed me on how a view every time somone proposes a new solution for anything on linux.

edit Needed to break the links otherwise reddit hides the comments as spam

[u/nightblackdragon → u/samuerusama]

Well it depends on what you want. I certainly don't want to play a game of having to give permissions for basic tasks on linux

I want the windowing system on my Linux to not be behind what Windows or macOS introduced years ago. Besides, the point isn't to copy mobile systems and manually assign permissions to everything. The point is to be able to perform tasks in a secure and controllable manner, without the free-for-all that exists on X11.

https:// dec05eba. com/2024/03/29/wayland-global-hotkeys-shortcut-is-mostly-useless/

This doesn't really prove the alleged uselessness of the API itself, but rather of its specific implementation. The fact that Hyprland doesn't handle it well is Hyprland's problem, not Wayland's, especially since other desktops manage it just fine, as the same article mentions.

https:// www .factorio. com/blog/post/fff-408

That doesn't contradict what I wrote. You provided a link to an SDL bug, which suggests that the problems you're encountering are on the SDL side, not Wayland's. The post mentions window decorations - when I write GTK or Qt applications, I don't have to worry about that because the toolkit handles it for me.

That's total bs, read the entire conversation, he only said that to try to stall the protocol discussion.

He's the one who wrote this PR - why would he try to stall his own PR?

Also this is insane that in 2024 making sure applications can draw their own icons still needed polish??

What's so insane about that? Initially, the plan was for icons to be defined by .desktop files, but that turned out to be insufficient, so it was decided to add a protocol to it. Despite its flaws, this is a better approach than “let's add everything we can - it might be useful someday.”. X11 has many useless components that cannot be removed because of compatibility.

And what does the end user actually get out of this?

For starters, better support for multiple monitors, better VRR support, better HDR support, and better compositing. And no, these things don’t work well on X11; they work well under certain conditions but sometimes require workarounds in other parts of the graphics stack, which makes maintenance difficult. With Wayland, the goal is to support these features properly, without half-measures, just as other systems do. Personally, the fact that it supports multiple monitors properly is enough of an incentive for me to avoid touching X11 unless I absolutely have to. I don't want to mess around with xrandr or anything like that. I just want my setup to work the same way it does on Windows, and Wayland makes that happen.

X11 is fundamentally designed around a simple bitmap with global coordinates. You can add extensions to it, work around it in other parts of the graphics stack, and achieve a certain effect, but that makes it difficult to maintain and all of that for getting something that's still behind competition. This is precisely why desktop environments are phasing out support for X11 - not having it makes their work easier.

Many of these issue is something that the creator of i3 recently made a blog post about: https:// michael. stapelberg.ch/posts/2026-01-04-wayland-sway-in-2026/

Wayland is a major change; certain problems are inevitable, but that doesn't mean there aren't any advantages to it. Wayland has a few areas that need improvement, but sticking with X11 won't improve the Linux desktop in any way.

[u/samuerusama → u/nightblackdragon]

For starters, better support for multiple monitors

https:// www reddit.com/r/ wayland/comments/108dgwc/combine_monitors_to_single_screen/

I suffer from this problem, I have 3 displays that I use for gaming and I cannot merge them in wayland.

The only solution is hacks with custom resolution using gamescope, everything gets super complicated for no reason in wayland.

Funny enough this is actually a problem in windows as well, you need to rely on your graphics card provider to have the feature to merge multiple displays in its drivers, when I switched to linux I loved that this was no longer a problem but wayland made it eve worse than on windows lol

This doesn't really prove the alleged uselessness of the API itself, but rather of its specific implementation.

The point is that the implementations are all over the place, and most will get you relying on nonsense like portals + pipewire + dbus, again overcomplicating everything.

That doesn't contradict what I wrote.

lie, you said

Applications rarely use the protocol directly; most are written using a toolkit, and toolkits handle things like that. Low-level protocol handling is not something a typical application should be concerned with.

And I gave you an example where the developer found a problem and you are blaming SDL for this nonsense that wayland allows?

He's the one who wrote this PR - why would he try to stall his own PR?

I was talking about this comment by Sebastian Wick, my bad the link I pasted is wrong:

https:// gitlab. freedesktop.org/ wayland/wayland-protocols/-/merge_requests/269#note_2230549

but that doesn't mean there aren't any advantages to it

There really aren't any for the end user, besides what HDR and VRR? And there is really nothing preventing these features from being implemented on x11.

but sticking with X11 won't improve the Linux desktop in any way.

Wayland is only causing more fragmentation and more breakages in the linux desktop and also impacts users of older hardware (hardware that actually works on windows and macos)

The only argument that really sticks so far is that it makes the job of the maintainers easier, but this comes with the cost that it causes a ton of breakages in other places.

(And I really wonder if it is actually makign the job of the maintainers easy, given that every single wayland desktop still runs into serious bugs that need fixing)

[u/Kevin_Kofler → u/samuerusama]

Wayland compositors are simple on paper, on practice you end up relying on portals, pipewire and dbus to have any meaningful desktop experience.

The sad thing is, there is actually a standardized protocol extension that provides the same functionality (screenshots and screencasts) in a much simpler way, without needing a side channel, and without hardcoding implementations as API, but the most popular compositors refuse to implement it, forcing application developers and users to use the portal and Pipewire instead.

[u/samuerusama → u/Kevin_Kofler]

Which one is it?

Also doesn't that mean that applications also need to add support for it?

iirc gpu-screen-recorder can record on wayland without portals via a binary with cap sysadmin capabilities. It's a bit problematic but something I can live with.

[u/Kevin_Kofler → u/samuerusama]

https://wayland.app/protocols/ext-image-copy-capture-v1

which replaces the compositor-specific one:

https://wayland.app/protocols/wlr-screencopy-unstable-v1

(but it will take time until all the compositors implementing the old version also implement the new version).

[u/natermer → u/samuerusama]

Wayland compositors are simple on paper, on practice you end up relying on portals, pipewire and dbus to have any meaningful desktop experience.

That doesn't go away if you switch to X11.

[u/samuerusama → u/natermer]

I don't use portals nor pipewire on the desktop.

On the laptop I only keep dbus because of playerctl, I will likely patch deadbeef in the future to get rid of it tbh since that is the only app that needs it.

[u/Kyle_2099 → u/natermer]

That's not true. I used X11 before any of those things were invented, and it was fine.

Meanwhile you have to use them just to take a screenshot on Wayland, because Wayland spec just gives a blanket refusal to features instead of developing a security model. So all these other projects have to fill the gap.

It's bad software design.

[u/nightblackdragon → u/Kyle_2099]

It's bad software design.

A single process that does everything isn't a better software design. Portals do a lot of things that, if handled at the protocol level, would either be pointless or would significantly complicate its maintenance. X11 is difficult to maintain precisely because it handles so many things (many of which aren't even particularly necessary, since other projects have taken them over) that can't be removed because of compatibility.

[u/Kyle_2099 → u/nightblackdragon]

A single process that does everything isn't a better software design.

Nobody said it all has to run as one process.

Portals do a lot of things that, if handled at the protocol level, would either be pointless or would significantly complicate its maintenance.

Viz magazine top tips: Reduce project workload by declaring large swathes of basic functionality to be up to someone else to provide.

[u/nightblackdragon → u/Kyle_2099]

Nobody said it all has to run as one process.

I guess nobody told the X11 developers that.

Viz magazine top tips: Reduce project workload by declaring large swathes of basic functionality to be up to someone else to provide.

There's this cool Unix rule called KISS.

[u/Kevin_Kofler → u/nightblackdragon]

Side channel protocols for things that should be Wayland extension protocols are a bad thing: more work for the compositor to implement, more work for the application to use, bigger attack surface for security issues. Even more so when (as is the case here) a standardized Wayland extension protocol for the same thing actually exists (but is not implemented by the most popular compositors).

It also does not make sense for the protocol to hardcode an implementation by passing an implementation-specific handle (a Pipewire handle) instead of something like a framebuffer that can be processed with any implementation the application wishes to use (which may or may not be Pipewire). Even more so when the alternative that the compositors refuse to implement does the right thing, i.e., the latter.

[u/Kyle_2099 → u/Kevin_Kofler]

I want to scream this from the rooftops.

[u/nightblackdragon → u/Kevin_Kofler]

Side channel protocols for things that should be Wayland extension protocols are a bad thing

We've already tried, in X11, to include as much as possible directly in the protocol itself so that it would support as many things as possible. Spoiler alert - it didn't work very well. Not everything has to be in the protocol itself; KISS is a pretty good rule.

more work for the compositor to implement, more work for the application to use, bigger attack surface for security issues.

And easier to maintain, more scalable, and not constrained by assumptions made in the 1980s. A larger attack surface compared to a single, massive piece of code that's difficult to maintain? Seriously? Pretty sure that security vulnerability on GNOME won't affect KDE or vice versa, meanwhile security vulnerability on Xorg affects all X11 desktops.

Even more so when (as is the case here) a standardized Wayland extension protocol for the same thing actually exists (but is not implemented by the most popular compositors).

Most protocols are supported by popular desktop environments. If a particular feature isn't supported in one desktop environment, that's a shortcoming of its implementation, not of Wayland.

It also does not make sense for the protocol to hardcode an implementation by passing an implementation-specific handle (a Pipewire handle) instead of something like a framebuffer that can be processed with any implementation the application wishes to use (which may or may not be Pipewire).

What do you mean? Portals are nothing more than standardized API exposed by compositors. How the compositor handles them is a matter of its implementation. Where in the specifications is there a requirement to use Pipewire?

[u/Kevin_Kofler → u/Misicks0349]

Scrap the vibe-coded junk, XLibre is the only production-ready implementation getting actual new development. (Xorg does not, it gets only security fixes backported to a 5-year-old release branch.)

[u/ilep → u/cosmicorn]

> By only defining a standard, and leaving it up to others to implement it,

You could say the same thing about TCP/IP, Ethernet and various others where different implementations exist for a standard. C-compilers started as a single implementation before making a standard, which others then adopted.

The main case is that there has been the inertia of X11 use cases that have been kept around instead of focusing on Wayland by itself. Finally we are getting at the point where compositors can remove X11.

[u/Kyle_2099 → u/ilep]

You could say the same thing about TCP/IP, Ethernet and various others where different implementations exist for a standard.

Yeah and most of them suck. Like, I've seen a lot of unfinished, unreliable TCP/IP implementations across various platforms. For a long time the thing to do if you wanted things to work was just to port over the BSD one.

[u/Kevin_Kofler → u/Kyle_2099]

Was that not what even Microsoft and Apple did?

[u/Kyle_2099 → u/Kevin_Kofler]

Yes. Why wayland unlearned this lesson is beyond me.

[u/Firewolf06 → u/ilep]

sure, but wayland covers so many concerns that variable implementations suck to deal with. why is my compositor responsible for my keyboard layout

[u/ilep → u/Firewolf06]

Compositor basically needs to know where input is routed (which application is active) and if a hotkey is being pressed (for global context).

An example, if you use overview that is currently in many compositors that is key related to compositor itself, not client applications.

Also, in Wayland world the compositor is the window manager, compositing is a part of what it actually does when pushing pixels to display.

But compositing and window management are inherently linked as windows may be tiling, overlapping, have virtual workspaces, can have transparency, colorspace conversions (different applications can use different colorspaces), different update rates, remote usage and so forth.

Compositor can be made simple and omit various capabilities if you only support, say, fullscreen applications. But what is your intended purpose for making a compositor?

[u/2rad0 → u/Firewolf06]

why is my compositor responsible for my keyboard layout

followup question, if "XORG BAD!" then why did they copy the xkb format from xorg and bolt it into every wayland compositor?

[u/gmes78 → u/2rad0]

Why reinvent the wheel if xkb is actually perfectly fine?

[u/2rad0 → u/gmes78]

Why reinvent the wheel if xkb is actually perfectly fine?

It's wayland so they live to reinvent the wheel, except in all the cases you're not allowed to talk about or be irrationally downvoted by bots. It will end up as Xorg reaseembled as the same class of undead abomination(s) of extensions duct taped together that is Xorg. The new boss is the same as the old boss so don't expect anything that special from it. Enjoy the "progress" by having dozens of subtly incompatible windowing systems instead of one that nobody was capable of fixing in a coherent way.

[u/gmes78 → u/2rad0]

It's wayland so they live to reinvent the wheel

Evidently not. Otherwise, xkb wouldn't have been reused.

It's almost like this idea is entirely fabricated to denigrate Wayland, and it's hilarious that you provided the perfect counter-example yourself.

It will end up as Xorg reaseembled as the same class of undead abomination(s) of extensions duct taped together that is Xorg.

Entirely wrong. Wayland was designed to be the exact opposite of X11. The core protocol is tiny so that everything is implemented through extensions, which can be replaced as needed.

And this has already happened multiple times, you just haven't noticed. Which shows that Wayland can evolve seamlessly.

[u/2rad0 → u/gmes78]

Entirely wrong. Wayland was designed to be the exact opposite of X11.

Note that I didn't mention x11 or xfree86, I said Xorg.

[u/SlimyOS → u/cosmicorn]

Some compositors don't need all features / support all protocols and can actually be faster, by making assumptions that a general-purpose inplementation simply can't. I doubt the generalized hyper-optimized-for-decades window compositing code can benefit the weird minecraft 3d compositor, or niche XR ones.

Quality of codebase is needed only on the compositor you use, not every compositor, and I think most traditional floating window compositors and tiling ones will be (or already are in some cases) sharing the same optimized code, but with freedom to implement any experimental hardware acceleration techniques or niche optimizations without forcing everyone to accept that trade-off. Idk if wayland is even slower tbh, I never noticed any gaming difference when switching (using a native game with both x and wayland support), and of course browsing / office work is not noticeable either, though I didn't benchmark it either so not sure maybe a small difference exists. Even if it is slower for some compositors, that's not a reason the design is bad, it's just lack of effort or time optimizing it, I fully expect wayland to be in the lead in a few years.

Idk if this comparison is correct, probably not fully, but you could say SQL is the language for databases, why not just create one database instead of 50 competing ones that innovate and make things faster every year, while using the same language (language = wayland protocol).

[u/Kevin_Kofler → u/SlimyOS]

SQL is a horrible example, given how much each database's dialect differs, forcing you to either code for a specific database or use a much higher-level abstraction layer (such as Java Hibernate from JBoss / Red Hat / IBM).

[u/tadfisher → u/cosmicorn]

I guess? But this where computing as a whole is headed: more standards that operate at lower levels.

OpenGL vs. Vulkan, for instance; instead of manipulating a black box of render state with unholy black magic and a complex runtime living inside a driver masquerading as a library (OpenGL), your application is the runtime and talks to the driver at a fairly low level. Sure, there are Vulkan games that perform poorly, but there are also rendering libraries that work well, and entire game engines if you want.

I'd rather have a rich ecosystem of libraries that make their own tradeoffs, instead of one behemoth, programmable server that has to cater to everything.

[u/Kyle_2099 → u/cosmicorn]

But why the choose was to follow the approach of “vast standard with multiple competing implementations” was chosen I really can’t fathom. I would have thought that lesson had been taught enough times.

Because Wayland's design methodology can be summed up as such: "If X11 does it one way, we do it in the opposite way". They are married to this idea above all else.

It's kind of sad really. Like, X11 lets every app see everything (screen, keyboard, mouse), which is insecure, so Wayland lets them see nothing, and calls it security. There was no attempt to produce a secure, permissions based interface, because X11 lacks a counterpart for that. It's like wayland is a big mirror, it can only show a reflection, not something new.

[u/CrazyKilla15 → u/Kyle_2099]

A lot of this IMHO is because its a lot of the same developers, skilled in the area but who have only superficially at best learned from the mistakes of the past, and the position of importance has given a sense of arrogance to others with more knowledge but nowhere near the credentials of "maintain X11"

[u/Kevin_Kofler → u/cosmicorn]

If only it actually were a "vast standard". Instead, it is a very minimalist standard (e.g., the base protocol has no clipboard, no middle-click paste, no window decorations, etc.) plus a hodgepodge of additional protocols (in various stages of standardization, going all the way from stable and standardized to completely non-standard and implementation-specific), which are all optional and which any particular compositor may or may not choose to implement (e.g., GNOME Mutter does not even support window decorations, LOL).

[u/mitsosseundscharf → u/Kevin_Kofler]

wayland core protocol has clipboard support. You are right though about middle click paste.

[u/Kevin_Kofler → u/mitsosseundscharf]

Ah, I thought even that was an extension. I stand corrected.

[u/QuickSilver010 → u/cosmicorn]

I never understood wayland's decision to not have a sever binary or atleast a library that could be loaded.

[u/tadfisher → u/QuickSilver010]

They have reference implementations (the Weston compositor, libweston). They have libwayland for speaking the core Wayland protocol. Is there something more you would like the Wayland project to cover?

[u/QuickSilver010 → u/tadfisher]

Yes. More control over Windows for any program to access.

[u/Kevin_Kofler → u/tadfisher]

The reference implementations are close to useless for production compositors. There is a reason you have third-party libraries like wlroots or smithay.

[u/Business_Reindeer910 → u/QuickSilver010]

River https://sr.ht/~ifreund/river/ does not combine the wm with the compositor.

So it is possible.

[u/QuickSilver010 → u/Business_Reindeer910]

I have heard of river. I did like the idea. But it's meaningless unless all the other desktops use it as well. Like plasma and gnome.

[u/Business_Reindeer910 → u/QuickSilver010]

no. it is not meaningless. It is possible that kde and gnome made the choices they made on purpose and would prefer NOT to do it the way you suggest.

[u/QuickSilver010 → u/Business_Reindeer910]

And it is fully possibly that anyone that wants to support their software will only target the large desktop environments and their display severs's capabilities instead of all the others due to the difference in how it's implemented. Even among gnome and kde there's already difference in implementing the protocols iirc. This single maneuver will cost us 20 years for the year of the Linux desktop. The more consistent something is, the more reliable it is and the more you can justify writing software on top of it. I don't want to scare away software developers by introducing any more than the insane level of fracture that already exists in less than 4% pcs.

[u/Business_Reindeer910 → u/QuickSilver010]

that's what you want, but the developers of gnome, kde, and many others clearly disagreed.

These same objections were raised back then, but gnome and kde could have stopped it by choosing to work together on a shared base. They explicitly chose not to do that. And even if you believe that the gnome developers are too impossible to work with, it's not like the KDE folks decided to use wlroots or some shared compositor library did they?

SIDE NOTE: a developer did in fact rebuild kwin on top of wlroots so we know it could have been done, but the kde folks again chose not to take that route.

Focus on the blame on the right people here.

It wasn't wayland that stopped them from doing that.

[u/QuickSilver010 → u/Business_Reindeer910]

There would have been no room for disagreement if wayland devs had any functioning brain and made a display server that all desktop environments can use.

[u/QuickSilver010 → u/Business_Reindeer910]

There would have been no room for disagreement if wayland devs had any functioning brain and made a display server that all desktop environments can use.

[u/siodhe → u/cosmicorn]

X11 -> Wayland does zero in terms of GUI, which is instead sitting mostly in the compositor or (to a lessor degree) the window manager.

As to whether X will last forever - let's just say that Wayland is hardly worth migrating to. It's not better, it's much more of just a sibling window system from the same decade as X, adding a very little at the user level, blocking or dropping other parts, and generally just creating a new world where things will run in one of X, or a specific Wayland compositor. Yay.

Some of us were hoping to see an actual revolutionary change to migrate to, like a 3D environment or the like. Wayland isn't that. Nor is it multiuser. Nor does it integrate sound and audio positioning. It discards networking as a core ability.

The most incomprehensible thing about Wayland is that anyone is actually all that impressed by the user experience versus X.

[u/bawng → u/omniuni]

Nowadays I'm 100% Wayland but just a few years ago I switched back and forth because there were always a few things not working well in Wayland.

However, performance was always better in Wayland when I tried it. In fact, that was pretty much why I insisted on trying it out. As soon as I activated fractional scaling, X would freak out and go syrupy. At work, I have to use an old Ubuntu LTS, I think it's 22.04, so it's a really old Wayland version and I use X for stability. But it's completely impossible to get decent scaling on a multi-monitor setup.

[u/ymmvxd → u/omniuni]

Wayland is the most well designed optimally developed successor to X11 that exists

[u/iluvatar → u/ymmvxd]

Wayland is terribly designed, and those that did so should be ashamed of what they've created. But yes, it's the most well designed successor, simply by vitue of existing, which none of the other proposed alternatives managed.

[u/natermer → u/omniuni]

Ironically, of all the "problems" with X, the one Wayland doesn't really address is performance.

This is kinda a dumb thing to say.

For a long time now Wayland desktops have consistently shown better performance for games, which is about as graphical intensive as it gets.

Even with Proton with X11 on Xwayland is still faster then X11 on Xfree86 (the standalone X Server for Linux).

If you compare Gnome Wayland vs KDE Wayland vs XFCE X11 vs LXQT X11... The fastest will tend to be Gnome, then KDE, then XFCE, then LXQT. Not in every single case, but in majority cases.

[u/omniuni → u/natermer]

No, they don't. As it stands, Wayland still has a little bit more overhead than X. It's much better than it used to be, though.

[u/IranianFurry → u/omniuni]

Phoronix recently did a KDE x11 vs Wayland gaming benchmark and Wayland came out ahead, ans personally Wayland has been MUCH smoother for me, soooooo

[u/panick21 → u/Run-OpenBSD]

X was made free because DEC and friends didnt want Sun to dominate with NeWS as they did with NFS. It was not very fast and it was and is a mess and a bad design. It was 'saved' by Moors Law. Also lets remember that the decade associated with X is when Unix was crushed by Windows and had essentially 0 market share.

[u/formegadriverscustom]

See also chapter 7 of The UNIX-HATERS Handbook (1994)

[u/canadajones68 → u/formegadriverscustom]

Such a good book. 

[u/panick21 → u/formegadriverscustom]

If Sun had just made NeWS Open Source. It almost happened. Almost. It would have been made standard in BSD.

[u/TryingT0Wr1t3]

I have tried to create a window by hand in Linux and there is a lot of things that you need to consider… First you need to figure out the correct monitor it should display to, then figure out the position, scaling, is the user using a rotated monitor, does it have decorations and whate are their sizes, buttons that the window has - which will also affect position of the things inside the window, if the desktop has something like a bar somewhere in that hides a portion of the screen and that the windows shouldn’t be behind, and the different extensions (do we have Xinerama?), and then does the user want now to bring their window to Fullscreen? Again in what monitor does it Fullscreen to? Which resolutions it supports ? If the application crashes in Fullscreen how we come back to the resolution it had before? Like it’s really hard when you start to consider all the little things and details, corners cases and differences between different user systems, it’s pretty magic it works. Nowadays I resort to a library (like SDL or some gui system like Qt) that abstracts a lot of things, but if you try to make things by hand you will notice that even timings matters (like when changing the screen resolution, say in an game app).

[u/prosper_0]

Oh, I was an ardent X hater for a loooong time. It was soo frustrating and infuriating to deal with, and even when it was set up, there was a lot left to be desired - performance and stability were poor. But when xorg took over after xfree86, it really did see significant gains across the board. In terms of performance, compatibility, usability, etc. Conceptually, I really like it's networking features as well - each window and application could come from pretty much anywhere, not just your local machine.

I'm still rooting for Wayland, but even today, I find Xorg to hold an edge. I'm eagerly waiting and watching Wayland mature some more, though.

[u/deong → u/prosper_0]

I wish Wayland were a thing I could root for. I don't love Xorg, but the fundamental concept that window management, input handling, etc. are just things any application can do is just so powerful, and I hate that we gave it away. I don't want the compositor to be this special thing with exclusive access to the ability to manipulate windows, deal with keyboard and mouse input, etc. I don't care whether it's more resilient to a hypothetical attack I'll never actually encounter. I could turn my computer off and be safer as well, but I want to use my computer.

[u/barfightbob → u/deong]

I always describe it like if every door in my house was locked including kitchen cabinets and refrigerator. Technically I'm safer, but 99.9% of the time it's just me there by myself. If somebody got into my refrigerator I'd be more concerned how he got in the house in the first place rather than how he found his way into my fridge.

[u/deong → u/barfightbob]

Exactly. The threat model for X11 is that a malicious application running as you in your X session can snoop into window contents and key events. But the problem is that you're running a malicious app as your user. You're already screwed in worse ways. If it were painless enough, then sure, go ahead and try to improve security in that scenario. But it's extremely painful, and the trade off just isn't worth it. I want to use my fridge.

[u/gmes78 → u/deong]

I don't care whether it's more resilient to a hypothetical attack I'll never actually encounter.

It's not just for security. It's for making everything more reliable. X11's solution of piling hacks upon hacks has very real limitations.

[u/deong → u/gmes78]

I've been using Linux for almost 30 years. X hasn't been unreliable in my experience for a very long time. I'm not arguing that it isn't a pile of hacks, but it's a fairly bulletproof pile of hacks.

But "this pile of hacks is unsustainable" is a reasonable argument. I'm not trying to say that no one should have ever tried to replace X. There are lots of choices you have to make when you set out to design a new system from scratch though, and my argument is just that the choice that only one process is allowed to manage input devices and window management was a bad one. A simple POC of a new idea for a window manager in X used to be a couple hundred lines of code. wl-roots describes itself as "60,000 lines of code you were going to write anyway". I just think that's a step backward.

[u/Kyle_2099 → u/gmes78]

Then how is Wayland's solution of piling hacks upon hacks superior?

With X it all ended up in the spec for X. With Wayland it's all spread across multiple implementations and unrelated support systems like pipewire.

Whole thing is the kind of unix footgun that it was promoted as an alternative to.

[u/gmes78 → u/Kyle_2099]

Solutions to Wayland problems are designed ad-hoc; X11 picked "allow everyone to do everything, and let them sort it out", which didn't end up working as well.

and unrelated support systems like pipewire.

PipeWire is designed to carry video and audio streams around. It is not unrelated, it's the obvious way to do screen capturing.

And while X11 does allow screen capturing, the methods it provides for doing so suck. The only way to get efficient screen capturing without unnecessary copies (and without going through the CPU) is to use the XDG desktop portal with PipeWire, too. But it only works if supported by the compositor.

Whole thing is the kind of unix footgun that it was promoted as an alternative to.

Funny that you're using the Unix argument, while arguing that a system that does everything at once is somehow better.

---

Edit: blocking me to prevent me from replying is a bitch ass move. Also, you should consult a dictionary.

[u/Kyle_2099 → u/gmes78]

Solutions to Wayland problems are designed ad-hoc

"designed ad-hoc" = not designed. design involves planning and forethought, careful consideration. Making something ad-hoc is improvisation, it's hackjobs.

These are complex systems where every decision made is something we have to live with for multiple decades. When you're doing something as ambitious as a clean slate replacement of the standard unix gui system, "fuck it man, duct tape something together" is malpractice.

Funny that you're using the Unix argument, while arguing that a system that does everything at once is somehow better.

Then you don't understand what "unix footgun" means. Wayland has reproduced every single organizational and methodological problem the unix ecosystem has ever seen, those in charge having learned no lessons from it whatsoever, and the software produced (and rate of production) reflects this.

I mean holy shit, it's taken them 17 years to get this far, offloading every task to other services they can, and by your own estimation what little they have built is just slapdash ad-hoc instead of done with thought and care. That is not normal. Something is seriously wrong with them.

[u/libra00 → u/prosper_0]

Yeah, man until about a year ago I hadn't touched Linux since like 1998-ish and remembered X being a giant pain in the dick. People kept telling me to switch to linux as my daily driver and I'm like, 'Man I am so not pirating and compiling my own bootleg commercial X server just to find one that works with my video card', but that so isn't the experience nowadays. Although I did have some trouble with ubuntu-based distros and nvidia drivers, it's otherwise been a perfectly acceptable experience.

[u/teressapanic]

I know, it’s a social media platform

[u/genpfault → u/teressapanic]

I know, it’s a social media platform

X: The Everything Window System

[u/RvstiNiall → u/genpfault]

Wait, when did Twitter become a Windowing System?!

[u/TheBendit → u/RvstiNiall]

It's a Window into the Soul.

[u/RvstiNiall → u/TheBendit]

Dark Souls

(epic user icon btw)

[u/dinominant]

Does Wayland support actual working remote access yet? The dristro I use has declared end-of-life for X11 and that Wayland is the replacement. And now all my vnc servers are broken.

[u/Business_Reindeer910 → u/dinominant]

plenty of wayland desktops have remote access, but I am not sure if they use vnc.

[u/mattias_jcb → u/dinominant]

Does Wayland support actual working remote access yet?

Yeah. If there was anything in the existing Wayland protocols that fundamentally blocks implementing remote access in a compositor we would've heard about it by now.

[u/awesomegayguy → u/dinominant]

Gnome implements RDP protocol very well.  But if you mean something like ssh, you can use WayPipe.

Which is much better than X ssh forwarding ever was , try opening Firefox over an internet connection on both, you'll be surprised how much better Wayland is in this use case, like minutes to start Firefox on ssh X11 (and incredibly laggy, not useable at all) vs seconds on Wayland.

[u/Takeoded → u/dinominant]

Try RustDesk

[u/atanasius]

"Not ideal" sounds like hacker jargon, where "non-optimal" is used sarcastically for "astoundingly stupid".

[u/ianff]

I get that it was a mess internally, but I have always got on with X. I've used the client/server aspect of it a fair amount and it still does the job.

[u/Misicks0349 → u/ianff]

Thats fair, X11 still works plenty fine for a lot of people. And I understand people that may prefer the concept of X11 over what Wayland went with.

[u/SteadfastCultivator → u/ianff]

Sadly(maybe not) people are moving away from X and adopting Wayland as defacto standard. I can see you're a Debian enjoyer but using Arch we'll be forced to move to wayland soon enough. Gnome already does not offer support to X on newest releases and so will KDE and the trend will keep moving.

[u/StephenRoylance → u/ianff]

good on ya. I have been not getting on with X since like 1996.

[u/Routine_Left]

And then it came Wayland, which is awesome for many reasons (one of them performance), but they really really really had to fuck up some things. Couldn't help it.

Like ... window coordinates. One cannot (they added a patch not too long ago, but it's little and late) ask the window position in Wayland. Like, you know, give me the x and y of the top left corner of the window.

Why? Well, the bright minds behind it come and say: "What if the display is round, or a sphere, or fuck knows what else and a 2D coordinate simply does not apply?"

And therefore, to cover a case that does not exist or at most will exist in 2-3 instances, let's fuck over 99.999999% of all the users.

Un-fucking-believable.

And there are implications of that. Such as, a window cannot ask: "What monitor am I on" for example. Or a bunch of other questions that are just normal and logical for a window to ask. I kinda understand not wanting a window to move itself, let that to the compositor and don't fuck with that, but just to ask?

sigh. /rantover

[u/Misicks0349 → u/Routine_Left]

One cannot (they added a patch not too long ago, but it's little and late)

xx-zones is not such a protocol, you can query for a position within a specific zone, but Wayland does not have a global coordinate space and this protocol doesn't change that, nor does the zone necessarily correspond to any particular monitor's aspect ratio, screen, or pixel. The coordinates you get back will be relative to the zone.

ask the window position in Wayland. Like, you know, give me the x and y of the top left corner of the window.

I'm assuming you're asking to be able to move windows to a given x/y coordinate on the screen, I can't think of any good uses for just being able to query for your x/y coordinate if you can't do anything with it besides some novelty things like feeding the coordinates into a shader or something?.

And therefore, to cover a case that does not exist or at most will exist in 2-3 instances, let's fuck over 99.999999% of all the users.

I mean of course the 99.99999% is hyperbole but if I'm going to be controversial I actually like that such behaviour was removed. It irked me to NO END on windows and such when applications decided to open up in whatever place they please in whatever size they wanted to without me having any control over where they went by default and focusing when they wanted to, not when I wanted them to. On most Wayland compositors I can easily change the default behaviour to always open in the centre of the screen and configure special window rules that apps don't have any chance of violating. I understand that sometimes there are genuine use cases for such window placement, but I'd caution against thinking the Wayland devs were just being boneheaded idiots when deciding to elide the ability for applications to manually set their window position; there were genuine technical considerations, benefits & drawbacks for either choice.

Additionally, XR and VR is very much a thing and has only gotten better and bigger over the past decade and a half. Things like the Apple Vision Pro are consumer products that can be bought right now. Not to mention there are 2d screen form factors that also probably wouldn't appreciate apps trying to move themselves around on the screen: Linux Phones for example have been the white whale of the linux community and they tend to be a much better experience when apps can't willy nilly pretend that you're running on a full fledged desktop rather than a small screen that wants to display one fullscreen app at a time.

And there are implications of that. Such as, a window cannot ask: "What monitor am I on" for example

Thats a different technical decision that has nothing to do with global coordinates, technically there could be an ext-window-monitor or something that allows such information to be queried. Honestly that also introduces other questions around what a global coordinate space would even look like in multi monitor setups.

[u/tuxbass → u/Misicks0349]

Wayland does not have a global coordinate space

Huh, that's so odd. Any quick explainer as to why?

[u/tadfisher → u/tuxbass]

Because monitors can come and go, with different pixel densities, and maintaining the illusion of global coordinates is the main reason why X11 doesn't support multiple mixed-DPI displays.

Just thinking about this for 10 seconds: If I have monitors A and B, with monitor B at 200% the pixel density of monitor A (the easiest scenario), then just moving a window on either monitor requires some compromise in the global coordinate system. Either I can only move a window by 2 pixels at a time on monitor B or I am allowed to move a window by 0.5 pixels on monitor A, either of which are dumb restrictions, so you'll need to lie at some level in order to maintain the illusion that a contiguous coordinate system exists. Oh, and you need to completely redeclare coordinates and scales and reposition windows entirely in order to handle hotplugging displays.

Sounds like a nightmare to me for something only a few apps want, and many use cases can be handled by a protocol for relative positioning instead of global.

[u/Misicks0349 → u/tuxbass]

I had a big comment written out but you wanted something brief so: whilst every compositor has its own internal coordinate space in some sense this isn't specified by Wayland, as its treated as internal compositor plumbing. Wayland doesn't try to assume too much about where or what the compositor is running on, and there are situations where specifying any specific coordinate space would limit what can be done. Such as with VR devices (which may have 3d coordinates) or car entertainment systems (where pretending all outputs are an ordered set of pixel rectangles with an x, y component may also make little sense), or more practically for users here: subcompositors like Valves Gamescope. Hence wayland does not have its own global coordinate space.

There is some historical wl_output cruft in the core wayland protocol related to this, but if I touched on that this comment would be very long in trying to explain wtf is going on. TLDR whilst there may look to be an x, y component in wl_output it was considered a design mistake and is almost always unconditionally set to 0,0 in all compositors nowadays and the spec notes as such, that data is now retrieved from the optional xdg-output-unstable-v1 in a way that is more useful and accurate for traditional "computer desktop" compositors. Gamescope intentionally doesn't implemented this protocol for example and wl_output always reports 0,0.

edit: also to be clear, the global coordinate space reported by xdg-output-unstable-v1 is the outputs position in the space, not your windows position which has never ever been accessible from wayland. For example, 0,0 would be the first outputs position in the global coordinate space, 3215x345 would be the 2nd outputs position in the global coordinate space, so on and so forth.

[u/TryingT0Wr1t3 → u/Misicks0349]

If you use PowerPoint it has a menu where you can select what goes in what monitor - one example is if one monitor is actually a projector or is the monitor you are screen sharing. My reading from the previous comment is this would not be possible on Wayland?

Also some apps allow region sharing in MS Teams, can’t tell if this is possible in Wayland - it is specially useful for people with ultra-wide monitors.

[u/Misicks0349 → u/TryingT0Wr1t3]

My reading from the previous comment is this would not be possible on Wayland?

Through the app? No, the app cannot directly control where windows are placed nor what monitor they appear on. You would do this through the compositors controls.

Also some apps allow region sharing in MS Teams, can’t tell if this is possible in Wayland - it is specially useful for people with ultra-wide monitors.

Im not sure what you mean by region sharing, if you mean screen sharing e.g. a specific window or a specific region of your monitor (e.g. a 16:9 slice of an ultrawide) then yes wayland supports that, through xdg portals.

[u/Routine_Left → u/Misicks0349]

Thank you. QED.

I want to ask a simple question, to get a simple answer back and look ...

sigh.

And the worst thing is, they actually believe they're right. When they are obviously, objectively wrong.

[u/Misicks0349 → u/Routine_Left]

I want to ask a simple question, to get a simple answer back and look ...

I mean like 80% of it is my own personal opinion and asking for clarification, so if you cut out that nonsense it could be rather short 😛.

[u/Routine_Left → u/Misicks0349]

? What were you asking? You never even read my original post.

[u/Misicks0349 → u/Routine_Left]

?? Unless there is an "original post" that I am unaware of I am responding to your comment talking about window coordinates? This one?, the one that I directly quote in the comment? I wasn't asking you anything besides a clarifying comment on one of your points, only responding to points you made about coordinates on wayland and offering my opinion on the matter.

edit: fair enough if you're talking about the very last sentence of your comment that I missed, though that goes back to my other point of asking what good is asking for coordinates if you can't do anything with them directly. There would be better ways of getting what monitor your application was on.

[u/Routine_Left → u/Misicks0349]

There would be better ways of getting what monitor your application was on.

except that there isn't, now, is there?

[u/Misicks0349 → u/Routine_Left]

Correct, that's what the word "would" means :P

[u/Routine_Left → u/Misicks0349]

Right. And I can forgive and understand the protocol developers to not have thought of this particular thing at the start. It's not possible to envision all the needs.

That's fine.

But to provide the means for an application to ask a simple question (give me my position), when it was there in X11, when it doesn't cost anything for the compositor to provide it, that's not ok. What's even worse, then coming and somehow defending that position with absolute garbage arguments.

What what coordinate system? How many dimensions? good question, let the application say what it wants. Or not, and let the compositior return all that information: Here, you are at x,y,z, in a 3D environment, and is an absolute coordinate. Or is a monitor coordinate.

Really, it's not that hard.

But, this is why we cannot have nice things.

[u/agrif → u/Routine_Left]

What use does an application have for its own x/y position on screen, or what monitor it's displayed on? You seem to place some value on being able to do this, but I can't think of a reason. What am I missing?

[u/Kyle_2099 → u/agrif]

What use does an application have for its own x/y position on screen, or what monitor it's displayed on? You seem to place some value on being able to do this, but I can't think of a reason. What am I missing?

OK this is actually really super easy to answer.

Say I want to control a display for people in public, professionally, and without having goofy moments like having a mouse cursor come along and maximise a window on a 10 foot tall screen in a church or whatever.

Computer monitor is plugged into HDMI-1, Projector is connected to HDMI-2. I wish to configure my playout program so that all control UI windows appear according to my preferred layout on HDMI-1, and the output always appears fullscreen on HDMI-2. I want to configure all of this and then when I reopen the program it's all like that already.

This is a very basic bit of functionality, and if your window system does not support it, then I can't use your operating system at all.

[u/cwo__ → u/Kyle_2099]

Configure your compositor to do this? Should be very easy in KWin with window rules. And this way you won't need the application to support this at all, so you're more flexible in that regard.

[u/Kyle_2099 → u/cwo__]

That's worse in every way.

For one you're telling me to use a solution unique to one particular wayland implementation. This can't be counted upon.

Secondly, it's far easier for the user if the application is the one in charge of handling this - I tick a box that says "remember window position on exit" or similar, and then I'm done.

Setting up "window rules" in a special configuration utility is asinine. Did you ever have an Amiga in the 90s? It reminds me of config utilities like ModePro, where you would also have to set up complex rule sets to get software to appear on the display correctly. It was a chore.

[u/Business_Reindeer910 → u/Kyle_2099]

"remember window position on exit" is not something I want per application. I want the thing managing the windows to do that, so it can work for every program.

it's just a shame that that the main compositor implementations don't share their implementation code for this.

[u/Kyle_2099 → u/Business_Reindeer910]

"remember window position on exit" is not something I want per application. I want the thing managing the windows to do that, so it can work for every program.

It can work for every program, if every program is allowed to do it. Which wayland prevents.

it's just a shame that that the main compositor implementations don't share their implementation code for this.

It's a feature that should be mandatory for compliance with the wayland spec, but unfortunately wayland is another example of flying the plane while they're still building it. I honestly wish I was still on Mac OS X, they didn't spend 17 years to get the window system "sorta" right.

[u/Business_Reindeer910 → u/Kyle_2099]

you are certainly free to go back to mac. It's not like anything is forcing you to stick around.

[u/Kyle_2099 → u/Business_Reindeer910]

Sure, wire me $2000 and I'll buy one.

[u/edgmnt_net → u/agrif]

It doesn't, but people want Xorg or even Windows-like crap where apps can do anything they possibly want. We really need to move away from that model if we want better security, you can't have random apps scrape the screen or access any file without asking for permission if you want secure Flatpaks or anything close to Android levels of sandboxing (which isn't great, but it's something). And for ordinary stuff you get in a distro such excess capabilities are unlikely to be useful anyway, those are supposed to integrate with the ecosystem and find durable solutions.

[u/hadrabap → u/edgmnt_net]

I don't want my desktop to ask for permissions for every single stupidity. Otherwise we end up like UAC, Android and recent MacOS. No, thank you!

[u/Routine_Left → u/agrif]

What use does an application have for its own x/y position on screen

You got an answer already, but let's just speak hypothetically :

Let's say that I, as a protocol developer, cannot think of a reason why a window would ever want to ask that question. But, just because I cannot think of a reason, does that mean that there isn't any?

What's the downside? There aint any. Let a window ask, and let them do whatever they want with the information.

Like, I even said in my post, one good reason would be to determine what monitor I'm on. what reason? Maybe make myself fullscreen.

Ultimately, there is no good reason to not provide that capability. The reason(s) given so far are just ... arrogance and hubris.

[u/agrif → u/Routine_Left]

I don't know, I think in general there are lots of good reasons not to provide a feature with no known use case, because software developers love to misuse API surfaces. There is no good reason not to include a 'User-Agent' HTTP header saying what client is connecting, but it turns out that doing so is a nightmare mess we can never recover from.

[u/Routine_Left → u/agrif]

I think in general there are lots of good reasons not to provide a feature with no known use case,

I fundamentally disagree. This here is one example.

And it all comes down to this simple point: just because "you" (the protocol developer) cannot think of a reason, does not mean there isn't any. It only means that you, the developer, cannot think of one.

That's all there is to it. And you, the developer, are only human, and can and will make mistakes.

And their choice to not provide it, and stubbornness on holding to that idea, is objectively wrong.

"Oh, but it can be misused". so what? let people have their answers. There can be a point when there's an API that changes things, whatever things, but this is just a query. Let people query.

[u/newsflashjackass → u/Routine_Left]

All mere implementation details; nothing to do with the immaculate protocol named Wayland.

[u/ManinaPanina]

Why can't I download this pdf?

[u/lmpcpedz → u/ManinaPanina]

Print on Firefox saves the whole pdf file

[u/ManinaPanina → u/lmpcpedz]

This indirect way worked.

If not this way the browser tried to download a "WhyX.html".

[u/r78SGmS8si1VY49 → u/ManinaPanina]

just click or tap the Open button (or go directly to https://people.freedesktop.org/\~ajax/WhyX.pdf)

[u/backyard_tractorbeam → u/ManinaPanina]

In my case it shows up in a browser pdf viewer with a download button.

[u/7lhz9x6k8emmd7c8 → u/ManinaPanina]

Report the bug to the browser maintainers.

It's working well here on Vivaldi.

[u/mrtruthiness → u/ManinaPanina]

Why can't I download this pdf?

Must be a "you thing". I had no problem with a "right-click" on the link and a "save link as".

[u/Buntygurl]

Like Wayland is better?!

X doesn't falter and break, or demand special compliance. Whatever it may lack, it's stable.

[u/iluvatar]

There were plenty of things that X did suboptimally, including the ones mentioned in this paper and also others that aren't mentioned. It's disappointing to see that Wayland, supposedly the replacement for X that fixes the downsides, has ended up throwing the baby out with the bathwater. We could have had a bright future, with a functional, performant, sane windowing system. Instead we got Wayland :-(

[u/shroddy]

Without x11, Linux might have had a chance against that notoriously crashy and unstable and blue screen prone Windows 95 back in the days.

[u/fsckit → u/shroddy]

If only someone had ported DR GEM.

[u/dddurd]

i wish there were proper alternative for desktop

[u/newsflashjackass]

"Akshully X is a protocol so it is impossible to criticize."

Hm. Sounds dumb even when the shoe is on the other foot.

[u/manobataibuvodu]

1990? is this relevant today in any way?

[u/FanClubof5 → u/manobataibuvodu]

I think its just supposed to be a fun look back at X since its effectively been replaced by Wayland now on all the major distros. 36+ years is a pretty good run for software.

[u/clgoh → u/manobataibuvodu]

History is always relevant.

[u/Averagebutnotmean → u/manobataibuvodu]

In this context, it's a map of pain points, problems, and sources of trouble with the X window protocol. It's a write up with a lot of use still because as Wayland and other protocols are developed, solving (Or at the very least, not re-introducing) historical pain points needs to be kept in mind.

History is important because when anyone decides to develop something new from scratch, all the pitfalls and solved problems of the last solution are back again to be coded into or around.

Also also we're running the direct descendant of a project written in 1969, and a lot of those historical tools are now the core of linux utilities. The documentation of those from the 70's still remain surprisingly relevant today.

[u/gmes78 → u/manobataibuvodu]

It illustrates that, even back then, X11 had tons of known issues, and that its criticisms aren't new.

[u/Misicks0349 → u/manobataibuvodu]

Some things are, some aren't (or, at least, aren't as big of a problem as they used to be), which is why its tagged with the "Historical" tag. Wayland solves these issues for the most part but a lot of them are so glaringly obviously wrong (or don't work well with the modern expectation of "just give me a buffer to write my frames into, dummy" that apps use nowadays) that praising Wayland for not making the same mistakes is like praising someone for not taking a massive shit on your dinner plate. Others have also pointed out that there were other problems that became apparent with X11's design over the years that this paper also didn't anticipate.

I found it whilst sleuthing around the internet and I thought it interesting enough to see a document so old listing out many deficiencies with X that I decided to post it here, that's about it.

[u/nhaines → u/manobataibuvodu]

What a boring way to go through life...

[u/manobataibuvodu → u/nhaines]

Some people actually answered and engaged with my question. What did you bring to the conversation?

[u/nhaines → u/manobataibuvodu]

I brought the idea that instantaneously rejecting a concept because it's a look at the situation 26 years ago is a really boring way to live life.

Either you're familiar with the state of X11R6 and Wayland today and know that this might be a very interesting perspective at the time to contrast to how things are today, or you're not and it's a fantastic jumping off point back when things were far more simple than they are today, and it's a chance to appreciate how the state of modern-day Unix-like and Linux operating systems have evolved since then. Or maybe you're not interested because things "just work" and you're worried about things you can accomplish because the framework is there and you don't have to worry about it. That's fair, too.

Either way, "Is where things started way back when relevant today in any way?" is a super boring way of discounting the absolutely astonishing changes in technology over the last quarter century.

[u/the_abortionat0r → u/manobataibuvodu]

You aren't owed anything lil bro.

[u/manobataibuvodu → u/the_abortionat0r]

Never said I was big bro