GNOME (and many others) have spent years telling anyone who has issues with Wayland that lead them to run an X session to report bugs, and has put a lot of effort into fixing those bugs. This seems like a reasonable next step.
> This plan seems to The Reg's FOSS Desk to be strong-arming people into adopting Wayland.
Or, more reasonably, to maintain less code for alternate paths in favor of fixing the issues that lead people to use those alternate paths.
Wayland has bugs. X has bugs. Fixes to one largely don't help users of the other. Every bit of effort spent fixing a bug in X to help the fraction of users still using it is effort that could have gone into fixing the bugs in Wayland that leave people using X in the first place. A project taking a step like this allows it to consolidate those efforts.
Yup. I think consumers of FOSS rarely understand the amount of effort that goes into maintaining code, whether that is keeping the test infrastructure up to date, fixing bugs, or adding new features.
In many cases, a large codebase like GNOME will undoubtedly have huge swaths of unmaintained code that doesn't have good test coverage and corresponds to rarely used features of the software. It also becomes a frustrating game of whack-a-mole when attempting to fix bugs in software with inadequate test coverage.
Another infrequently acknowledged point: writing tests isn't simple, it requires you to have thorough understanding of all the moving parts involved. If the current maintainers do not understand the architecture in some obscure corner of the software, then there is a significant upfront cost to expanding existing tests around that code -- time that can be spent improving frequently used parts of the software.
When nobody steps up for maintenance despite welcoming patches and calling for new maintainers, there is simply no reasonable option besides "remove this unmaintained source of bugs that none of the maintainers know how to properly test"
Exactly. Given the nature of Open Source, anyone is free to fork something and say "I'm going to keep maintaining the old thing forever". But that's often not feasible solely with the handful of people and energy of those people interested in a given older technology, especially in a world in which people expect pieces of the ecosystem to cooperate and interoperate with each other.
So, instead, the standard tactics are to 1) push people and projects to maintain the old thing for them as long as possible, 2) treat any new technology that doesn't give you free support as a threat, and respond to it with fear, disparaging and attacking the people and projects who are no longer willing to maintain the old thing forever, trying to rally others to pressure them, and 3) disparage and attack technologies that require integration/cooperation between projects, because it raises the bar for the amount of maintenance effort expected.
New projects should decide up front, and document very clearly, whether they're willing to offer substantial amounts of maintenance effort on behalf of older or more niche technologies.
> New projects should decide up front, and document very clearly, whether they're willing to offer substantial amounts of maintenance effort on behalf of older or more niche technologies.
Not just new projects. Existing projects can do with a clearer roadmap in my opinion. "Gnome 48 will drop X11" is easier to communicate than a merge request titled "session: Remove x11 session targets".
When did they do that? All I can find is the Python foundation protecting their trademark. Someone launched "Python 2.8" without any affiliation to the Python Foundation, that's a silly move. Surely everyone in open source learned from the Iceweasel debacle.
Something called Tauthon is still being patched every few months for people who can't let go of Python 2.7, though I don't see many contributors to that fork.
> without any affiliation to the Python Foundation
Sorry, no dice. The Python team said for years as the 2 to 3 rollout grew increasingly catastrophic "If you wan't to keep Python 2 all you have to do is maintain it" and then threatened to sue the guy who called their bluff. It was a real low point in free software.
Clicking on the GitHub repo it seems that in fact the project making unauthorised use of the name “Python 2.8” was the one that ended up changing its name to Tauthon. Neat!
My impression though is that for enough people, the wayland code doesn't exist (see this comment from a GIMP dev on the aforementioned MRs for example: https://gitlab.gnome.org/GNOME/gnome-session/-/merge_request...). It's one thing to choose between different buggy behaviour, it's another when the new way does not allow you to do your job.
> Every bit of effort spent fixing a bug in X to help the fraction of users still using it is effort that could have gone into fixing the bugs in Wayland that leave people using X in the first place.
What fraction is that? I thought X still had the larger user share.
If the article is still correct, and Wayland doesn't work with the Nvidia binary drivers then that's a hard blocker for at least myself. :/
That being said, I'm still using Ubuntu 20.04 LTS on my desktop as I prefer stable systems. That way I can put time into the things I'm interested in more. :)
So, as long as it all works nicely by the time I need to change from Ubuntu 20.04, then I likely won't particularly care if it's wayland or X underneath.
It works perfectly fine on Debian testing (in fact the X session developed show-stopper bugs that forced me to use Wayland), so it should be on Ubuntu soon.
As someone who used to be a diehard Linux user and supporter, and then switched back to windows after about a decade, this thread is a good reminder of why I switched back. I've been hearing about the year of the Linux desktop for... Years... And yet here are people who suggest I should put up with an incomplete, partially broken display server, because they don't want to deal with maintenance of the old one. And in this thread, any complaint by real users who are missing features or have encountered bugs is met with a dismissal.
You know what? The equivalent of X11 in windows may be full of cruft, technical debt, poorly thought out / "unelegant" design decisions... But it fucking works. I'm sorry, but I have other things to do than dealing with the constant churn of Linux desktop software.
I remember a decade ago when everyone was supposed to switch to pulseaudio, it was the greatest thing since sliced bread, its design was solid and future proof. Migrating from alsa did break everything and was a PITA. And alsa was still there! The fix for many problems was to configure something in the venerable alsamixer. Now apparently we need to migrate to pipewire. All I know is that upgrading broke my rpi4. I don't care about the software, I just want my htpc to play a video with sound when I get back from work. I still had to run alsamixer and flip a few knobs to get it to work again. This is madness.
> You know what? The equivalent of X11 in windows may be full of cruft, technical debt, poorly thought out / "unelegant" design decisions... But it fucking works. I'm sorry, but I have other things to do than dealing with the constant churn of Linux desktop software.
It's funny because it's the opposite.
On Windows, you can install and update the graphics drivers without restarting, and it can ever seamlessly recover from a GPU crash.
On Linux, you need to update the whole kernel, and if the GPU or the driver crashes, you'll kernel panic.
On the compositor side, on Windows you can easily have multimonitor setups with different fractional DPIs, different refresh rates (including variable refresh rate), mix of HDR and SDR, applications without vsync and so on. On linux, even single monitor HDR is unsupported.
X11 also just "fucking works", and this is article is about a proposal to remove it from GNOME.
GNOME is the DE equivalent of North Korea. It's like hearing about North Korea contemplating removing the right to wear clothes and going, "I left Earth a decade ago, and this is a good reminder of why I haven't come back." :p
X11 will still be supported by sane (desktop) DEs for as long as Linux will still be in use, is my guess. (Just like window minimization and non-rounded corners and system trays and disabling composition and...)
> Now apparently we need to migrate to pipewire.
I don't even think I'm on pipewire. Using Arch, you can run anything you want; no ones forcing you to do anything. ;D
> X11 will still be supported by sane (desktop) DEs for as long as Linux will still be in use, is my guess. (Just like window minimization and non-rounded corners and system trays and disabling composition and...)
Not if they remove X from gtk+ too. That is the logical next step.
I am using wayland since 5 years and never looked back to X11. I think it is the right way and time to remove the old insecure X11 backend. GNOME should not be bloated with legacy stuff.
Your experience is not universal. On an intel cpu/gpu laptop, I have zero issues.
But on an AMD/Nvidia desktop it's unusable because it's buggy as all hell. It's endless glitches in dozens of applications. At first it appears fine and then you get subtle stuff like like letters not appearing in vscode when you type, OBS won't record etc.
I have experience with all three manufacturers. We deploy them at work and the integrated AMD GPUs work just as good as the Intel systems. However I can't say much about the discrete AMD GPUs or older hardware.
Just yesterday I changed one nvidia system to the proprietary Wayland driver and started gnome with a three monitor setup. Works like a charm.
- O proper screen recording support
- broken screen sharing
- No proper global keyboard shortcut
- No push to talk support
- Their developers are seriously crazy on their design decisions.
- Several problems with multiple screens
A proper refactor of X11 should have been the way to go and there should had been X12 with modern technologies
Both work perfectly here with pipewire installed. I can do screen recording, and share my screen in video meetings in Firefox.
> No proper global keyboard shortcut
System-wide keyboard shortcuts already work, through the desktop. The ability for an arbitrary application to request a global keybinding is in progress and expected to become available soon.
> No push to talk support
Completely valid; that's the near-future global keybinding support mentioned in the previous point.
> Several problems with multiple screens
Such as? Reported bug URLs?
For the record, there are other known issues with Wayland, and they're being worked on; nobody's claiming Wayland is perfect at this point, just that the solution is to fix it rather than assuming it's doomed because it doesn't do some specific thing.
> A proper refactor of X11 should have been the way to go and there should had been X12 with modern technologies
Wayland is X12; it's designed and endorsed by the folks who worked on X11.
So, basic functionality is still not there 15 years after release.
And I believe gnome still has that thing where if the UI lags, the cursor lags.
Windows DWM, WDDM architecture, and anything graphics related on Windows is superior in so many ways. They should have copied that instead of the mess that Wayland is, which was developed in a manner that is typical for so many free software: the developers think they know better than the users about what features they need or don't need
> So, basic functionality is still not there 15 years after release.
X11 didn't have what we currently consider "basic functionality" for decades after its release.
The design of X11 says that every application connected to your display is completely trusted, hence why it can grab any key (and thus be a keylogger if it wants to be). The design of Wayland starts with the premise that every application connecting to your display might not be completely trusted, and thus has to ask for a global key shortcut. That makes some things harder, requiring the design of a protocol for such requests. It also makes it possible to have sandboxed applications. That seems like a tradeoff worth making.
> The design of Wayland starts with the premise that every application connecting to your display might not be completely trusted,
What a strange premise... Do the wayland people have keylocks on all the rooms, drawers and cupboards on their houses?
Unix programs by default have access to all files in the user home. That's the main point of running programs after all: to edit your files. Letting these programs see all pixels in you screen does not seem that bad, does it?
If for some reason you want to run an untrusted application, use a container. But building your whole house around the "untrusted" premise sounds ridiculous.
> If for some reason you want to run an untrusted application, use a container. But building your whole house around the "untrusted" premise sounds ridiculous.
I guess we should do away with memory protection as well. Filesystem permissions? Bah, they can go too, after all, a computer is generally used by a single person right?
The reality is that many users use untrusted applications that don't have access to home, ergo Flatpak. There are plenty of reasons why the free for all security model for X11 isn't suitable. Besides, that ship has well and truly sailed - most of the X11 devs have been working on Wayland for the better part of a decade now.
It is not a strange premise. It is the security model that for example Android uses. Unix security model is dated, and it is good that steps are taken in this direction.
It has nothing to do with security and everything to do with hollowing out all generic functionality and passing it on to the compositor. In other words, the devs are lazy and went for a minimalist approach and now we all get to suffer.
> X11 didn't have what we currently consider "basic functionality" for decades after its release.
What's the relevance of this? You're position is that we should give up features we have for software that doesn't have them after 15 years of knowing they needed them.
No, my premise is that it takes time to develop features, and what's considered "basic" both changes over time and varies by person.
For instance, I would argue that "basic functionality" today, established by browsers and phones more than 15 years ago, is the ability to sandbox applications and not treat them as all-powerful. X still doesn't have that today. Wayland had that as a basic design premise from the beginning.
ctrl + alt + shift + R will record the screen on Gnome, it's built into the shell.
wf-recorder will do Wayland screen recording fromtthe she'll. I don't think anyone has bothered to implement Wayland screen recording in ffmpeg yet, maybe ask the ffmpeg mailing list to check if that's on the roadmap yet.
> [N]O proper screen recording support - broken screen sharing - No proper global keyboard shortcut - Several problems with multiple screens
I thing all these things work flawlessly in my KDE Wayland session.
By the way no more blinking and sound cut (my sound goes through HDMI) when rearranging screens.
I've been very late to make the switch (I did a few months ago because I always saw blocker issues with the wayland session), but now it is at a point it works better than on X11. I miss raising apps when they are called from another app (like calling Kate from the terminal) but I know this is coming soon.
In that sense they're even more at the mercy of packagers. There's nearly 400 million repositories on Github alone; the pain point is curating those into a coherent system.
It would be one of many in a long line of backward compatibility missteps they continue to make; and would help shore up my reasons for me to recommend other WMs, as well likely encouraging other developers to bring some of GNOME's good stuff elsewhere.
X can easily support per-display DPI -- clients just have to eschew the legacy global DPI setting. The Xrandr extension knows the dimensions of each display in both pixels and millimeters from its EDID. Clients interested in making adjustments based on per-display DPI could simply use those values obtained from Xrandr. These values can be wrong, of course -- monitors have been known to lie in their EDID reports -- but they'd be wrong in Wayland too.
Of course, no one actually wants to do this work because there is a deep-seated intent to salt the earth where X once stood.
The way multihead works in modern XOrg is basically a hack to enable seamless dragging of windows across physical display boundaries.
Once upon a time you'd do multihead on X with discrete screens and your display environment variable would be something like DISPLAY=:0.0 vs. DISPLAY=:0.1 where the last digit after the dot was the screen number. But your X client would then be confined to that screen. In this old manner you could probably have per-screen DPI stuff work somewhat, but you wouldn't be moving windows across physical monitors like we take for granted today.
Having your X clients connect to DISPLAY=:0 and somewhere behind the scenes that X server is putting its windows across physical displays or moving from one to the other seamlessly is basically Magic (look up XINERAMA) that the protocol is largely ignorant of, so the DPI differences among those physical displays are pretty invisible to the random X client.
IDK if ability to drag a window between screens is something more important than properly supporting different DPIs; but that might be a decent level of ignorance on my part
Eh, I lived with the limitation back in the XFree86 4.0 / beta multihead support days on an array of Matrox Millenium PCI cards.
While it technically works, you quickly discover the importance of being able to organize windows to different physical displays after the programs are already running / the windows have been created.
Requiring exiting and relaunching things to migrate them to different physical screens gets old fast.
That article is horrible. What it describes is yet another hack where clients attempt to guess the DPI and then rescale themselves, and the server and compositor know nothing about DPI. That method only exacerbates the problems where clients that don't support scaling are going to be scaled wrong on every screen. Compare this to Wayland where the compositor itself knows the scale of every window and does all the scaling.
Which is a fair assessment, And I think I agree with you. however there is a bit of irony around the whole situation.
The article reaches the conclusion that the best way to handle the situation is for the display server to provide the dpi primitives and let the client figure out how best to draw to that dpi. But acknowledges that there is a hack where you can make the server present a standard scaled dpi, but the drawing will then be bad. And there is this new-fangled thing called wayland where all it can do is the hack.
The irony is that wayland is infamous for usually making the clients do the work(I am thinking window managers) and X for providing a standard method. Nether of which is true, but it made me chuckle.
xrandr is not sufficient for this. One needs a way for users to configure the per monitor DPI. And have the configuration available to X clients. Currently the only cross DE mechanism for this is Xft.dpi and its global, not per monitor.
It's per screen, though ; you can have different Xresources on different screens bound to different monitors, I'm running such configuration just fine.
Actually, since most of the software I'm using is GTK-based, my per-monitor DPI configuration tool(s) are a pair of xsettingsd running with different DISPLAY variables, and having different Xft/DPI values (and a few other tweaks, like different font rendering options). I'm running two openbox instances , xfce4-panel and tint2 , and two picom instances to properly support client side decorations. And I'm trying to scrape some time to patch xfwm4 and xfce4-panel to support per-screen processes for both .
This way I'm driving 24" 4K as my primary display, for coding/browsing/etc, and 24" 2K as a sidekick for monitoring/documentation/spotify/etc
If this works for you, cool. But this is... not good in any way, and it's still not going to work for clients that use a different toolkit or text renderer than the ones you've configured. I hope you can see how it's unacceptable for an average user to have to mess around with this many random commands and environment variables just to get scaling working.
xrandr is perfectly sufficient for this, although GTK for whatever reason chooses to break it (not just not implement it; proactively break it). Xcb picks it up just fine, as does Qt. I'm pretty sure Fltk does now too though I haven't tried it in a while.
No, xrandr isn't sufficient. It still doesn't have scaling information, only size information. Changing the reported physical size of the monitor is a bad idea as it can break other things.
X11 simply isn't built to do this. If you want this to work, then the last 35 years of clients don't do the right thing and still would need to be changed to use a new extension that behaves more like Wayland does it.
Simpler you can just scale lower dpi clients down from a higher resolution. Applications think every screen has the same DPI and draw accordingly. X scales such displays to the correct physical size.
I understand the reasoning here, and frankly supported. I've been using X11 while having an available Wayland session because some applications are subtly broken on Wayland - discord has weird text input issues, same thing with Emacs, and Wezterm just flat out doesn't work on Wayland with Nvidia GPUs. However, the slow breakage I've seen with X11 has caused me to start migrating. To explain, every now and then on X11 my screen will simply go black for a couple of seconds. It happens often enough where I'm no longer willing to accept in. And so thus I've moved to Wayland. And frankly, with a little bit of effort, I've found work-arounds for all of my issues - Wezterm works if you disable wayland, Emacs 29 works fine, and Discord is acceptable in the browser. And thus, I think that disabling X11 is a good idea because finally it would force people to actually make things work well under wayland, instead of being able to rely on X11 as a fallback.
This is going to leave so many people by the wayside. (Pun totally intended.) Late 2020, my jaw dropped on the floor when a developer from CERN showed up and said that X11 support was needed in ContainerSSH for their use case and then developed it. (The LxPlus service, which acts as a dev host for researchers.) I thought X11 forwarding was well and truly a thing of the past.
Yes, I know that waypipe is a thing, but it needs to be installed on both ends and I haven't seen any mention of non-Linux support either.
X forwarding over SSH always struck me as a bit of an edge case. I used it maybe 5 times in the last 20 years. Most people probably never knew this was a thing.
I use it every day all day ever since it was introduced in ssh (can't remember when). Before that used to just forward in plaintext over the network (different times).
With every year X is still in use more and more tech debt is being built up. It's a big problem in how slow this migration is going. The Linux desktop community should have made this migration its top priority and have had completed it a decade ago. It's sad to see how far behind the Linux desktop is compared to other operating systems.
You are wondering why other people didn't invest more of their time working for free for the abstract goal of moving someone else's vision forward.
If they wanted buy in the logical thing would be to provide a something usable and feature complete with wlroots like library inside of the first 5 years rather than producing something nobody would use, claiming it is usable, and then slowly evolving it towards usability slower than duke nukem forever while continually claiming it's ready to rock until the lie slowly becomes increasingly true.
I am not wondering that. There could have been corporate sponsors or community fund raisers to fund this essential work.
>If they wanted buy in the logical thing...
I already know that this was poorly handled. If Microsoft or Apple wanted to change rearchitect display servers I can assure you it would not take over 16 years.
Reminds me of systemd: we "modern" developers despise anything that reminds us of "traditional" Unix, thus we need to rewrite it in such a way that is not only new, but actively punishes unwelcome users.
Then we will complain about "embrace and extend" while people try to replace their xdotool scripts and their perfectly working X11 setups.
Too bad for them: we don't care about custom applications, we still aim to just steal users from Windows. And 2024 will be the Year of Linux on the Desktop.
X11 has nothing to do with "traditional" Unix. Even back in the 80s the UNIX philosophy didn't work with a graphics stack and X11 itself is very un-Unix-like. This is even more true for the modern graphics stack. That being said, X11 is one of the few APIs that had a really long run and that everybody in the community agrees upon. This is extremely rare. 38 years of backwards compatibility and still being able to deliver performance on the most modern graphics stacks is a tremendously huge value that shouldn't be thrown away just because some IBM/Redhat or Collabora employee says so.
>X11 is one of the few APIs that had a really long run and that everybody in the community agrees upon
Outside of a very small niche of obscure window manager developers, this isn't true. GNOME and KDE have been trying to get rid of it for decades. The glaring flaws in the API have been known for that long.
>38 years of backwards compatibility and still being able to deliver performance
No, the Xorg server actually lacks backward compatibility with lots of non-standard X11 extensions that for whatever reason were either removed or were never merged upstream. At the time some of those may have been the best way to deliver performance on specific hardware but, like anything, they didn't hold up and were thrown away. It wasn't because an IBM/Redhat or Collabora employee said so. See also https://en.wikipedia.org/wiki/X_Window_System_protocols_and_...
Both are are really bad desktop environments and part of the reason the FOSS desktop never took off. Also they are mostly developed by full time paid employees with zero community involvement. As such they are the small niche.
> The glaring flaws in the API have been known for that long.
X11 has flaws but I wouldn't call them "glaring". They are a nuisance at best. You don't pay for functionality you don't need. Wayland has glaring flaws because it does not provide and standardize functionality that people need. It also has severe technical flaws like implicit sync which makes all your application stutter when one application has high GPU load.
> Xorg server actually lacks backward compatibility with lots of non-standard X11 extensions that for whatever reason were either removed or were never merged upstream.
Great, so there is a regular organic and efficient clean up process happening that keeps the unused or unpopular stuff out of X11. There shouldn't be much "old cruft" around then. If this is the case, why do we need Wayland?
>Also they are mostly developed by full time paid employees with zero community involvement.
No. Both of them have a good mix of community contributors to do the fun stuff, and paid employees to do the annoying tasks no one wants to do for free. A good project needs both. Are you really suggesting that another desktop is somehow going to spring up and succeed with no paid employees and no business case? If what you're saying is true, wouldn't that have already happened and left GNOME and KDE in the dust long ago?
>You don't pay for functionality you don't need.
You actually do if you're maintaining the X server and protocol.
>Wayland has glaring flaws because it does not provide and standardize functionality that people need.
These can be fixed by extending the protocol, unlike in X11 where the flaws can't be fixed because they're built into the core.
>It also has severe technical flaws like implicit sync which makes all your application stutter when one application has high GPU load.
This is actually a kernel/driver problem. It also happens in X11 if you use a driver with implicit sync.
>Great, so there is a regular organic and efficient clean up process happening that keeps the unused or unpopular stuff out of X11. There shouldn't be much "old cruft" around then. If this is the case, why do we need Wayland?
No that's not what's happening either. Lots of current X11 extensions (such as Big Requests, XC Misc, XFixes, XSync) actually exist only to paper over old cruft in the core protocol that can never be removed. It's possible to remove other extensions from the core and still keep the core intact. When the core X11 protocol itself becomes unused and unpopular (which it is) then it's time to remove the whole thing.
The API compatibility is not being thrown away. Xwayland will be with us for a long time for backwards compatibility (that includes stuff that lots of users care about, e.g. most Steam games). X11 will continue to be around, reduced to a more manageable size as a compatibility layer, within Wayland.
Xwayland only provides backwards compatibility for a very small subset of the X11 ecosystem (E.g. window managers or xdotool are not supported). As such it is only useful for very limited X11 clients on the level of GNOME applications and in most cases completely useless.
That's the same limitation as XQuartz or any other rootless X server. And you have this exactly backwards. The majority of X clients that users care about are ordinary programs, not window managers or xdotool.
> The majority of X clients that users care about are ordinary programs
This is simply not true. The only "odinary" programs according to your definition that I am running are a browser and a terminal. All other xclients I'm running go beyond that and can not work with Xwayland or XQuartz. (a quick ´grep "^[x,X]" .bash_history´ reveals xautolock, xbacklight, xbel, xcalib, xcape, xdpyinfo, xdotool, xkill, xmodmap, xrandr, xrdb, xsel, xset)
> This plan seems to The Reg's FOSS Desk to be strong-arming people into adopting Wayland.
Or, more reasonably, to maintain less code for alternate paths in favor of fixing the issues that lead people to use those alternate paths.
Wayland has bugs. X has bugs. Fixes to one largely don't help users of the other. Every bit of effort spent fixing a bug in X to help the fraction of users still using it is effort that could have gone into fixing the bugs in Wayland that leave people using X in the first place. A project taking a step like this allows it to consolidate those efforts.