"at the moment there are several types of applications that not only don't work in wayland, but would be very difficult, or impossible to work natively in all major wayland compositors.
Examples (in order of importance to me):
* Programmatic output configuration (xrandr, arandr, etc.)
* CLI clipboard access (xsel, xclip)
* Third party app launcher/window switcher (rofi, dmenu, albert, docky).
* Clipboard managers (parcellite, klipper, Gpaste, clipman, etc.)
* Third party screen shot/capture/share (shutter, OBS, ffmpeg, import, peek, scrot, VNC, etc.)
* Color picker (gpick, gcolor3, kcolorchooser)
* xdotool
[1] - https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...
Case in point: Gnome + Wayland + guake. If you configure guake to use anything less than 100% of the width of the screen, then it suddenly appears in the wrong position.
But wait, maybe that's a guake bug, right?
Wrong. I tried a couple of other options for similar functionality and they demonstrated the same issue. So odds are it's actually a bug in the compositor.
And that's ignoring that basic things like global keybinding don't work (edit: ya ya, the Wayland proponents will tell you that's by design, but it's a) user hateful b) totally different than literally any other desktop OS out there today, and c) breaks apps, right now, in ways that will require major code changes to fix) so I have to put a hack in place to allow F12 to open guake up in the first place.
Meanwhile, we only just got the "official" solution for screensharing (what Zoom does is an incredible hack: they just take lots of screenshots! No, I'm not kidding, that's actually how it works, which is why the framerate is so bad) and it involves yet more new stuff (pipewire, et al) that I'm sure will be a source of its own raft of bugs.
I'd say "maybe in a year or two", but we've been saying that for a long time, now...
The hotkey thing is big and it's annoying because it's another thing that might need to be implemented/fixed in each and every composer and environment (and it could be different in every environment).
I've seen the X11/Wayland talks and I agree Xorg has tons of old crufty garbage in it, and screen locking in Xorg is not very secure. But the Wayland team seems to have made little effort in addressing even the most basic things like hotkeys, screenshots, etc.
I'm not sure if "user hateful" is the right term, but they don't seem to be prioritizing the most basic things people are asking for.
- Handle rendering things to screen
- Handle user input
My issue is that while X has a LOT of other things it also happens to do, it just doesn't do those two primary things very well on modern hardware.
As an aside -
This reminds me of the systemd arguments all over again, but the same crowd that was ready to crucify systemd for all the things it does are now bemoaning all the things Wayland doesn't do.
But really, I think there are just a lot of folks who aren't willing to try something new, or to re-evaluate some of the toolchains they've made for themselves.
Now - I'm not going to blame them for that, having a working system change under you isn't fun, and it eats up time and resources some people don't have. But it also doesn't stop the new thing from replacing the old thing.
Particularly if the new things happens to be genuinely better in many respects.
And while I can certainly understand the pain point of missing features in Wayland, The way it gets user input and display output right are just delightful.
So delightful that I actually prefer it to my work macbook, which is not something I could ever say about X.
I'm glad they're leaving all the "desktop" stuff out and letting desktops agree on dbus interfaces. I doubt people writing little CLI utilities want to have to create dummy Wayland surfaces to do interact with the display server which is how wl-clipboard works.
It was fairly easy to find an example on stackoverflow that created a Window using Gtk, and reported it's position.
Once something like that is on the bug report things tend to get fixed pretty quickly.
Report the bug on the outer-most thing first, e.g. GNOME shell in this case.
There are strategic and tactical issues here.
Tactical issues are obvious. Wayland's problem with screenshots and all the bugs from not having a decades long lineage.
Strategic issues are less obvious. As this blog pos alludes to the standard X server is reaching a maintainability crisis where long term devs don't think the project is a good idea.
I think Wayland is a tactical mis-step myself for reasons you and GP mention, but I think now that the bad has been covered someone needs to mention the good:
The reference X server cannot practically be replaced. The reference Wayland compositor quite possibly isn't ever going to get established before being replaced. This is an excellent thing - it beings evolutionary pressure to the display system.
Wayland has problems, but unlike the current X ecosystem the problems can be fixed by replacing bits of software. The Wayland protocol seems light enough that Wayland+1 can implement it as a compatibility layer. When the dust settles, leaving X will have been a good idea.
Sadly I don't have time to work on that, which really sounds like a full time job for a team of at least 3 developers, and from the looks of it, the people in charge don't share my vision for integrated coexistence of old and new.
So Wayland is not a replacement of X11. Gnome on Wayland should be a replacement for Gnome on X11. KDE on Wayland should be replacement for KDE on X11. Sway on Wayland should be a replacement for i3 and X11. But as you can imagine in this equation, KDE, Gnome and Sway are permitted and required to take on more responsibilities.
You might take issue with the fact that a lot more of the display stack gets tied up in specific desktop environments. It's KDE and Gnome and Sway that are not providing you these command line tools/screen recording/clipboard access. I don't mean to say this as nitpicking or that """Wayland""" (whatever that means) is dropping the ball, but this is really the responsibility of the desktop environment (or WM) in Wayland's design. Wayland is just a protocol.
What you're observing as shortcomings in Wayland is really a lock of pace and direction of development for (e.g. Freedesktop) standards that standardize clipboard access/screen recording use cases, and the adoption of those standards. The Linux community seems to have been hit by 1) not realizing Wayland does not replace X11 and 2) realizing that, not being to coordinate standardization well of the pieces of the X11 stack that should be replaced as well. If you need to replace X11, you need a lot more than just Wayland. But that seems to keep on catching people by surprise.
I think it'd be helpful for the future of the Linux desktop if more people recognized that.
You can't capture an ecosystem unless you provide that value, plus the activation energy needed to persuade people to change.
systemd (as an example of a large, recent, change to the "whole system") touched end-users far less than X so the pain was felt mainly by distributors and sysadmins.
Time and again, software that's "better" fails in the market because it doesn't provide the things that users need, want or use.
Backwards compatibility is usually key when trying to capture a large, long established user base. ...and that means backwards compatibility even (or especially!) with all the "bad" or "wrong" stuff. This is one of the things that makes software "products" much harder than software "engineering" (which in turn is "harder" than computer science).
Science is how it works. Engineering is getting it to work and productisation is getting people to adopt it.
Wayland has to solve problems that end-users actually care about rather than just being better in technical ways.
But the writing's on the wall. This change is not coming about through market forces as you're suggesting, but where the developer's interests are. And that's pretty clear X.org's development has slowed down significantly compared to whatever is happening around a Wayland ecosystem. Although sadly not as much effort is put into the stuff that is needed outside of Wayland.
Love it or hate it, but systemd has been around since 2010, and is almost ubiquitous by now. Wayland has been around since 2008, and it still seems more like a tech demo for most use cases rather than something that is production ready. There is clearly an issue with this project.
For the understanding of all of this by the community, certainly. But Wayland could have never been a direct replacement for X. The problem with X is not that it's old or poor quality. Even if that were so, that is fixable. The problem with X is that its fundamental design principles are not suited to a desktop made after the early 1990s.
The reason X is much more entrenched than being a display protocol very much has to do with every X running system having a standardized X server any system process can talk to. That client server principle was fundamentally flawed and Wayland fixes that, but that very same client server principle allowed this X ecosystem to thrive. Any "X replacement" that did away with X11's core design problems would therefore run into not being able to replace the ecosystem in the same way.
If there would have been a coordinated effort to replace X, we would have needed a much broader initiative pop in 2010. An initiative where Wayland is one component, something like PipeWire another, and some Freedesktop IPC standards for e.g. accessing the clipboard and other features provided out of the box by X11, and reference utilities implementing those standards.
But coordinated efforts like that are not really how the free software community works! So Wayland just evolved out on its own. It started as a small effort by developers frustrated with X11 the display server protocol. The community then proceeded to take the line "Wayland is a replacement for X.org" and then ran with it, creating confusion everywhere, and stifling progress to replace X11 in the process.
Systemd is quite unique in the free software world because it's a tremendously coordinated effort and has taken on a broad scope. And just look at the sheer amount of vitriol that ended up getting just for those aspects of the project. It's just not how the community likes to operate, or at least a vocal minority does not like this.
Look from another side. Wayland has been around since 2008 yet it accomplished something X.Org could not. It's been 30 years in development, it has tremendous market share and yet it failed. There is clearly an issue with this project.
I hope we'll eventually have some "wayland-goodies" package which will implement the common stuff like easy screenshooting, easy hotkey assignment, easy window inspection and control, etc. I suppose this can be implemented based just on the protocol, and not specifics of a compositor.
This statement doesn't make sense to me.
X.org is a display protocol, its own server implementation of that protocol, and many utilities to interface with that server. And even more stuff.
To illustrate this: if you run Gnome on X.org, you will see you have an 'xorg' binary running in addition to all the Gnome stuff. That's the X11 server from X.org. If you run Gnome on Wayland, there's no 'wayland' stuff running. There's just Gnome implementing the Wayland display protocol.
That's why this "switching to Wayland" talk is just missing the point. You're not really switching to Wayland, you're just switching to a "pure Gnome" stack, or a "pure KDE" stack, or a "pure Sway" stack. These stacks all just happen to implement the Wayland protocol in their own compositors (i.e. Mutter, KWin, Sway) because they're committed to standardization and all want to run GTK3+Qt5+Ozone+XWayland+etc apps built for Wayland.
* swaymsg (no idea what Gnome or KDE do here)
* wl-clipboad
* wofi, or a Wayland fork of rofi (https://github.com/lbonn/rofi)
* I don't use a clipboard manager, so I'm gonna skip this one. :D
* slurp, grim, wf-recorder, mpv (OBS and ffmpeg work fine, not sure about the others)
Also here's a oneliner for color picking:
grim -g "$(slurp -p)" - -t png -o | convert png:- -format '%[pixel:s]\n' info:- | awk -F '[(,)]' '{printf("#%02x%02x%02x\n",$2,$3,$4)}'
This is the biggest problem. I accept Wayland brings benefits for some people, but I couldn't care less. Since I don't care about the benefits it brings, it needs to be entirely painless.
Until the switch is more painless than holding on to Xorg, there will be a good chunk of users with no incentive to make the move.
EDIT: I'd also say that the fact that so many of the tools need to change, rather than e.g. get support added to them to support Wayland compositors is a huge indictment of the whole thing. It seems like no thought was put into planning for transition.
That depends a lot on how difficult it is to keep Xorg working with modern distros. You might get forced into Wayland when your favourite distro and all acceptable alternatives don’t want to put the work into integrating and patching an aging Xorg.
Whether it’s with a carrot or a stick, you’re going to Wayland sooner or later.
Put another way: I've seen similar new things come and disappear several times.
Some of your issues are solved:
CLI clipboard access: wl-clipboard: https://github.com/bugaevc/wl-clipboard
App launcher: bemenu: https://github.com/Cloudef/bemenu
I'm really concerned about Wayland fragmentation. Will some tools work on only wlroot implementations and not others? X11 apps generally work across window managers, although the weird ones (tiling window managers like i3) may have some interesting things you have to work around.
If wlroots became the standard for all window managers on Wayland and everyone used it, I guess it would be fine. But if not, we're going to see a lot of apps that have to be adapted for each and every composer.
If the world can agree on Wayland then desktops can agree on some dbus interfaces for doing stuff like screenshots, screencasts, and automation.
Wayland is a shiny new thing and lots of people are writing compositors since it's suddenly possible for people to write them in a way that you simply couldn't with X11. The ecosystem will eventually mature but I think it would be a mistake to recreate the Xorg monoculture with wlroots. People seem to see the value of multiple browser implementations agreeing on standard but not display servers.
This is the common refrain I tend to see. I know I was certainly in the "Can't believe it" category, since I'd tried wayland about 4 years ago and ended up moving back to X.
That said, I had exactly the same reaction 2 years ago when I gave it a shot on my new machine.
It was fast, didn't show any tearing or flickering, handled automatic configuration of most monitors correctly, and made my touchpad genuinely nice to use.
Just the touchpad support alone won me over pretty much immediately.
I went from "Eh, Wayland isn't ready" to "Holy shit, I'm never going back!"
https://github.com/swaywm/sway/wiki/i3-Migration-Guide#commo...
ydotool is listed there as an equivalent of xdotool, but ydotool has only a tiny fraction of the features of xdotool.
And it's unlikely that it'll get much better any time soon, as its README says:
"Since Jun, 2019, I have little time to maintain this project"
wtype is listed as another equivalent to xdotool, but it has even less features than ydotool.
If the rest of the X equivalents on that list are as feature poor as these, I don't hold out much hope for Wayland in the near future.
You're here complaining that a maintainer isn't around to add features in a thread that's literally a major maintainer of X server telling you he's not going to work to maintain the project anymore.
---
Here's my take on your position - I absolutely agree that if you have processes and tooling in place that you currently depend on, and can't replace, you should stick with X.
That said - As a way to manage input and output on my system (MY system, with my preferences and my requirements) I've found Wayland to be a delightfully better experience than X.
So to come back at your list of requirements, mine looks like
- Multimonitor support, including mixed scaling ratios
- Touchpad input with gestures, approximately in line with the experience on OSX
- A sane "default" that does not constantly require that I manually edit settings or xconf files on EVERY system I touch
- No screen tearing or flickering. Seriously - NO!
---
The difference between the two lists, is that I believe Wayland can eventually replace the tools you need. I no longer have any faith that X will be able to solve my requirements. Wayland does.
From the article, about X:
> But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse.
This is a weird conflation of this developer's experience after being burned out on development, and the user's experience running a modern distro.
If as I user I confuse those two things, then I'm going to click the button to choose Wayland when I log in. And I guarantee you my experience as a user will be worse on Ubuntu, Debian, and probably any other modern distro by making that choice.
I can work around that worse user experience by choosing alternative to what doesn't work, but that's a separate issue from the default UX under Wayland making my life easier.
This whole "desktop stack" on Linux always makes my head hurt, so these might be really dumb questions:
If I install some distro, Arch say, and I wanted to use Sway, and I then want to run Kile, will Kile then run through XWayland? Will it work just as well as Kile on KDE Neon?
I understand KWin has some Wayland support but it also seems not quite ready for prime time the times I've tried it. So was curious about alternatives, just for curiosities sake.
Kile seems to use Qt5, so should work without Xwayland.
> Will it work just as well as Kile on KDE Neon?
It should, yes. I don't use Kile though, so I haven't checked.
Since Kile is a KDE application it should run using Qts wayland backend.
> Will it work just as well as Kile on KDE Neon?
Depends, do you need anything more fancy than mouse and keyboard? No? Then great.
Power user functionality like copy paste on the other hand? https://github.com/swaywm/sway/issues/4007 might want to pray before using that.
Yikes! So just more fragmentation and half-baked alternatives.
Because Wayland pushes so much logic into the compositor, there's now the very real likelihood that things will work on Gnome but not KDE, or work in i3 but not Gnome.
For me it’s some of those, dwm, sxhkd, keynav, xcape, the Compose key, and simple highlight + middle click/Shift+Insert copypasta. I’m a bit confused about the extent to which the Wayland devs have changed their minds about the last one.
So far I basically kept using X11 because it mostly just works for me, but I didn't expect that Wayland was still so far behind.
https://gitlab.com/interception/linux/plugins/dual-function-... (currently using this – very powerful)
https://gitlab.com/at-home-modifier/at-home-modifier-evdev (used this for years – works extremely well)
Two more projects I've found that should work on Wayland:
Every time this topic comes up, a bunch of people bring up the things X has that Wayland doesnt yet have, or have in the form they think it should.
I'm not sure if it's just me but these comments come across as some combination of defiant, demanding, or I dont know what. It's like they don't understand that the world is moving on and doesnt really give a $h!t about them and their love of X. I mean here is a post from "the guy" whose been keeping X going for a long time saying "this shit is done" and people keep complaining about that as if they have some say in it without actually contributing to the code. It reads like entitlement - some kind of expectation that other people exist just to make things the way they want them to be.
Entitled developers who think their work is above criticism just because it's open source are just as annoying as entitled users who think they are owed something.
X, architecturally, is a dumpster fire. None of the ideas that were reified in it's design, types, or behaviour - not forcing rasters down unix pipes nor building widgets with X objects nor rendering networked fonts nor the general concept of immediate-mode widget rendering - are actually used today in modern X apps and have been mitigated-away with hacks and jury-rigs. But the design and the types and the protocol persists and no one wants to work on this nonsense in their free time. Unpaid programmers have voted with their commmits and Xorg has been orphaned. It's a dirty job and for the longest time only paid programmers have maintained X. And the last company to pay programmers to work on this stuff canvassed their customers and decided that the work didn't need to be done anymore.
Everyone using X today has been free-riding on RHEL customers for years and Redhat has decided not to burden them with this anymore. And nobody else is volunteering to pay for this.
I don't think entitled developers is the right term here. As an Xorg user, how much did you pay to use Xorg?
That's valid, and I did say I'm not sure if it's just me - meaning my (possibly wrong) interpretation. A list of specific things missing is fine, but the I'm-not-switching-until sounds different than a simple valid criticism or an inquiry as to weather those are being addressed.
I probably should not have responded to a particular comment with my comment though. It wasn't too bad as those things go. Some of them really do come across the way I described.
I mean, this really sounds very similar to systemd and pulse audio type gnashing of teeth where the new solutions added plenty of widely required features while compromising on niche use cases which had other workarounds.
Every time this topic comes up, a bunch of people remind that Wayland doesn't yet have an accepted standard for basic features. Wayland is very good at some niche features like HiDPI or fractional scaling* , but more people (at least two orders of magnitude more) need screensharing these days when companies move to WFH.
* Yes, these are relatively niche features right now. e.g. Look at the Steam hardware survey: more people run resolutions below 1080p than above it - and that's in a biased sample, since gamers are more likely to have high resolution monitors! Now, it's nice to be future proof, but these features should not be prioritized over basic features.
* Image editor, with own modern looking GUI-toolkit built on top of X11 (AzPainter)[0]
Same thing actually decided by AzPainter developer: they already tried to add Wayland support to its GUI-toolkit (additionally to already supported X11), but postponed it due to Wayland still is not fully usable.[1,2]
[0] https://github.com/Symbian9/azpainter
> EGLStreams (NVIDIA): GNOME, KDE, Weston
I was suprised to read that OBS doesn't work with Wayland. I found some articles [0] on how it runs well using XWayland [1] - which I guess let's you run X-Clients under Wayland - but it seems that the amount of work to get this to work is not trivial, considering the official PR for the work, is on part 3 and that has been open since March![2]. Oh, how did it get so bad?
---------------
[0]:https://feaneron.com/2019/11/21/screencasting-with-obs-studi... [1]:https://wayland.freedesktop.org/xserver.html#heading_toc_j_3 [2]:https://github.com/obsproject/obs-studio/pull/2484#issuecomm...
* https://github.com/bugaevc/wl-clipboard
* https://github.com/ReimuNotMoe/ydotool
OBS / ffmpeg and etc. should get integrated with Pipewire I think for screen capture and the like? But I'm not sure how far that progressed.
Also, there's no longer tearing when I resize windows!
If you are re-architecting a system from the ground-up there is always some fallout expected.
I would also not expect people to suggest deprecation OS X in favor of Windows and then shit on people what want to keep using their OS X Clipboard manager.
This is the real problem with all this forcing to move people to Wayland / Pulse / SystemD crap: They are new platforms instead of compatible improvements to the existing platform, but somehow you still expect everyone to just jump ship.
Wouldn't it be easier to make it a separate service instead of having X or Wayland deal with it?
Open source software is also free (as in beer) software.
There's a word for people who complain about free things.
The problem is not wayland. I root for wayland and I hope it'll progress steadily to maturity.
The problem is getting pushed to drop my well-working Xorg-based setup for some wayland-based setup that can't run the application I use daily and that I've been running for years.
I'm okay with wayland, but I have a problem with people telling me "oh just drop that".
GP is saying yeah, that's great and all, but other people try to push everyone to switch to Wayland because <reasons>. The Wayland ecosystem simply isn't there yet though; they're hawking a broken solution.
It's perfectly fine for a FOSS developer to walk away from any given project. When third parties come along and frame things as though the only option is to switch to a broken "solution" it derails the discussion. We (ie the community at large) should be having much broader discussions about both how to keep maintenance going as well as what's needed to actually make the replacement viable (so we can maybe switch to it later).
Only that they'd rather use (unmaintained) X over Wayland due to numerous shortcomings in wayland that are practically unfixable (because they're intentional design choices, or because they're a result of the fragmentation resulting from wayland's design choices).
It is fine. It is done. Maybe something better will come along at some point, but we could just keep using it like this indefinitely.
The post and comments are free, yet here you are complaining. Consider why you think that's okay, and you'll understand.
You don't complain about the weather?
Even if all developers were paid, they wouldn't be paid _by users_. It means the developers don't owe the users anything.
Those users are the target market that those companies are interested in pleasing. It’s not about “owing” or not. It’s about delivering something that people want to use or not. If you fail, the users will go elsewhere. You don’t have to care; you might develop the software for your own personal gratification. But people are going to share their dissatisfaction and might very well vote with their feet. And it’s possible that, even if they don’t, your work makes the world a worse place. No, no one can sue you or call you a cheat for doing a bad job, but they don’t have to like it either.
XFree86 is a specific X server implementation, though it has been superseded by X.org sometime around 2004 due to a license change from the MIT license to the 4-clause BSD license, which is incompatible with the GPL. X.org is by far the most dominant X server implementation in the free open source software community, but it is not the only implementation; off the top of my head there were proprietary X server implementations for SunOS and NeXT.
My understanding is that the scene for the fork had already been set by the time of the relatively late license change. I seem to recall reading at the time that the XFree86 core team was unhappy that a sole contributor was attempting to modernize the system by introducing extensions, without building consensus around them to their satisfaction.
So the license change was meant to prevent forks from merging in further work on XFree86.
Of course the fork was adding functionality everybody wanted. So the fork survived and upstream languished.
This is a kind of odd retelling/interpretation of events, considering the “rogue” contributor version is the only one that lived and XFree86 is history.
It has a long a storied history. The concept of running an app remotely and use a local display server is probably the thing that sets X11 apart from the rest of the pack. This is still really useful in my humble opinion -- I can run X11 apps (e.g. xv) on a headless EC2 server running Linux in the cloud and have the UI/display on my Mac (using Xquartz).
This story runs in parallel with the history of Unix itself.
However, regarding remote setups, is X forwarding significantly superior to using something like VNC? I've never done a side-by-side myself, but most of what I've read indicates that VNC is usually faster.
As a semi-experiment, a few months ago I decided to try running Firefox in a Linux VM, and render it in XQuartz on my Mac host. The experience was not pleasant, to say the least. And that's what I'd think to be the best-case-scenario for latency. Hard for me to imagine using it over WAN.
XFree86 is a free software implementation of the X Window System.
The whole server/client thing is a bit outdated now, since almost nobody uses actual thin clients anymore. X forwarding is useful, but it's not a mainstream way to do your computing.
Sun also tried to get into this game early with the JavaStations. But they were ridiculously slow, so painful to use. In fact they kind of ruined Java for me. I was learning it at the time, and we got a JavaStation on loan from somewhere. Working on it just established this "Java = slow" feeling in my head and really put me off so much I went to do other things.
Of course this wasn't really deserved, and Java has gone on to become powerful (though I still consider its poor intra-version compatibility an issue). But I've never been able to quite shake that feeling.
+----------------+ +----------------+
| Client +---->+ Server |
| | | |
| +-----------+ | | +-----------+ |
| |X Server +<---------+Application| |
| +-----------+ | | +-----------+ |
| | | |
+----------------+ +----------------+
The one place that X could use some updating is all the sync method calls, that unlike RDP become quite slow if the network connection has any real latency.
I wouldn't say the one place, but it is a pain point.
(And actually, many of the supposedly synchronous things are not synchronous at the protocol level, but at the C library binding level -- xlib. Nowadays there's a much closer to the protocol binding: libxcb.)
What does he mean by that? That there isn't really a hardware-accelerated Xorg server?
If that's true, is the post indicating that Adam sees the Xorg code as an interface layer to some other rendering system that had hardware acceleration?
Is that XWayland? I'm guessing at all this.
In an ideal world where everything uses KMS or everybody uses something like Xwayland we would be able to kill million of lines of code from the Xserver. While this doesn't happen, those millions of lines not exercised by these paths remain unmaintand.
Remember, Ajax works for Red Hat, which is trying to push really hard for Wayland on Gnome. They don't seem to care about anything graphics-related that's not Wayland+Gnome. Red Hat has much more decision power on the Linux community than people imagine it has.
A huge problem here is that a lot of efforts that were previously redirected at X11 are now being done on the Gnome compositor, due to Red Hat. We just won't get to see a solution to the fragmentation power unless someone with a lot of money decides to play Linux Graphics.
sloccount says xserver is around 370kloc. This isn't counting the drivers outside of the generic KMS support (which, practically speaking, is what you're probably running on anything remotely modern), but ati+amdgpu+nouveau are another 102k, and intel is another 186k (partly because it embeds a copy of the software renderer for dumb reasons), so you're still not quite at two-thirds of an MLOC. The size isn't so much the issue, it's the design. The xfree86 ddx seriously believes that you have one video card driving one monitor with one keyboard and one mouse, and anything beyond that only works well because we sank a ton of effort into it. (It used to have code to disable interrupts! From userspace! What could go right.)
It sounds a little like you think I'm being given these priorities as marching orders from above. That's maybe a bit insulting? I suspect I'd have the same opinion at this point regardless of my employment history, namely, that X is a tremendously successful project whose core design and reference implementation do not reflect how computers work anymore, in ways that make it painful to develop and maintain as the system display server. Frankly that was probably true in 2005 when I started on it, but at that point it was also the only thing that had credible video drivers at all.
It's not that Red Hat is trying to lock anybody into a particular desktop out of some nefarious political agenda, it's that we don't have the resources to do things twice. If we want to deliver the best desktop experience we can then choose your own adventure among Gnome and KDE and XFCE and twm and i3 and whatever else simply is not going to be an efficient use of our headcount. And we're reaching that point with display services too, trying to support both X and Wayland increasingly means writing the same feature twice, sometimes with radically different approaches, and trying to implement them _at_ _all_ under X11 is more and more intractable. What would you have us do? What we're trying to build now is an Xwayland that keeps your X apps working as well as they ever did, under a hardware display server model that makes things like high-dpi and HDR and AirPlay and RDP and GPU offload straightforward, or at least feasible, instead of excruciating. You can like that or not, I guess.
In all seriousness, if someone wants to take the reigns of stewardship over the xfree86 code then please, by all means, come forward and claim your prize. But I can't justify spending my time on that anymore, and given the interval since the last major release, apparently nobody else can either.
I appreciate the work that is going into the Wayland desktop ecosystem, really, but I would wonder why you would put all this general-purpose desktop environment implementation effort into Gnome specifically and not a common library like wlroots, with the Gnome compositor as a layer on top, so that all compositors would benefit. (I would ask the KDE team the same question.) It feels like what we are losing most with the transition from X11 to Wayland is commonality of implementation for the various system services other than input or presentation which were formerly handled by the X server, and which are now handled either by the compositor itself (Gnome and KDE) or by a shared library (Sway and any other wlroots-based compositors).
It is good that we at least have standardization at the protocol level, but just the same in my opinion it is … unfortunate … that the two largest desktop environments chose to forge their own paths in terms of the implementations of those protocols, with various desktop-specific extensions.
> 1st big paragraph
Yes, I recognize I exaggerated regarding LOC. I should have not said that. I do understand that the core protocol assumes one of each thing. Sometimes I dream about declaring X12 being the same thing as X11 but with the core protocol being converted to just an additional extension marked for deprecation :). Then we also deprecate everything related to drawing and find a way to make compositing great again.
> 2nd paragraph
I did not mean to insult you at all. But let's be honest: if you wanted to spend your time doing something that your employer does not want, you'd either have to do it outside your normal working hours or you'd start getting bad performance reviews due to not being aligned with the business priorities. Red Hat's business alignment has much much much more influence over the Linux ecosystem as whole than people on Hacker News realize or are willing to believe.
> 3rd paragraph
I understand it, and that's why I say things won't change unless someone else with lot of money decides to play Linux Graphics. We can't blame RH for choosing a path and following (to quote a certain someone, "Linux is not about choice", right?). But we do have the unfortunate consequence that RH's decisions are contributing to significant fragmentation. You don't want to have to reimplement the stuff for X+Wayland, but everybody else who does not want to use the Gnome compositor will have to reimplement the stuff you put on Gnome. There's probably a lot the community (not only RH) could try to push to alleviate the fragmentation problems.
> 4th paragraph
I completely understand that.
If only we had more real world money-making products actually relying on the desktop graphics stack to make money, then we'd have a better graphics situation.
The organization is called X.Org. The project is called xserver. It contains several display backends. The one based on the model inherited from XFree86 is called xfree86 in the code, but the executable is named Xorg (to avoid stepping on the XFree86 trademark, if memory serves). Its other backends you might encounter include Xvfb for an in-memory virtual framebuffer; Xwin and Xquartz, for running nested under some commercial OS' display servers; Xephyr and Xnest, for two different approaches to running nested under another X server; and Xwayland, for running nested under a wayland display server.
So when I say Xorg is abandoned I'm very specifically referring to the xfree86 code, to running xserver as _the_ display server.
There was an inversion from "Users per to Computer" to "Computers per User" and that model mostly fell out of favor.
However they were more than a simple terminal. Most of them were basically small Unix computers (like the SPARC X-terminal which was just a diskless low-powered SPARCstation, it could actually run full Solaris). HP's EnvizeX stuff was similarly complex though I don't think they could run HP-UX. But they weren't nearly as 'dumb' as the text terminals of the days.
I still have a few Sun Rays here but they used a very different protocol that only worked with their proprietary software.
However I do expect a return of this model. Now with the cloud, a lot of computing is once again shifting to a central model rather than on the endpoint.
Todays modern desktops with compositing and rendering libraries that can target hardware acceleration and run games and visualisation software on opengl or vulkan aren't well served by network transparency and the X extension model.
The sad truth about X network transparency is that it generally worked better to write to a local screen and then send the screen updates over some other protocol like vnc or nx.
You could sit down at any of the terminals on campus, select the server you wanted to log into, and log into your own account.
It would bring up a fresh instance of your desktop, much like when you boot up your own computer. Except all the files and configuration were on a shared server.
The experience was almost as good as running applications locally, with the added benefit that the applications ran on a big, shared, beefy computer somewhere else, much more powerful than could be placed at each desk.
And you could sit down wherever was convenient to do your work, and have all your files and familiar configuration available.
Back then, most people didn't have their own laptop to work with so that wasn't an option. Those that did, their laptop would be much slower and have a poorer quality screen.
If you read other comments in separate parts of the threads here, you’ll see people describing re-scoping certain elements “out” of Wayland and “into” other layers to fix “broken” parts of X. Those “widely agreed upon” solutions for other layers exclude considerations for the way OpenBSD works in fairly fundamental ways that make it seem (to me, at least) there is no practical purpose in exploring Wayland on OpenBSD beyond the point it has already been explored.
I’m speaking about the coherent and supported OpenBSD operating system, not what can be found in packages.
If there ever become features fundamental to the current user-developers of OpenBSD that are enabled by Wayland, I would expect them to further modify Xenocara to support those use cases, but it is hard to even imagine what those could be. Most of Wayland’s promised future features are anti-features to the OpenBSD approach.
I expect that in 5-10 years, many user applications will be Linux-only, and there will be many conversations about how stubborn BSD (and Windows/Mac) designers are for not aligning to earlier decisions made on their behalf.
These are just my personal opinions with no inside knowledge from any part of this intellectual territory, and I do not accuse or blame ANY developer on ANY project for working on what they are interested in, but I expect this unified Linux (and Linux-only) outcome is the unstated but express purpose behind promoting Wayland for some of the commercial interests that support it.
I want to doubly emphasize that I am talking about the motivations of executives determining the allocation of capital and human resources, not about the motivations of the developers, which are clearly to facilitate cool or useful new things.
Windows & Mac are already on exclusively Wayland-style compositors, they made that transition years & years ago (Vista was Microsoft's transition, for example, which was 13 years ago now). Why would they have any issues here?
The driving force behind Wayland appears to be commercial interests that have no interest in the desktop use-case per-se.
The linux-only outcome is purely an unintended side-effect.
It's not even the second time.
This is the third time X development has been abandoned. And yet, millions of us use X11 every day.
Don't hold your breath for Wayland to replace X11.
When XFree86 was forked to X.org, is that what you call the first?
X11 gave us XFree86, because changes to the X386 server weren't being merged. There wasn't much of an alternative to forking.
Xorg was forked from XFree86 over a license change, but after the fork, XFree86 died -- its maintainers were unable or unwilling to merge changes or do releases.
As I understand it, Linus' number one deal is "don't break backward compatibility." The Unix Way is "Write programs that talk to one another..." etc. This is the foundation that I believe put Linux where it is today, this is why I love it and use it so much.
Which is why I'm dismayed to see so much comfort with what feels in line with a proprietary top-down control attitude, the thing that Microsoft and Apple et al do, i.e. "This thing is going to change, so get over it."
I appreciate that there is work being done. I'm willing to trust that there is a point to Wayland (I literally don't get it at this stage; trying to use it presently creates FAR more problems than it solves) -- but it seems like it should be axiomatic that the project works harder to preserve the space than it appears to now.
By contrast the common complaint about Wayland is that it doesn't have the vast variety of unrelated features rammed into it like X does.
Part of the problem here then is that there's A) no big pushes for 'does one thing & does it well' for all the other X features (like clipboard or global keyboard shortcuts), and B) fragmented implementations of the wayland protocol. There really should have been a much better, and more singular, reference implementation that Gnome, KDE, etc... all just embedded instead. Which means the "does it well" part is taking a really long time, as developer communities are split up.
I have an opposite view. X11 has two key aspects separated to two independent entities: mechanism (in Xserver) and policy (in window manager). This has and advantage as neutral mechanism can be shared by everybody (Xorg), while everyone has different opinion about policies (many WMs).
Wayland assumes integration of compositor (mechanism) and WM (policy) to one entity.
I have to remind myself to try to dig a bit deeper around to find out about the things I'm more into; what matters more to me than "the desktop" is "applications/programs" -- and that seems to be harder to seek out these days.
Distribution is a collection of such parts, you may think of it as "proprietary top-down control attitude" but it is just a collection that suits someone needs. It may not suit you, you may replace parts, you may create another distribution. For example as Arch Linux user my install does not include graphical system, no one forces me.
The point I see is that Wayland got something useful. So useful that distributions started to switch their default. If anything it conforms that X11 has some problems, that it was harder to achieve same result there. Maybe it does not cover your needs but it covers someone needs better.
I know enough about X, but. What the heck is wayland?
wikipedia says (display server using the Wayland protocol is called a Wayland compositor, because it additionally performs the task of a compositing window manager.) Whats the compositor doing? Does this effect local linux or only trying to run windows remotely? Xwayland?
I've used X (Xwindows) to run windowing apps remotely (ssh -X) occasionally. It works, excepting that now that I WFH it doesn't.
Linux moves very slowly, but shouldn't replacing X be a great thing?
The windows (clients) send their local framebuffers to the X server, X sends them to a compositor, the compositor joins them together into a big framebuffer that has the different windows in their respective positions and sends them to the X server. The X server then displays them on your screen.
There's a relatively new (~10 years old) protocol, called Wayland, which will replace X. The architecture is better and it has some other constraints (vsync is always on, so there's no screen tearing). Some distributions are using it by default (Fedora), but most are still sticking to X, since Wayland is not completely ready yet (in practice) and other projects are still transitioning into Wayland.
Maybe I got some technical details wrong, but that's the basic idea.
So basically Wayland replaces the X protocol. (I had to run some things with ssh -X, and windowing on remote machines came back to me..)
And Xserver is replaced by another Compositor which is not specified, but poking around Weston seems like the reference one (towns in metro west Boston?)
No tearing would be nice (I watch someone weekly on a Manjaro install, tearing linux screen share, it can be unpleasant).
I'm assuming a lot this gets abstracted away by QT/KDE , Gnome/GTK so developers can just Develop. (probably at the expense of alternative desktops..)
I guess it would be nice to have Wobbly Windows - but there's nothing about it that is missing for me.
Wayfire got you covered: https://wayfire.org/
As much as I like sway, this smells like bad architectural decisions when so much code needs to be rewritten many times.
X11 is ancient (1987), but it's brilliant. Its designers even anticipated having 16 mouse buttons, and (more importantly) opening a window on a remote system.
The system is flexible, programmable, customizable; I've got all development manual volumes here on my shelf.
While I'm open and sympathetic to any new ideas and improved software systems, including novel windowing concepts, personally, I don't have any unmet window manager needs at present. Any new system shouldn't just replicate a subset of X11, they should go beyond the state of the art to justify the time investment.
But X11 has been stale so long it would really benefit from a back-to-the-drawing-board approach. From many points of view. Network latency, security etc.
But Wayland isn't it for me... It's too desktop centric IMO.
I mainly use it when logging into headless servers by the way. Saves me setting up a complete desktop environment there. All they need is the GUI apps I need and some X libs.
Ajax seems pretty open in his invitation for people to come and help maintain the things RH doesn't care about anymore...
I think you may have misunderstood the commenter you replied to: they were probably referring to the careless breaking of backwards compatibility that was being done while Xorg was still nominally being maintained. I think a good example is refactoring the Server while silently breaking extensions they don't care about.
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/3...
I'm not convinced it will ever actually happen.
Assuming they do.
Is there any software that can replace the server part of it?
For example in my current work I SSH -X to another machine, and use X apps installed on that machine, any other software can do that?
Although X was remote-capable from early on, it was never especially well designed for remote uses. For example you can't easily detach from a display and move an app to a different display. And it's not very good at latency on a high-latency network. Partly that's because of how it assigned XIDs in the protocol; they should have been client-assigned. It would still be possible to make that change (as an extension) but it hasn't been done.
It would be great if there was a modern remote desktop application protocol, that works well over all kinds of networks and allows application windows be moved between different display clients easily (e.g. from your laptop to your desktop at work). Or even better, let the application move as well, for ideal responsiveness everywhere.
I think we will get that eventually, because it's such a natural evolution of all the distributed things we're building. But I think it will be a long time coming.
Indeed it's not great at high-latency, it was invented for rooms full of local X-terminals (that were on constantly so connection loss wasn't an issue either, unless someone messed with the cable terminators :P )
I would love for this to continue being developed though, as there is still a great usecase for it IMO. But the protocol could really be cleaned up removing a lot of round-trips with locally cached variants (basically what NoMachine NX and X2GO are doing).
I do agree it makes sense in this increasingly cloud-centric world.. I hope it will eventually come too!
Windows has Xming and Cygwin. Mac has XQuartz. Linux, well, has Xorh and Xwayland. Even on iOS and Android there's X servers.
The ecosystem is still powered by the community. I see a lot of patches coming from hobbyists in many related projects.
Except X. X is X and everybody agrees that X is X. It's not perfect, but it's there, and it mostly just works, and all the programs are written for it. Instead of trying to fix the one thing we've all managed to agree upon, we're going to replace it with something completely different.
I'm not sure this is a good idea.
Wayland works really well, I think people who can't use it yet because of features they miss should just use x.org and stop complaining and harassing open source developers. I'm using sway and wayfire but I have no clue how they work behind the scenes or wayland itself.
Wayland is also a protocol and also documented, somewhere. I heard it has support for extensions and they are also in some repo. Search: https://cgit.freedesktop.org/
A big difference between the Wayland and X11 protocols is that X11 covers a lot more things, like drawing. Also, X11 has the concept of a client that is also a compositor and tons of interfaces for clients and compositors and the Xserver to interact. Wayland has none of those things, because the entity that implements the protocol is the compositor, unlike X.
Everything that's not covered by the Wayland protocol or extensions has to be defined/implemented by the Compositor, and that's where Fragmentation is killing us. Each compositor is allowed to implement whatever it wants to deal with those things. I am not aware of any standards here, although I would recommend trying to look if any XDG standards exist for those.
The other problems like environment drift and maintainer interest are secondary to the trust problem.
Who is using Wayland without X in Asia right now and isn't using English?
That said, the way fcitx works is to use toolkit integration directly, rather than work with the compositor via the input-methods protocol. So it only works for programs using those toolkits. Thus gtk2, gtk3, qt programs will work, but not something like alacritty. (This is good enough for my use case.)
That said- Wayland might be the only future but I'm not convinced it is the present. It still misses a specified way to handle shortcut keys and screenshots.
But I'm not even sure what to do about Wayland, other than switch to Fedora and meet that people that use it. I'm in a complete we-all-wish-we-were-using-wayland-but-aren't bubble. It's unfortunate.
The trouble here for those who use Unix-likes as graphical programming environments is that Wayland is the intended replacement for Xorg, and the quoted statement comes from the perspective of making products for non-technical end-users instead of something power-users (like many of us here) can use efficiently. I will not claim here that it is theoretically impossible for efficient graphical programming environments to be based on a Wayland compositor, but the facts are firstly that currently Wayland based systems are a downgrade compared to Xorg (I think the Wlroots/Sway is currently the only compositor that tries to cater to power users, and the issue with Wayland is also that support from the compositor is necessary and difficult for almost any feature), and secondly that the Wayland design is hostile to features that power users are already accustomed to from X Windows. More broadly, Wayland is actually hostile to features like screenshots that all users of other operating systems are accustomed to, meaning that Wayland is actually causing an unnecessarily ugly image of Linux systems among users of other systems. Causally related to the above is the fact that the Wayland design necessitates great duplication of effort for both compositor implementations and applications that want to be able to use more than one incompatible compositor.
Three days ago there was a discussion here on basically the same topic, and because my comment there[1] is completely relevant, I'm going to mostly just copy it here:
A too common complaint about Wayland (or Wayland compositors, more specifically) is that it is taking a long time to catch up to X11. The elephant in the room is that this situation stems from a deeper issue: Wayland has a horrible design, for an X11 replacement, a design that leads to massive fragmentation issues across the graphical part of the Linux ecosystem. Implementing a Wayland compositor requires much more effort than implementing an X11 window manager and each new compositor implementation reinvents the wheel many times, leaving users with less options for a desktop environment than on X11. Even worse, Wayland does not standardize on or is hostile to some essential features, meaning that users need to rely on compositor specific behavior for those features, if they are even available. E.g., an application that needs to grab the entire screen will need separate code for each compositor it supports screenshots on, or it must use a protocol outside Wayland to get the screenshot. Quoting Red Hat: > Furthermore, there isn’t a standard API for getting screen shots from Wayland. It’s dependent on what compositor (window manager/shell) the user is running, and if they implemented a proprietary API to do so.
An xdotool (an input event automation tool, imagine wanting to inject or intercept input events) replacement is not possible on Wayland (without having separate support for each compositor, of course). These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile), this[0] Reddit comment puts it nicely:
> It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones. But for some reason we absolutely need this technology on the desktop, like we had not enough pain and lose ends over here without it.
But the lack of these features AFAIK also causes big trouble for users with special accessibility needs. Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games.
[0] https://www.reddit.com/r/linux/comments/7lb5l7/new_screensho...