Maybe don't write an Xorg window manager right as the replacemeant for Xorg starts to take off though
2. While it appears that Wayland is poised to replace X11 on Linux desktops given the amount of backing Wayland has compared to X11, it is not clear whether Wayland will replace X11 in the BSD ecosystem. According to the FreeBSD Wiki, Wayland is not ready to be a daily driver (https://wiki.freebsd.org/Graphics/Wayland), though work has been done getting Wayland compositors and other software to work on FreeBSD. I use X11 on my FreeBSD desktop. I'm unfamiliar with the current status of Wayland on NetBSD and OpenBSD. I expect X11 to live on for quite some time in the BSD world and among more conservative Linux users, similar to the situation regarding systemd in the Linux community, which was adopted by mainstream distributions and users but faced (and still faces) opposition from some users.
I doubt it's something that will be ready for 7.1 next spring, but it's nice to see that it's actually working.
WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd.
There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old.
Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among other things when it didn't work
Some relevant links for those curious about other people hitting into this:
https://www.foell.org/justin/simple-hidpi-monitor-scaling-wi...
Gnome team:
xrandr --dpi 100/eDP-1>My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?”
>Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.
The support of hidpi scaling is something Toolkits have to manage (on both Wayland and X11). On X11 all the necessary pitch information to do so is available via the xrandr extension.
One of my desktops uses 2x 4k monitors, is that hidpi? X works fine... X also worked fine on an older setup with 4 monitors.
Also, I don't know Wayland internals, but I'm gonna assert without proof that any low level graphics interface is gonna involve a framebuffer at some point...
You have a Microsoft Surfacebook, Chromebook Pixel, or Macbook with retina display, let's say at 300 DPI, and you try to plug it into a monitor that is 70 DPI. The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. This is because xorg is internally designed around the philosophy that every monitor will have the same DPI. There are tricks and hacks that teams, specifically I've seen the canonical team pull this off, where they can "trick" xorg into displaying properly with some minor visual artifacting. The last time I tested this was with Ubuntu a few years ago, back when Wayland support was "experimental" and I had this exact sort of setup, and Wayland was easily able to pull this off 100% better in every way because it is not designed around this limitation.
In your example, I imagine everything would work just fine, but images will be physically bigger on the 70 DPI monitor because, well, the pixels are bigger. I'm guessing that Wayland adds a layer of indirection, resampling the framebuffer based on the DPI to preserve the same point size across displays with different pixel sizes.
I ascribe to "the end user is always right" philosophy, so, if you want that functionality, you should be able to have it. But I wonder how popular that desire is. It's far from universal.
Personally, I find resampled images to be so distracting and distasteful that it makes a computer hard to use for more than a few minutes. I hate fuzzy text, fuzzy windows, and fuzzy pixels. Any time I've been forced to use a device at something other than its native resolution, I've gotten preoccupied with "how can i fix this ugly crap" until I get native resolution working, and I'm sure I'm not alone.
It's cool that Wayland does that for you, because you want it, but consider that to others, it might be a bug, and not a feature. :)
"On a Wayland display server, each connected monitor will have a scale that depends on the DPI. A scale affects the scale clients draw surface contents when they are visible on said monitor."
So it seems like it actually modifies the drawing at the application level rather than rescaling it like an image.
X also supports exactly this. Qt uses this information. gtk doesn't for whatever reason, forcing the workarounds.
Most the so-called "X limitations" are actually just toolkit bugs if you get into the weeds.
What complaint? Why do you think I'm complaining? I wanted to know what's so fundamentally wrong with X to warrant a massive developer effort to replace it.
Based on the comments here, I have my answer: Nothing's wrong with X. Also, something lighter weight is desired for embedded platforms.
Some fraction of the population, like you, wants their display system to render in terms of points, not pixels. To me, and many others, this would be hell, but hey, different strokes for different folks -- good software does what the user wants, not the developer's will.
> ...majority of users that want sane...
You troll. :P I think the majority of users want sane display systems that don't resample and change resolutions away from the native resolution of the hardware. To you, the majority of users want fuzzy text and ugly UIs. We're both wrong to assert this as some obvious fact, because neither of us speak for any user but ourselves!
If I have any complaint (which, again, I'm not sure if I do!) it's that I don't appreciate my reliable computing setup breaking just because some young developer decided the programs I use are "too old".
This does not work smoothly at all in X11. This is a mixed bag with Windows because of reasons that are well documented. The compromise chosen by Apple works reasonably well.
This is not about my personal preferences unlike the GP asserts, it’s based on observing hundreds of deployments in industry and academia - which both Apple and Microsoft are very much aware of - they don’t try to support these features for no reason at all. I personally don’t love the scaling done by Mac OS, and in an ideal world apps would just magically scale geometry and “do the right thing”, but that is a fantasy land and the best FLOSS unix has to offer with X11 does not meet a lot of users needs.
As for nothing wrong with X? Lol this is a display system that still does not have a sane unified way to prevent screen tearing - despite 30 years of shitty attempts.
Note that I am not talking about multiple displays, but rather a single display, but the user wants things to be bigger than they are by default.
I know this because have used all 3 major operating systems recently (MacOS, Windows 10 and Linux/Gnome) on plain-old 96-DPI monitors such that if there were any interpolation or scaling algorithm I would be able to see the effects.
On a monitor 1680 pixels wide, Gnome gives me a choice of the scaling factors 100%, 125%, 150%, 175% and 200%. On a monitor 1920 pixels wide, Windows 10 gives me a choice of the scaling factors 100%, 125%, 150% and 175%. Some apps are blurry as hell, but on both Windows and Gnome I was able to live my life using only those apps that don't have the blurriness problem, but then I am not forced to use old Windows apps provided or specified by my employer and don't need to share my screen (which I am told does not work yet on a pure-Wayland set-up like mine).
On Windows 10, I used Google Chrome, some apps such as Settings and Timer provided as part of the OS and VS Code. On Linux I used (and continue to use) Google Chrome, modern Gnome apps and Emacs. On Linux, I need to open Chrome with specific flags to get it to be non-blurry while the visual elements are a non-standard size, and I need an Emacs built from a git branch called feature/pgtk. Both apps have some bugs when used in this way, but the bugs are definitely live-with-able, and I expect the bugs to be fixed eventually.
This can be true only if you use a really narrow definition of "apps adapted for Wayland". For example, a viewer of png files may not be possible to adapt to wayland? A png file is just an array of pixels (typically without a meaningful dpi). How are you going to ever display it without interpolating and resampling?
The word "properly" here is quite subjective, though. I have a similar setup, combining monitors of different pixel sizes. It works properly with Xorg: When I move a window of size WxH pixels from one monitor to another, it remains a window of WxH pixels. A thin line of one pixel width remains so. A checkerboard pattern that tingles the monitor refresh rate remains so. This sounds like perfectly appropriate behavior, and anything else would be ridiculously inappropriate. I accept that this usage of "appropriateness" is subjective to a subset of people that includes me, but it may not be universal.
Whatever, this is such a thin point for Wayland: hey, you lose copy-paste, screenshots, xdotool and most of the apps you used before. But hey! you can combine monitors of different pixel size as if they had the same pixel size! See, the thing transparently re-scales your windows using cheap-ass bilinear interpolation so that they get the exact same size in millimeters! Fancy, isn't it?
No. It's creepy.
Wayland has had working screenshots, screen recording, clipboard functionality for text and arbitrary mimetypes, etc. for years on wlroots, GNOME, and KWin. It also has ydotool, an xdotool alternative. For pure keyboard automation it also sports wtype.
Which apps don't support Wayland? The only ones on my machine that need XWayland are some video games and FLTK apps like Dillo (I have to test with xwininfo since it's normally impossible for me to notice if a program is using XWayland). All GTK/Qt apps work OOTB on Wayland as a first class citizen, especially since those toolkits nowadays receive more Wayland testing than X11 since barely any current distros still ship X in their default installations.
Which Wayland compositor/version and GUI toolkit/library gave you blurry bilinear filters?
Bold statement. Citation needed? Debian does, and that's hardly a small percentage of market share. I guess if you include Android as a Linux distribution then you might be correct.
KDE upstream is also Wayland by default which is reflected in the KDE version of OpenSUSE, the Fedora KDE spin, and Fedora Kinoite.
Advanced mixed DPI also comes to mind.
Another is performance: Sway easily outperforms DWM/i3/AwesomeWM on most ARM devices when configured for minimal latency.
The real reason would be that X contains lots and lots of cruft which isn't used anymore and it made development&testing impossible.
Follow along this post and you'll end up with one case in the wild all by yourself on your own machine: https://theinvisiblethings.blogspot.com/2011/04/linux-securi...
Xace was designed to address the mess that is Xsecurity and using the SELinux sandbox for GUI apps, except Xace barely works for mitigating exploits well on the desktop; it's so finicky that Dan Walsh himself concluded that XACE does not work and instead opted to use nested X servers (!!): http://people.fedoraproject.org/~dwalsh/SELinux/Presentation...
>Follow along this post and you'll end up with one case in the wild all by yourself on your own machine
I know it's possible. The 'case in the wild' terminology is asking whether this was ever weaponized in an exploit. I don't recall X ever being an attack vector in the last decade or two. I guess there are more than enough ways to gain local root this class of exploits doesn't matter.
Now, I'm all for closing this hole. But there's something bad about a development strategy that finds things like this and DPI with multiple monitors very important - the vast vast majority of users only have a single monitor - and mostly ignored scenarios like remote desktop until 2020 or so - remote desktop always used by several orders of magnitude more users than HiDPI, and a little tiny bit more important with this mass pandemic going on.
Maybe that's why transitioning from X to Wayland takes more time than transitioning from python2 to python3, a well known example of successful migration.
So the reason for not exploiting X may very well be simply because there is an even easier exploit available..
So, to be blunt, this 'security feature' breaks a whole hell of a lot of use cases. If wayland wished to go down this route they should have displayed a prompt to the end user 'this application wishes to record the screen, that ok?'. The last time I made this point someone snidely informed me that 'this was not wayland's responsibility'. I'm sorry, if you break my use case you make it your responsibility!
It is true that it isn't strictly the responsibility of the Wayland protocol, the API functionality is still there just it has moved somewhere else where it's more appropriate.
This is completely false. X offers both nesting for full isolation and a concept of "untrusted" connections for partial isolation. This is the reason why ssh -Y and ssh -X are separate things.
These facilities could use a little love to make them user friendly, etc., but they're there and have been for ages (enabled by default around 2013, present before then).
X also supports advanced mixed DPI, providing all the information to the application to handle it as they see fit.
This is a great answer, thanks. Also, the comment about GUI isolation for security makes sense (though I suspect x11docker would solve the security issues as well). Seems like Wayland is on track to be a good solution for a niche use case.
Maybe when Wayland was started. But X.org is now effectively unmaintained and most of the core X.org developers are now working on Wayland. From the release maintainer of X.org:
So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse.
https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...
See also:
https://www.phoronix.com/scan.php?page=news_item&px=XServer-...
This implies it's a choice made in isolation, rather than with the matrix of WM features and hardware support driving.
People aren't "choosing" Wayland or X in large numbers. They're making decisions like "I'm using distro A which ships Wayland by default" or "I want a tiling WM and have nvidia hardware, so I have to use X".
As for systemd, it appears to be an entirely different type of transition. I won't go as far as saying it is unnecessarily complicated since many Linux distributions had a complicated startup to begin with. However, it is complicated compared to Net/OpenBSD. In contrast, I have always seen X as complex. It is easier to deal with these days since they have smoothed over the sharp edges, but I don't know if it is a case of those edges being sanded down or covered up. It also doesn't cover up the complexities of the many different toolkits one encounters, which you will encounter under X if you use older software.
True, but don't assume Wayland to be less complex [1]. It has a lot less features, sure.
Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were.
Systemd offers countless advantages over previous init systems: https://www.reddit.com/r/archlinux/comments/4lzxs3/comment/d...
I already disliked systemd on its own merit, but the condescending "if you disagree you're a troll or an idiot" attitude of its proponents really helped cement the feeling.
Sysvinit never got stuck in those cases because it never had service dependencies and thus never needed to have a constraint solver for the dependency graph... So could you honestly say that pain point was better?
>Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were.
Was bad faith, naive, and frankly... insulting -- so I just chose to ignore it.
My reservations are well grounded, and when ones concerns are echoed by ESR, Linus, and tytso, I don't think they can be dismissed so easily.
Certainly some people wanted features that sysvinit couldn't provide, obviously, because so much effort went into systemd. But surely everyone in this conversation is experienced enough to know that just because "lots of people" choose something, that doesn't always mean it's a good choice. :)
I'm still using sysvinit on my main machine, and on all "critical" servers not because I have an advanced use case requiring a specialized init system but because I have a simple use case and a computing philosophy that requires simple init system. I have a strong (I'll admit, borderline fanatic) affinity for the "unix philosophy" of accomplishing things through the composition of simple to understand and debug tools that do one thing, and do it well.
To me, SystemD is about as far as you can get from "do one thing, and do it well" and "simple to understand and debug". It's a monolith (right?) which is why it's not running directly on the hardware. Unfortunately, Debian now builds some packages that I use occasionally with SystemD specified during the configure stage, and I don't want to maintain my own packaging of tools with different compile flags, at least not yet. Presently, I solve this by having a separate VM for "all tasks that need systemd", but I hope to replace that with something lighter weight, perhaps containers instead.
SystemD provides some features I imagine most users want, and that I strongly see the benefit of, but for the vast majority of those features, those reasons I'd want to use systemd, I'd already solved it myself, through the composition of existing and simple tools. A good example is networking. My computer does exactly what I want it to do, every time, in all permutations of wireless, wired ethernet, wireguard, knowing to mount certain NFS shares when I'm at home, randomizing mac address in certain situations, knowing when &c. It's great functionality, and I got there over time by building simple and easy to debug shell scripts, which call out to tools like `ip`, `iw`, `wpa_supplicant` and reading from /sys/class/net.
I also don't use pulseaudio, as audio happens to be one of the subsystems I have strong experience with, and pulse is an unnecessary (and sometimes error prone) layer, considering I get along just fine with ALSA.
The one thing I'm jealous of is faster boot times. But I'll happily boot a few seconds slower in exchange for PID 1 being simple, and my other services being simple and hence easy to debug.
I don't think the opinions of ESR, Linus, and tytso are relevant here either as none of those people work on init systems. If you developed your own solutions with shell scripts, that's great for you, but I hope you can see how that doesn't work at scale in a big distribution. BTW systemd includes a lightweight implementation of containers so I also don't understand what you're talking about when you said you needed to then put it in a VM or container. The exact problem you're having can also be solved... by just using systemd. So it actually seems like you're making things more complex than it needs to be by jumping through hoops to avoid it.
Audio is also my expertise, and using just ALSA is an experience in pain. You need some kind of userspace daemon in order to get a good experience with that.
Also, does your system do logging before the file systems are mounted?
Sure, but systemd has quickly been adopted by the experts, namely the maintainers of every mainstream distribution. The people who maintain all of that infrastructure think it is much better than what we had before. That does say something about its quality.
> It's a monolith (right?)
That‘s a common misconception. You don‘t have to use all of systemd. And I am not talking about all of systemd, just the init system.
That also invalidates your point regarding networking, btw. You could keep using your setup with systemd.
I'm living a pretty good life without systemd, so it's clearly not necessary. I'm sort of willing to acknowledge that it fits some people's needs better than alternatives however.
systemd doesn't have the ability to cancel tasks from the console like other init systems do, for example when my laptop can't get a DHCP response from the network card that's not plugged in, so it's clearly stupid (and so is the init script or whatever it's called that's trying to get an answer from a not plugged in NIC, but that's a separate although related issue).
Yes, it does… not sure what you are talking about.
This has been going on for at least 15 years now. I've been through multiple cycles like this with different desktop environments and GUI toolkits. The churn is even much greater in the Javascript world where if you come back to a project you haven't look at in about 3 months, the first few hours you're just busy catching up with the rest of the world.
X comes from a time when GPUs were not even a thing, it’s current role on a typical desktop is basically just to be a middleman in the communication of applications and the compositor. Wayland cuts out this middleman, fixes unfixable problems in X (you can’t have displays with different DPIs), and is backwards compatible through XWayland.
There's an implicit assumption here, that one is even using a compositing window manager. I'm guessing that you do, and that's cool -- you do you! But there are lots of people, who, when sitting down at a fresh install of any operating system, start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of them, and about half of my peers do as well.
The first thing I do on Android is disable all the useless (imho) animations and effects, the same on Windows (back when I used Windows), and on Debian, where I have real control, the last time I saw a compositing window manager was I think 2006. I remarked "Ok. I guess this is for people who want their Linux to look like a Mac" and then promptly removed it. I have nothing against people wanting eye candy! Eye candy sells! But... don't pretend that it's a necessary, or even important feature.
> you can’t have displays with different DPIs
This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy.
What I think you mean is "Wayland supports point based instead of pixel based rendering", or "Wayland does image resampling for you, making it easier for people who don't want to use native resolution" (I don't know Wayland internals).
Anyway, I think this whole comment thread is both educational and disturbing. :/ There appears to be two camps, both of which are incorrectly assuming that everyone else thinks like them. I'm guilty of this as well. Other than the comment about security, and use on embedded environments, all of the "features" that Wayland offers (according to these comments) are, from my perspective, things I would turn off because they'd get in the way.
And I will follow your suggestion, and sometime soon set up a VM, and try to install Wayland and whatever the current whiz bang desktop environment is.
That’s just one part of what a compositor does. I assume you prefer watching videos without tearing and those are really apparent with Xorg without a compositor — something solved entirely by wayland’s “every frame is perfect”. Even on window managers like sway which has absolutely no animation or eye candy. Android also uses composition even with animations turned off.
I’m not sure we mean the same thing with multiple monitors having different DPI settings. X can’t really handle different screens — it will create a huge framebuffer of all of them together and draw on that. So if you have a high DPI and a “regular” monitor, content will appear right on the regular one, but overly small on the other. If both screens have the same DPI, X can also render at eg. at 2x size.
And thank you for trying it out, X is indeed a cool project that spanned 3 decades. But due to the very major improvements in the underlying hardware, its abstraction is simply not up to date.
Of course! I hate tearing, just as much as the next guy. However I honestly haven't seen any tearing in video watching under Xorg, anytime in .. I donno .. at least the last 6 years. And this isn't exactly a powerful machine. :) If I have a video windowed and I move it around while playing, I can see a bit of tear. But.. I don't do that. Most of the time if I'm watching a video it's full screen. It looks perfect.
I bet the tearing you've seen using Xorg is attributable to something else. I remember back when video kinda sucked (in anything other than mplayer) but that was years ago. I have a windowed Netflix playing video as I type this and nope, no tearing. shrug I see in the Xorg.0.log that the COMPOSITE extension is loaded, but I'm not running a compositing WM, nor am I running a stand alone compositor.
I think we can put this "Xorg video playback has tearing" myth to bed.
It was certainly true back when suspend and resume didn't always work right, but that was quite some time ago. Having read much about Wayland in the last few hours, I think a more accurate thing to say would be "In Wayland, there is never any tearing. In Xorg, you can have tearing under some conditions" There are some very compelling reasons to be interested in Wayland that don't require exaggerating Xorg's failings. :)
> X can’t really handle different screens — it will create a huge framebuffer of all of them together and draw on that. So if you have a high DPI and a “regular” monitor, content will appear right on the regular one, but overly small on the other.
I think we have a different definition of "handle", and I apologize in advance for semantic pedantry. I'm looking at 3 screens right now, one of them is a 14" "4kish" (3200x1800). Xorg "handles" it just fine. As I drag a window to the highest resolution screen (which I have in portrait orientation and use basically only for coding), the content appears exactly as I expect it to. That monitor has a higher DPI, which means the pixels are a different size. It's not a bug... it's expected and desired behavior. Dots Per Inch. It's right in the name! If some software in the display stack was interpolating everything, making my text look fuzzy, now that would be a serious bug to me!
I really really think what you mean to say is "Xorg doesn't support rendering things in terms of physical size regardless of the underlying resolution." That might be true. Pleaseeeee say that instead. :) Personally, I wouldn't use that feature but I can imagine one desiring it.
But... when you say "X can't have displays with different DPIs" ... I mean this with no offense, but... you sound less intelligent than I'm sure you are. Because I can plainly see multiple displays with different DPIs right in front of my face. :) Xorg has been able to "handle" multiple displays since Xinerama, IIRC.
Anyway, I'm encouraged to take Wayland out for a spin for a reasons not mentioned in this comment thread. I like minimalism. :)
BTW, despite any appearances to the contrary, I recognize (and look forward to!) the superiority of an architecture based on fixed rate interrupts rather than a freewheel unsynchronized protocol. I was just afraid, previously, that:
1) All my stuff is gonna break! (Consider I've been using the same setup unchanged since the mid 2000s, and it's got a lot of self written code)
2) I'm gonna be stuck with a system I consider ugly!
3) My stuff breaking will be in exchange for nothing I consider worthwhile in return!
Now that I read the great article https://www.phoronix.com/scan.php?page=article&item=x_waylan..., much of my FUD has melted away. I know that #2 and #3 aren't true, #1 is probably true but now I'm looking forward to it.
Again, factually false. X has various synchronization options from the older double buffer protocol to the XSync extension to the GLX/DRI vsync commands.
I've also never seen tearing in X since like 2006.
Meanwhile, if you plumb atomic page flipping through the whole system and make it mandatory, the chances of having tearing are pretty nonexistent. But you have to drop legacy stuff from X if you want to do that.
Funny thing about that: if you want them to be scaled correctly based on different factors for each monitor, then you need a compositor...
You and I have an opposite definition of "correct" in this context, perhaps neither of us should use it! See enriquto's comment above, this is subjective. To us, we expect a window of size WxH to be WxH pixels, regardless of display. That's my definition of handling it properly, and when I use Wayland that's what will happen.
I will (grudgingly!) concede that perhaps it's not "universally and obviously correct" that things stay the same number of pixels, if you concede that perhaps it's not "universally and obviously correct" for windows to be drawn in terms of points and scaled behind the scenes.
Before this discussion I didn't have the concept of "scaling" my windows.. because that doesn't make sense to me, and it's something I'd never want. So my scaling factor for everything would be 1. Given that, Xorg "scales" perfectly.
No, you don't. And using a naive compositor is liable to make things blurry compared to the direct approach (the application requests the physical dpi for its current location and changes its vector drawing).
About its current role, there is a famous talk by an ex-Xorg developer that explains it well. Very crudely, a wayland compositor relays events to applications, which signals when it’s ready. Xorg on the other hand does these as well, but sits between the compositor and the clients, relaying their messages with some delay (and not having a concept of every frame is perfect)
Xorg doesn’t have support for mixed-DPI monitors, as it renders to all screens simultaneously with a single DPI setting. This is pretty much unfixable, it is so inside the core of the whole thing.
And finally, Xwayland exists and it is backwards compatible to the most part (other than manipulating wayland clients as if they were x ones, but that is also a wanted “functionality”). These are pretty much just nested x servers, so I don’t see how is it false?
Compositors are an optional component. I have never run one myself since they don't add anything of value. So any time someone says "the X server only talks to the compositor" I'm like "lol what compositor".
But even if you have one, it is still wrong. You have to understand that GUI applications are a LOT more than just low-level rendering. So even if you didn't need it for that, there's so much more going on that the server still plays its role in like coordinating copy/paste, drag+drop, hotkeys, notifications, etc., etc., etc.
And it isn't true that everything goes through the middle man. A graphics-heavy X application actually tends to work very similarly to a Wayland application (not coincidentally - as people love to point out, a bunch of the Wayland devs worked on the gpu rendering parts of X before): you get a direct render context, write to a buffer, then inform it to draw it. See more https://keithp.com/blogs/dri3_extension/
Mixed DPI is fully supported by the system, but may be buggy in applications. See here http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/ you can get information and handle it client side for maximum quality, or do auto-scaling for easy support bridges. KDE and Qt manage to do it. So much for "unfixable".
Can't you see how this is self-fulfilling though? People don't use X compositors because they suck and cause issues, so then you have people saying they don't use it because it doesn't add value. Well, yeah, compositing in X is bad and really convoluted and causes issues because X is not built for that, that's why they had to make Wayland to fix it.
"copy/paste, drag+drop, hotkeys, notifications, etc., etc., etc."
The first two, yes, the rest of it not so much. The X server is quite bad when it comes to managing hotkeys or notifications or doing any of that stuff not related to window management and input, most of those uses have been replaced with D-Bus.
"A graphics-heavy X application actually tends to work very similarly to a Wayland application"
Yeah, using extensions that were made way after X was designed.
"See here http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/ you can get information and handle it client side for maximum quality"
This article goes around every so often and every time it does, I have to point it out: Randr is not enough information to do mixed DPI. There is a reason the suggestions in that article have not been taken seriously. See this MR if you want more info on what actually needs to be done in the server to get this to work: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
It's for Xwayland but similar things need to be done if you want it to work correctly on the Xf86 hw. And also, you would still need a compositor for this.
I enjoyed reading that link -- a fact oriented list, directly answering my question, rather than an assumption that I want eye candy or resampled resolutions. Fixing the input subsystem alone feels like a compelling reason to use Wayland. It's also interesting to me that the list doesn't mention DPI, which seems to be of great concern here. :>
Having read that, I'm much less terrified, though it does mean I probably will have to take the time to write a window manager for Wayland. Thanks!
From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves.
Imagine two cars: X11 its an old one, it doesn't quite start right, the windows are chipped, the paint is peeling of and no one really wants to invest money into maintaining it, it defaults to brakes and a steering wheel from 1980 but has seen continous upgrades over time and you can generally swap in a steering wheel from 2010 with minor problems.
Now imagine wayland, a brand new tesla, it doesn't have brakes or a steering wheel because history has shown that these concepts evolve and if anything it should be a third party provider that creates them. Who cares that it took ten years between the release of the car as ready for use and the first compatible steering wheel implementation? Who cares that getting it to run on half of the roads (NVIDIA) is still not a solved problem because they stripped out any abstraction.
> From reading the sibling comment, if BSD guys want to keep using Xorg, they'll probably have to maintain it themselves.
As opposed to wayland which pushed 90% of features on the KDE/GOME/etc. guys (to be reimplemented in dozens of incompatible APIs). Of course the people who wrote wayland also wrote X11 so removing themselves from the equation might have been the nicest thing they ever did, given their own opinion of their past work on X11.
a) nvidia's refusal to implement GBM in their driver was their own choice. The abstraction was never removed; GBM is the abstraction over all drivers.
b) nvidia already relented and implemented GBM in their driver.
The latter doesn't necessarily mean nvidia is a good choice of GPU even now, because it requires a proprietary driver, so compositor / Mesa / kernel devs cannot debug the full stack when anything goes wrong. So having your problems ignored is something you'll have to get used to if you choose to use hardware that requires proprietary drivers, regardless of whether you use it with X or wayland.
>As opposed to wayland which pushed 90% of features on the KDE/GOME/etc. guys (to be reimplemented in dozens of incompatible APIs).
wlroots exists to solve that problem. Whether an individual compositor decides to use it or not is up to the compositor.
At least in KDE's case, wlroots did not exist at the time they added Wayland support so of course it's understandable that they don't use it. There's a fork of kwin that uses wlroots ( https://gitlab.com/kwinft/kwinft ) but I believe it's just an experimental one-person effort rather than anything that kwin devs are working on as a replacement.
>Still not going to amputate my leg over a stubbed toe even if RMS considers the toe cancer.
I didn't say you should. I worded what I wrote specifically to indicate that I'm not passing any judgement on whether you made the right choice or the wrong choice.
There are many people who bought nvidia GPUs because they worked fine, and were rightfully worried that they'd stop working fine if their DE of choice decided to switch to wayland or became abandoned. I empathize with their situation completely.
All I'm saying is that you made the choice to buy hardware that requires a proprietary driver, and so you have to live with the consequences of that choice. This is not something unique to this situation involving nvidia GPUs. Only you have the right to decide whether it was a good choice or a bad one.
The problem with nvidia on linux isn't wayland, it's nvidia.
Based on what? Because I rather believe its maintainers..
>If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles — but you’d be able to shift gears with your car stereo. Useful feature, that. - Marus J. Ranum, Digital Equipment Corporation
You mean under “they” the linux kernel devs? Because it has absolutely nothing to do with wayland. Nvidia cards’ proprietary drivers work with X because you are using a part-binary blob for X. Also, finally nvidia realized that they should goddamn support linux, so what all these resulted/will result in is better integration for people with nvidia cards.
I don't think life support is appropriate here. It still works well.
And that is not a negative about web browsers or all the things we're doing with them. Just to be clear.
Edit: Also I'm pretty confused as to why anyone refers to X as "multi-user", are you talking about multi-pointer X? That doesn't really have anything to do with X in particular and is also possible in Wayland.
Fonts from one machine Window management from another An application running on yet another, with it's program data sourced from yet another machine accessing data on still another machine. All of which is displayed on another machine also supplying user input.
Or, I could do something crazy like put a window on your display, with appropriate permission of course, and you could interact with it.
A big wall type display could take windows from a number of users.
The promise back then, and something I used a lot, an many still do use today, is being able to run something and display it somewhere else. Say my cellphone is on my desk. I could ask it to do something for me, and the window into that activity appears on the display like any other window does.
Another case might be several users running on one machine each with their own displays and inputs.
Here is a real world case:
High end CAD software, managed data, many users.
With X, one can make a big application server and that is not visible to users at all in terms of the application or data to be manipulated.
Users run the program via X, running X servers on anything they want. PC, Mac, Linux, whatever.
The only way to interact with the managed data is through the application.
One copy of the application, one data repository, many users.
With X doing that kind of thing is easy, and it works whether one user runs the app on their local machine attached to a shared data repository, or many users run on a remote machine perhaps that machine itself also holding the data repository.
The only exception is this:
"Another case might be several users running on one machine each with their own displays and inputs."
This would be multi-seat which doesn't really have anything to do with the display server. It is implemented in udev and logind, which spawns additional X or Wayland servers for each additional "seat".
2. X11 does lack critical features that lots of users need: GUI isolation (a very basic security measure that's otherwise been standard practice for decades), mixed DPIs, and perf on low-end ARM devices (compare Sway with dwm/openbox/i3 on a rbpi or pinebook and the difference is kinda shocking).
Factor all this into account and I'd be interested in seeing an X setup without screen tearing that performs at least as well as Sway on a Pinebook or a rbpi.
I have never seen any screen tearing in my life by the way. Despite I have always been generally using decade-old PCs with lowest-end (mostly built-in) GPUs and Raspberry Pi is the only way I watch TV. The only annoyance I have with Raspberry Pi is YouTube the website (not the actual video, it plays Ok) being rather slow.
The delays and latencies for me have been noticeably lower when using Sway on ARM, which is quite surprising because I was expecting the opposite. I hadn't even tuned it for low input latency yet.
I see. Curious that I have never noticed anything like this though. I have always been disabling compositors as I realized I don't really care if my panel is transparent. Perhaps the problem just doesn't affect Intel graphics (Raspberry Pi browsing is slow anyway so fast scrolling just doesn't exist there).
UPDATE: I've just realized I've actually seen screen tearing many times - always within specific Windows apps ran with Wine, e.g. Total Commander.
You're also massively overstating the complexity of an X server. Writing X servers that are advanced enough to be usable is something a lot of individuals have done. It's nothing like matching a modern browser. Incidentally, if I were to try to do this today, I'd gut a proxy like Xephyr and make it rootless to support older clients, and make the main server itself only support the subset of the X protocol modern clients speak.
If so, why are we observing apparent shortage of developers to maintain the actual Xorg? I can't believe there are no people interested in maintaining it in the whole world. I thought it's so complex it just requires much more expertise and dedication than anybody is ready to invest.
E.g. support for a bunch of backends of which most are not worth supporting if you want to implement a server from scratch, but which Xorg has been saddled with, as well as support for a bunch of legacy X functionality that nobody would bother implementing if implementing a server from scratch because most clients never use it.
E.g. a major source of complexity is supporting various X visuals that are irrelevant today when you can decide to only support truecolor natively. Another is support for a bunch of drawing primitives that you might as well just ditch all but the very simplest of, and support for legacy clients via a proxy like Xephyr. That said, most of those drawing primitives are also supported by any 2d canvas style library like Cairo or Skia that does client side 2d rendering, so if you want to implement them for an X server, just picking up one of those libraries would be time far better spent than implementing it yourself.
It'd certainly be a lot of work, and a lot more work to write an X server from scratch that is a complete replacement for e.g. Xorg - you'd need to support a number of X protocol extensions, but most clients backends will fall back on core functionality if extensions are not available (you'd definitely want to support some of them, like Xrender and SHM though, or your server would be largely unusable with modern clients).
At the same time, if someone wants to write a new X server, it'd be silly to do the work of writing their own backends when the could just grab wlroots and build an X server on top of that. "Modern X11" can be reduced to a relatively narrow superset of Wayland functionality if you defer most of the weirder legacy functionality that is rarely but very occasionally used to a proxy like XWayland, Xephyr or XPRA (all of which do, that said, rely on Xorg code) and make people use those for clients that need it.
Honestly, I think this is the most likely/viable future for X on Linux. It'd drastically reduce the amount of code to maintain and share that burden with other projects, and would make it far more viable to keep maintaining X support for those of us who wants (part of) it.
But what you list is not enough, though. There are enough extra bits that goes well beyond what Wayland provides today, like ability to write a standalone wm without having to build a whole compositor, for example, that you'd end up with something quite substantially unlike Wayland if you went down that route and looked at which pieces of X11+extensions people are actually using. It'd be far less than full on legacy X11, but far more than just Wayland.
It doesn't matter if it's not X. Nobody but extreme purists would care if it's not exactly X. What will matter is if you lose capabilities.
E.g currently my preferred wm (bspwm) doesn't have a Wayland alternative, so a Wayland compositor isn't a viable option for me without changing my workflow. Sway might be nice, but it's different and I have no compelling reason to put in the effort to make a switch until running Xorg starts becoming problematic. One day, maybe I'll feel compelled to switch but it won't be soon.
Even so, Xorg will hang around for decades in the form of XWayland because of old X apps people still use (e.g. none of the terminals I have installed on my system except for gnome-terminal supports Wayland).
If you liked bspwm then you might want to try this: https://github.com/riverwm/river
> If you liked bspwm then you might want to try this: https://github.com/riverwm/river
If I wanted to spend time redoing my configuration, maybe, but I have better things to spend my time on. So in however many years it takes before getting Xorg running starts taking more effort than switching. I'm not expecting that to happen anytime soon.
https://gitlab.freedesktop.org/xorg/xserver/-/issues/386
https://gitlab.freedesktop.org/xorg/xserver/-/issues/333
https://gitlab.freedesktop.org/xorg/xserver/-/issues/380
https://gitlab.freedesktop.org/xorg/xserver/-/issues/249
https://gitlab.freedesktop.org/xorg/xserver/-/issues/260
https://gitlab.freedesktop.org/xorg/xserver/-/issues/258
And I'm sure you could find plenty more. All this stuff is fixed or is trivially fixable in Wayland, by the way.
"If I wanted to spend time redoing my configuration, maybe, but I have better things to spend my time on"
I don't understand, you were just talking about spending significantly more time rewriting the X server...
It works fine for me. I gave my reason for why I won't consider switching to some Wayland compositor. None of the bugs you list affect me, so your suggestion I look at a Wayland compositor which would require me to spend time changing my entire config only to be left running XWayland anyway because the terminals I use are X11 based.
It would be a massive waste of my time for no benefit whatsoever.
And this is why X will stay around for a long time: There are lots of us with dependencies like this and no reasons to change things until things starts breaking.
> I don't understand, you were just talking about spending significantly more time rewriting the X server...
Read again. I have not once suggested I'm planning on rewriting an X server. I pointed out doing so would have been a better choice than starting over from scratch, and that the choice to start over from scratch is the reason people are still sticking with X.
"I pointed out doing so would have been a better choice than starting over from scratch, and that the choice to start over from scratch is the reason people are still sticking with X."
I would urge you to look into how much work it would take to actually fix those bugs and push out incompatible server/libraries/etc to people and then come back and see if you'd like to revise this statement. Because that is what we are looking at here. Remember what you are asking here is for every toolkit and program to do a "if x12 then dostuff elseif x11 then do otherstuff" and weigh that versus "if wayland then dostuff elseif x11 then do otherstuff".
> If you only care about bugs that affect you then it's not even worth having a discussion about this, you can't expect everyone to wait to make changes until it's personally convenient for you
I'm not expecting anything other than to keep using the software which works for me. I'm not the one arguing for people to change setups that works for us. Use what works for you. If that's Wayland that's your choice. For me it's not - it involves putting effort into something that doesn't give me amy benefits. Nobody is arguing for you to do anything or not anything.
> I would urge you to look into how much work it would take to actually fix those bugs and push out incompatible server/libraries/etc to people and then come back and see if you'd like to revise this statement.
No, I wouldn't like to revise that statement, because none of the bugs are relevant for an updated protocol unless you choose to keep the things that are broken, since the "worst case" is to throw away and start over the same way Wayland did.
> Remember what you are asking here is for every toolkit and program to do a "if x12 then dostuff elseif x11 then do otherstuff" and weigh that versus "if wayland then dostuff elseif x11 then do otherstuff".
And it's obvious that the number of if x12 then dostuff would have been far smaller and/or amortized over longer time because you'd only need them in cases where you actually introduced a breaking change that couldn't be fixed by using functionality that would keep working the same on both.
Most modern X11 apps already don't use most of the functionality of X that is worth deprecating, and for many of those who do the solution would be to change to a request that'd be worth keeping, not to add an if x12. E.g. as I mentioned there are a number of different ways of rendering text with X. The most popular terminals are split roughly in two broad groups: Those who use the old server side rendering, and those who use XRender (a couple of outliers use OpenGL). Most of the ones I've looked at use Xlib etc. directly rather than toolkits, though some of the font stuff in Xlib is wrapping the server side functionality in ways that could be retargeted to use Freetype.
If you remove the former, then ~half of the terminals would need to get updated to use the latter method or forced to use a proxy (ditching most of them isn't really an option - many of the most feature-complete ones use X directly, and all of the ones I have looked at have users who swear by them and will keep using them until there is a feature complete replacement; many of them are decades old and their users still don't agree there's one worth switching to) or client-side reimplementation of the font rendering. But assuming you were to retain the XRender glyph rendering you wouldn't need to special case for this hypothetical x12, just upgrade apps to use XRender, and you could yank out all the font support in the server. Moving to Wayland on the other hand requires all of them to change
To date most of the terminals I've looked at haven't been updated with Wayland support, and many probably never will, making XWayland and so most of Xorg still hang around as long as they have users and someone cares. Given how long many of them have survived, I'm guessing you'll have to wait for their user bases to literally die out.
The X12 approach would have allowed starting to actually deploy the improvements stepwise more than a decade ago. Or more. E.g. the XFIXES extension happened in 2003 and was the first real attempt at some somewhat potentially breaking changes hidden behind an extension flag rather than a version change (and didn't allow the server to actually ditch the old code). Nothing other than politics stopped a more drastic approach.
This notion that there were technical barriers stopping an iteration of X is pure fiction.
You're right, compositors weren't a thing, but we're also talking CPUs several orders of magnitude slower, and where the blitter capabilities of what passed for GPUs had a throughput magnitudes slower than what my cellphone has today.
The difference will widen as Vulkan support in Wayland compositors seems to be outpacing the X equivalents; modern GPU development is starting shift away from OpenGL
Are they SO slow on the tasks they are not optimized for they can't even beat a 25-year-old GPU like S3 Trio?
> I'd imagine that running a current distro with a current X WM wouldn't be a great experience on 90s machines.
Why does it have to be? What do we get for this cost? The only things in which I would find a modern Linux better than a 90s Linux are full UTF-8 support, modern crypto and hardware drivers availability.
> The difference will widen as Vulkan
I don't know a single person (among many dozens of Linux users I personally know) who would need it. I can only imagine movie makers using Blender or something like that
A lot of exploit mitigations, especially spectre/meltdown mitigations, allocator hardening, auditd, toolchain hardening flags that introduce runtime checks, syscall filtering, etc. have introduced major slowdowns. I'm sure this isn't the only reason, but it's the only reason I am familiar with. Ask someone familiar with a different sector of osdev and they'd probably rattle off a few more.
I have noticed that lots of tasks that would be fast a decade or two ago are slow today on a rbpi: tasks like switching workspaces, switching browser tabs, etc. have noticeable delays. Sway makes switching workspaces and some window management functionality nearly instant in comparison. I've compared it with i3 and openbox; others have compared it with dwm. I'll see if I can find a link.
A lot of tasks become faster with GPU acceleration, which is why OpenGL and Vulkan accel are helpful.
i3/dwm (or any X window manager), unlike Sway (or any Wayland compositor) has nothing to do with client window contents rendering. X and Wayland works fundamentally differently in that respect. Under Wayland the compositor and wm is the same. Under X the server and wm are separate programs in separate processes, and the latter is not involved in rendering the client window contents, only the window chrome, if any.
Meanwhile, I often don't need any network connection (when coding, watching pre-download videos, or running data/number-crunching or build scripts). Can I expect 90s-like efficiency if I disable all the mitigations and hardening stuff?
That being said, one writeup explained how disabling several mitigations improved http server perf by several factors: https://talawah.io/blog/extreme-http-performance-tuning-one-...
You must confuse something here - wlroots recently got a Vulkan backend, meaning you can run it on top of Vulkan API.
It has nothing to do with what Graphics API the clients will use.
I'm not aware of GNOME or KDE having similar improvements on their X backends or the same happening for X WMs.
You're probably right that a modern X server optimised for modern PCs won't run well on those machines, but the point being that this has little to do with X the protocol, and everything to do with the implementation of the X server and to a certain extent with clients being optimised for different performance characteristics.
As for Vulkan, there's no reason you can't use Vulcan with X. It's again an implementation question, not a protocol issue.
Now, the X protocol is awful, to be clear. There are plenty of issues with X that were worth fixing. But the time it has taken to get Wayland to a usable state (many would argue it still isn't - I certainly have no interest in running Wayland other than with XWayland possibly given the current state) suggests that opting to start from scratch instead of upgrading X step by step was a relatively poor choice - the X protocol is easily upgradable.
Also I think it should be obvious by now that upgrading X step by step isn't viable anymore. That was already tried for 30 years and reached its limits of what you can do without breaking the core protocol, which Wayland has already demonstrated how most of that can be discarded.
Redraw time when the systems were slow enough to for the client app to not be fast enough to render the content, sure, there's no way of avoiding that. But again that is not a protocol issue. Wayland can't help you with that. Blitting the graphics onto the screen was back to being limited by the hardware from MIT-SHM arrived ~'91.
> Also I think it should be obvious by now that upgrading X step by step isn't viable anymore. That was already tried for 30 years and reached its limits of what you can do without breaking the core protocol, which Wayland has already demonstrated how most of that can be discarded.
Upgrading the core protocol has hardly been tried. What has been done is piling on extensions - ironically exactly the same mess happening with Wayland to try to get back to reasonable parity with X. But even most of those didn't go very far. E.g. none of them tried stripping out more than a tiny subset of legacy stuff.
The very first message an X client sends includes the protocol version. Nothing stops you from starting by bumping the major protocol to 12, removing whatever you like from the protocol if a client connects and asks for 12, and upgrade Xlib to ask for 12 first and try again with 11 if the server barfs. Nothing stops you from making a version of a server that just refuses to let clients asking for 11 to connect, and defer those to requiring a proxy to translate/implement whatever you strip out if you care rather than upgrade the clients.
I understand why people got fed up and did Wayland instead, but that was largely organisational, not technical.
If there had been the will they could have done a dozen iterations of the core X protocol in the time it has taken to get Wayland reasonably usable and removed things piece by piece instead. To take a concrete example, there are about half a dozen ways of rendering text in X. Nothing would have prevented saying that X12.0 has XRender by default so you don't need to query for it, and that no other text-like rendering operation than RenderCompositeGlyphs8/16/32 is supported and just yanking all of the font code out of the server. If anyone cared, taking the old code and implementing a client side library providing the old string drawing functions would keep compatibility easily enough.
Nobody seriously tried doing this, because the politics of it was maintaining full backwards compatibility or building something new.
Wayland was a technical solution to a political problem. Frankly a fork and iterating would have likely gotten buy-in much faster.
The rest of your comment doesn't really make any sense to me. Somebody could make X12 but I'm sure you understand that doing that would have all the same technical/organization challenges as Wayland. I don't know why you would think making an incompatible fork of the X server and then trying to convince everyone to use it is a simple endeavor, it's not. There is zero will to actually do that, I've heard similar suggestions to make X12 for the last 15-20 years, and nobody has ever cared enough to do it because the only reason anyone ever uses X is for compatibility with old software. Once you take that away, there's nothing left. The closest existing thing to an X12 is, well you guessed it, Wayland.
Nobody is talking about double/triple buffering every client, but the final composited surface.
> you are getting into an area where there are accelerated graphics and where fullscreen compositing isn't going to be a performance issue
Double-buffering was viable and done on quite a lot of 1980's hardware. The point remains that this is not a protocol issue.
> Somebody could make X12 but I'm sure you understand that doing that would have all the same technical/organization challenges as Wayland. I don't know why you would think making an incompatible fork of the X server and then trying to convince everyone to use it is a simple endeavor, it's not.
I didn't suggest it would have been simple. I suggested it would have been simple than a well over decade long effort to write a new system from scratch.
The point being that the reasons for the existence of Wayland are not technical, but political, due to the lack of willingness in the Xorg core team to break compatibility at the time. And we're still paying the price.
You are presenting this as if it's some kind of decision between "break compatibility" and "start from scratch" when really those are a lot closer than you think. Realistically, most of the X server is still overdue for a major rewrite/refactor. But I really doubt anyone would ever volunteer to do that work at this point.
There may certainly be cases where it'd be harder to avoid, but realistically this hasn't been a problem for most X users for decades. Of course I'm not doubting that it is a problem for some, but it's not for me and haven't been since the 90's.
Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, the Andrew Window Manager, and NeWS, and an old friend), who explained the 80's era X-Windows hardware model and war on drugs quite well here:
https://blog.dshr.org/2018/05/recreational-bugs.html
>"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami.
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
>The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python’s “Cheese Shop” sketch, or a grail seeker in “Monty Python and the Holy Grail.” Even the simplest applications must answer many difficult questions:
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
root = RootWindow(display, DefaultScreen(display));
win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1,
BlackPixel(
display,
DefaultScreen(display)),
WhitePixel(
display,
DefaultScreen(display)));
(the next client tries to connect to the server)
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
cmap = DefaultColormap(display, DefaultScreen(display));
favorite_color = 0; /* Black. */
/* Whoops! No, I mean: */
favorite_color = BlackPixel(display, DefaultScreen(display));
/* AAAYYYYEEEEE!! */
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
struct XVisualInfo vinfo;
if (XMatchVisualInfo(display, DefaultScreen(display),
8, PseudoColor, &vinfo) != 0)
visual = vinfo.visual;
/* Is that a SubstructureRedirectMask or a ResizeRedirectMask? */
(server dumps core & falls into the chasm)
I'm aware it ran on mid 80's hardware, but I didn't personally have experience with X that far back, so I stuck to what I knew for a fact it handled fine :)
> WHAT IS YOUR ROOT?
A lot of these are macros in Xlib that obscures that they're "just" looking up things in the display info returned on opening the display, though.
The X protocol is messy in places, but Xlib is far worse than necessary. I'm currently toying with a pure Ruby X protocol implementation (client side only; "why?!?" I hear you ask - I guess I must be a masochist; the real reason is that I'm writing a terminal in Ruby and the C extension annoyed me; I only need a small subset of the X protocol in any case; the reason I'm writing a terminal is that I'd like to experiment with terminal extensions to integrate with my editor - also in Ruby - turtles all the way down... I guess this just conclusively proves that I'm a masochist), and thus was forced to learn that the initial display info returns the list of screens and the root, and the black pixel value and the white pixel value.
So there's no good reason for the client to keep being this complex other than inertia - few people write applications directly to xlib and so there's little incentive to make it better.
There are lots of things in X that would be nice to ditch, though. I just wish there'd been a more gradual approach.
In fact, I've seen some want to keep maintaining Xorg - if someone ends up doing so, I'd strongly recommend they'd take the Wayland approach of a rootless X server for legacy clients, and then doing a review of clients and aggressively deprecating features which are mostly unused by modern clients.
EDIT: In fact, an X proxy that re-implements deprecated features would be very simple - it "just" needs to understand enough of the protocol to pass on packets it doesn't want to handle, and to rewrite sequence numbers if needed. Then it could do nothing if it connects to a "legacy" X server, but intercept requests when connecting to an upgraded X server. There are already several X proxies of varying capability that could serve as a starting point - e.g. Xephyr and Xnest.
I learned that the hard way when trying to figure out how to use Display PostScript with CLX in 1992, which is an X client library written in Common Lisp.
Few people still write applications directly to XLib, but many do write applications directly to toolkits and libraries that DO depend on XLib.
So we're all stuck with XLib from now until eternity. If you replace it, you lose the entire ecosystem of client side extension libraries, so you have to reimplement them all from scratch.
At the time, that was a no-go if you wanted to use Adobe's proprietary Display PostScript extension, which was quite popular and included with most commercial X11 servers of the era. Even if most important X extensions are open source, how about about them NVIDIA drivers?
Display PostScript is simply an old example from 1992 of what I mean, that I wanted to use from Common Lisp via CLX, but couldn't. But it shows how this problem has been around for a long time, and is never going away. The only viable solution was to dump CLX and call XLib and the Display PostScript extension libraries directly from Lisp through a wrapper layer.
But now the problem with clients and toolkits depending on X11 extensions is much more entrenched, not just limited to high-end exotic graphics-rich apps that want to use Display PostScript to draw a nice pie chart.
That's because of how heavily all modern X11 toolkits and clients now depend on a plethora of X11 extensions and their XLib-based libraries -- just to measure the display, shape windows, listen for input, memory map pixmaps, and composite the first pixel on the screen -- because they've long since abandoned X11's horrible old built-in pixel-based rendering API, broken font model, leaky input system, etc, and switched to using full stacks of X11 extensions (via their XLib based libraries) instead.
Then Wayland will be more a nightmare still, since they moved everything but core rendering into extensions and say "just use wlroots" to deal with it.
And for my use I only need to support about a dozen requests types, and no third party libs, so it's not that bad. My starting point only linked with Xlib anyway, nothing else, and I verified which requests Xlib actually sent via xtruss before I started.
But of course, that's because I only want to actually use it for something very simple. If I wanted to do something more complex I'd wrap a higher level library instead.
1.: https://github.com/emersion/hello-wayland/blob/master/main.c
Well actually it's the reverse: the more abstractions were put into toolkits, the more it became obvious that there was little reason to use everything in X11.
That's also exactly what most modern GUI toolkits do when they run on X11.
Doesn't the server tell the client what to render, and the rendering happens on the client? Why would that result then be shipped over the network?
* http://inclem.net/2021/04/17/wayland/writing_a_wayland_compo...
Does this display server have any form of colour management for, you know, the stuff it's displaying?
Wayland is taking off like the Spruce Moose...
> Does upstream Wayland work on any platform except for Linux?
Yes, FreeBSD. Patches welcome to make it work on other BSDs.
> Does this display server have any form of colour management for, you know, the stuff it's displaying?
No more than X11 right now, ie. none. But it's in the works.
Also good news re colour management. The last I heard about this was Drew DeVault (and I'm paraphrasing) calling it "precious horseshit".
[0] https://drewdevault.com/2021/02/02/Anti-Wayland-horseshit.ht...
It has been "taking off" for 13 years at this point. It seems like it doesn't have much thrust behind it.
On the more minimal side to compete with X-based window managers: Sway is very mature and River is turning out nicely. All that's left is an Openbox alternative. I believe there are a few, but I'm not familiar.
Wayland has already taken off; once we get XFCE to switch we should be able to move on.
The X11 ecosystem is more than just GNOME, KDE and i3 and porting XFCE will not be enough to "move on" (For me it is the small things like Xdotool, Xsel, Xcalib, etc. that are holding me back). Maybe X11 needs to be replaced but Wayland is not the answer. It's just not good enough and because of fundamental flaws of its philosophical concepts it will never be.
The reason why major orgs have had to push for Wayland is the same as the reasons they had to push for HTTPS and TLSv1.2, unique passwords, keeping software up to date, etc: using outdated and insecure software with significant attack surface has real costs even if it's convenient.
HTTPS vs HTTP is a false equivalent. HTTP works just fine like before. X11 can be made fully secure (e.g. QubesOS does it) but nobody uses it because there is really no need on a FOSS system where 100% of clients you run are trusted.
HTTP also doesn't work as well as it did before: Chromium and Firefox have begun rolling out an HTTPS-Only mode that warns when visiting HTTP pages. The landscape has also gotten more hostile: many telecoms have been caught modifying unencrypted traffic. Vodafone was also caught HTTP CSP headers for ad injection.
Firefox devs have expressed interest in removing HTTP-specific logic from FF in the distant future too, with the HTTPS-only mode being the first step. All current browsers have also disabled obsolete TLS/SSL versions, which broke several sites during the initial rollout.
There is no such thing as a trusted client; plenty of FOSS has exploitable vulnerabilities. Rather than "trusted and untrusted" software, the cybersecurity crowd has shifted to thinking in terms of "untrusted and untrusted+malicious".
There's also a reason why software audits typically have their moment of truth during binary analysis, whether or not source code is available: source code is only part of the puzzle. Runtime behavior is influenced by the toolchain behavior, host OS behavior, shared libs, and a ton of other variables that are collectively harder to audit than a black box binary. FOSS' reasons for existing should be primarily related to freedom rather than security. I don't copyleft my work because it improves security, but because it protects users from further infringements upon their freedoms.
I'd suggest chatting up a security researcher or reading some material on modern approaches to exploit mitigations (source availability is not a replacement for exploit mitigation); I could give you some starting points when I wake up if you're interested.
Also, this is just patently false: “Like all things Wayland it's a mess with zero benefits for the user.”
Theoretically Xorg can be made fully secure: just isolate clients so they can only receive events and bitmap information from windows created on the same client connection. It would be relatively straightforward, if quite involved, to implement.
But nobody wants to implement it because everyone qualified to do so has jumped ship to Wayland. The X architecture is so fatally flawed that the most straightforward way to fix it is to start from scratch, and that's what Wayland is.
X is like global warming: one hundred percent of the people who are in the least wise knowledgeable agree that it is a problem. Unlike global warming, however, that problem has a fix: Wayland.
So just... shut up with the irrelevant bullshit and use Wayland, like all the Linux graphics maintainers and distro maintainers want you to do and have been telling you to do for years now... or find your shit unsupported.
There are still, to this day, tons of features which end consumers rely on that are still unsupported out of the box with wayland. If you're writing a replacement for x, it had damned well better have feature parity with x. Saying 'shut up and switch' is not an argument for switching.
Also, this sort of attitude is precisely why linux never took off on the desktop. Such arrogance.
I'm a happy Mate user and while there is ongoing work to move towards Wayland, it will likely take several years to complete.
So for the time being I keep X11 dear to my heart, and to be honest I'm not sure what I'm missing with Wayland (expert apparently problems with screen sharing applications that have not been updated to Wayland yet …). X11 + Compiz work fine for me.