I was in graduate school at MIT in 1984 when Bob Scheifler was originally working on the X Window System. I am not much of a visionary, and didn't understand much of his original conception, but in retrospect you have to give him an immense amount of credit for envisioning this system that has persisted for nearly 40 years. An accomplishment almost at the level of the creation of Unix itself, I would say, but vastly underappreciated.
Was at project Athena mid-80’s at MIT taking a class on X internals and probably ran into those guys. We did all of the work on DEC workstations running saber C as I recall.
Рік тому
This is yet another vague underappreciating video.
@@GodEmperorSuperStar I can't really tell you. I left MIT in August 1984. My impression was that Barbara Liskov's group had mostly transitioned to working on Argus roughly at that time, and I am not sure how much new CLU stuff went on after that.
Hi John, I guess it heavily depends on the desktop environment or window manager that you use; for instance, I found very little glitches when using Sway WM, but a whole lot of issues when using KDE + Nvidia proprietary drivers. There are so many layers in our current digital onions that sometimes our experience vary greatly from user to user even when using the same software and hardware stack, but mixed in a different way!
been using fedora with gnome on Wayland and amd igpu for a while now and I've had no issues. I definitely wouldn't call myself a "lightweight home user"
I'm running KDE Plasma through Wayland on Arch. Only problem I remember from the past year or 2 was an update breaking Kate text editor that was fixed next update.
I personally have been using Wayland with KDE as a daily driver for the last 2 or 3 months and my anecdotal experience has actually been great. I switched because I use a laptop with multiple monitors in two different locations via docking stations. I was able to get this set up and working with x11, but it was a pain. Wayland, on the other hand, just worked. I’ve also noticed it’s a much smoother experience in general. Between these tidbits and a much nicer codebase, I can’t realistically see myself ever switching back at this point. The only substantial issue I’ve had is that custom scaling can be a bit weird across multiple monitors of different sizes but this isn’t a make-it-or-break it thing for me. The text on my laptop screen, which is effectively a rarely-user 3rd monitor 90% of the time, is just slightly smaller than it would be in a perfect world. This I can live with
I'm also using a docking setup on two different offices with different external monitor setups. It worked great for me on X11 but on Wayland - which I committed to a couple of months back - the experience is not as smooth: mostly Plasma forgets my desktop configuration every few days, reverting to the default "folder view with default wallpaper". I stopped using widgets on the external monitors because of that.
I have been running Wayland on my main machine for development and gaming since Gnome 3 and I do not remember when I last had an issue with any of my various applications. Therefore, I consider Wayland is not only the future and presence, but even the more recent past of compositing under Linux.
Wayland is getting a lot better very fast. I tried wayland a year ago and rolled back. I tried it two months ago and I stayed. Especially on a laptop this lack of bloat allows me not only to have a better experience, but also save my battery. There are of course issues still - discord doesn't let me screen share, and funnily - telegram got worse when it switched from xwayland to native wayland (the mouse doesn't integrate, and you can't use the default system top bar), but they aren't enough for me to roll back like I did a year ago. So yeah, I too, from the very beginning, thought wayland is the future. I thought it even as I was rolling back to X11. It's just the matter of adoption by other software, but since it's clearly better it's only a matter of time. There are things you can't do on X11 because it's ancient and defunct, and there are things that you can't do on wayland because they aren't ready YET.
Nice, is one thing to read on the subjects and construct visual idea. Another coming from a view of a professional with past experiences. Thanks for your input on each subject. Love the microkernel video, Can't wait for nano.
I worked on a factory planning system back in the mid-90's that used X-Windows to interface with various X-terminals. As part of this we wrote a library of C++ classes to wrap the various X widgets. Good times... 🙂
Yes almost all games whether running through Wine or natively use X11. Luckily XWayland seems to be perfectly handling them, I play a lot of different games all the time on KDE Wayland and they all work how you would expect them to work. Great video :)
Thanks for the good explanation! I’m using Wayland with Gnome in Fedora and it works just fine for me, even with gaming. If any I’m only having sound issues, not graphics 😁
Thanks for the video. I always enjoy your breakdowns. I will stick with Xorg until Wayland is implemented or supported by desktop environments other than Gnome. KDE would be a good first step if the bugs are resolved. I really want to see Xfce, Cinnamon, and Mate on Wayland before I consider making a move.
@@CyberGizmo Alice in UNIX Land by Lincoln Spector, 1989: [...] Soon Alice came upon a large brown table. The Consultant was there, as was an apparently Mad Hacker, and several creatures that Alice did not recognize. In one corner sat a Dormouse fast asleep. Over the table was a large sign that read "UNIX Conference." Everyone except the Dormouse was holding a paper cup, from which they were sampling what appeared to be custard. "Wrong flavor," they all declared as they passed the cup the cup to the creature on their right and graciously took the one being offered on their left. Alice watched them repeat this ritual three or four times before she approached and sat down. [...] The Mad Hacker handed Alice a cup of custard-like substance and a spoon. "Here," he said, "what do you think of this?" "It looks lovely," said Alice, "very sweet." She tried a spoonful. "Yuck!" she cried. "It's awful. What is it?" "Oh just another graphic interface for UNIX," answered the Hacker.
Ngl really solid video, I already knew a lot of the technical underside stuff but you kept it interesting so I watched all the way through. It was also nice learning the roots of x11 that up until late last year was Atlas, holding up every linux desktop environment from xfce to KDE-Plasma to even individual window managers (many of which likely won't ever switch to wayland due to small dev teams and the massive undertaking it requires for a small team
Ive been using Wayland (with xwayland) since January and it has been great. I run games on steam, blender and a bunch of other applications with very few problems.
10:49 Games can run quite fast on X11, by making use of modern extensions such as XRender and shared memory sections. The legacy baggage doesn’t need to slow things down if you don’t use it.
@@mikesoto890 I assume this is referring to how in the original design X11 applications would send commands for lines, shapes, and text to the display server, and the server would then perform the drawing operations from scratch in its own pixel buffers. That design could be really efficient when the application was running on a remote computer and the UI design was simple, but the protocol's drawing commands were designed in the 1980s with little to no support for things like anti-aliasing and color blending, and dealing with fonts was an ordeal because they had to be installed on the display server rather than the machine where the application was actually running. This approach is still used by some applications, especially older ones such as xterm. To get around the graphical limitations in the X11 drawing commands, a lot of modern applications do more of the drawing in the application itself. For example instead of telling the display server "draw the text 'example' at position x,y with the current font and color", they use their own font rendering code and send the characters to the display server as image/pixel data. Some extensions have been added to the X11 protocol over the years to make that work better. The XRender extension provides pixel blending operations which can help with drawing application-rendered text. If an application is going to be drawing the entire window itself, the XShm extension lets the application and display server set up a pixel buffer in shared memory (if they're running on the same machine), so then the application can fill the buffer and tell the server to make it visible, without having to encode the pixels into the X11 protocol or copy them multiple times.
Thanks for the video. One thing I disagree about is that "the client server protocol got reversed" because of performance reasons. The X terminal is an evolutionary step from the then common text terminals. Multiple text terminals were connected to a big mainframe or minicomputer (in the "server room"). The programs running on the computer interacted with the user by sending text to and receiving text from the terminal the user was sitting at. X made the terminals graphical and applications could send graphical commands like "draw a line", "output some text", "bitblit an image|". The "server" refers to the display server, not the computer in the server room. The display server is a program running at the "tube end" of a connection, the other end being the computer end. These two roles were of course often combined in one package, a graphical workstation.
They DO have the role reversed if you think in 1984 terms. Normally, you, on a small computer, send requests to a Server on a big one which do something useful for you and returns the result. If you use X11, you need to start a server, and the big machine sends you requests to draw stuff on the screen.
@@framegrace1 Yes, I was there, in the eighties. But it is still logical that a display server is where the display is, just like a file server is where the files (disks) are. So what really was reversed, the perception people had about client-server in the 1980's or the X11 protocol? Should the X11 protocol have been designed differently (how?) so that people would have had a better grasp of it, but then reality kicked in and it had to be implemented "in reverse"? I really don't understand what DJ Ware is trying to say with "the protocol is reversed because of performance reasons".
I agree with Johan. X provides the "service" of displaying the output of a program (and sending user input back to it), hence "server". The program at the other end is requesting display service, hence "client". The confusion is purely one of terminology, not of functionality. Once you grok to the idea of network transparency that is (was) central to X, everything clicks into place. Think about having many programs running, all on different machines scattered across the world, and calling into your single X server to request display and input management. It would be absurd for those programs to send their output to their own monitor in Timbukwherever, even if they had one.
This is been quite educational from a historic and functional perspective. Accordingly, now I better understand why my much loved Autokey did not work on Wayland 😢 nor any of the other text expanders I have tried. I run Wayland on my Gnome systems (Ubuntu and Fedora), but my fault driver is still Arch (Garuda Linux) running KDE Plasma on X11. And, other than obvious none existence of a functioning Autokey I am never aware of any performance issues on either platform. Thanks for the education and God bless.
Wayland was slower for me on my intel built in graphics. Also had a problem with automating software which gave key strokes to other apps. So I went back to X11. But will keep an eye on it and see if gets better. Will also check if get a different graphics card or PC.
Had a similar issue with my graphics, turned out to be an issue they fixed later on. So don't you worry. The automation on the other hand I'm not so sure about, since it sounds like an issue with how wayland is meant to work. Could be unfixable. But maybe, I don't know. Screensharing sounded like that too and yet apps are slowly implementing it anyway.
I was using wayland already in 2014 on the Jolla phone (Sailfish OS); had it for a couple of years as my daily phone. Sailfish OS is probably the earliest adopter of wayland on a commercial device. I've tried wayland on the desktop from time to time and it has steadily become better. Now there is one thing preventing me from using it: the Nvidia driver. It mostly works, except Gnome nightlight that I like to use. There is a bug open at Nvidia and they've promised to fix it, so let's see.
Very good video - a much-needed comparison between the two systems! I'd be interested to see a review of *Plan 9's* approach to the gui - their approach looks interesting and quite elegant from what I can see, using the 9P2000 protocol.
The thing that was hardest to understand for me is that Wayland is NOT a server. It's just a standard that people are trying to go into. So there isn't a Wayland tool they can use but rather they have to build back-ends so that the Wayland standard can be followed. Wild!
You are super interesting. Thanks for sharing your knowledge. I am subscribing with the bell. This is perfect. You remind me of the feeling of watching The Computer Chronicles as a kid. The same wonderful explanations.
Definitely agree about Wayland not being finished on KDE. When I use fractional scaling with Wayland under KDE, menus don't redraw themselves until I move my mouse over them. It ends up looking broken and a total mess.
Excellent video!! A very good introduction and comparison of x11 and wayland. I hope to see more content like this form you and others in the linux community
I was using some Unix systems back in the early 90's as a student. One guy displayed a pic on my screen from across the room. Nowadays we would consider that an obvious security no-no. I hear that X contains a lot of hacks designed for hardware that is long since obsolete. I also heard that it includes an interpreter for ELF binaries, prompting one commentator to say that X is an operating system by itself.
Very similar to a security flaw I found in Sun's workstations, in 1988 or 1989, before the days of X, when I was a sysadmin at Ford. We reported it to Sun. I assume they fixed it. I also remember from that time a display windowing system based on Postscript.
One of the features of X that I've always appreciated is that networking was an inherent feature. I have implemented multi-user systems at several local non-profits using discarded older machines as diskless X terminals, net-booting LTSP from a single minimally powerful application server. This is also great in educational settings. The X terminal network can be kept entirely separate from the Internet and other local networks, which somewhat limits the security concerns. I would be sad to see that capability go. Perhaps Wayland has a built-in way for client apps to connect remotely, but I don't hear anybody talking about it. I've always found stuff like VNC to be OK in a pinch, or for occasional use, but too clunky for everyday applications, while horrible old 'beater' PCs can make very usable X terminals.
that client/server feature had to go because of the change in paradigm. wayland basically is a command-buffer stream for GLES commands going to the GPU, its the GPU that does the heavy lifting, not the wayland, wayland in a way is a "client" of sorts. it should be possible to do region damage on the framebuffer after compositing together while you know about the data-structures of the wayland to compress the video stream. RDP works that way on Windows, it provides a virtual graphics card framebuffer, it knows enough about the tree structure of the windows (I mean, the components, the buttons, and panels and shit, Windows calls everything windows, I guess that's why its called Windows) to reduce the need for "bitmap" transfer. Its kind of unavoidable with modern desktops with lots of bells and whistles. VNC is really, really bad protocol, it is basically dividing the screen in blocks and sending them as JPGs and the algorithm try to detect the blocks that didn't change (I think it can detect if blocks moved, but it is really bad, any MP4 compression algorithm it does better) , its possible to do better because proprietary software do video encoding with good latency, for ex, anydesk, that I'm sure works entirely on the bitmap framebuffer, but I bet it uses the hardware encoding for H.264. probably all of that is too much for your "beater" PC, I consider anything before the SandyBridge as e-waste, except perhaps for the "nehalem i7" those were really good. but if you are thinking about a core-2-quad, that would be a stretch, they would max out the CPU trying to decode and you are going to get latency.
its probably possible to create a client/server command buffer for GLES as a virtual GPU before Wayland and that would work without even changing Wayland. that would be a cool experiment.
@@jeremiahbullfrog9288 yeah, in that way we can have back that feature of client/server, but in a way that makes sense for our current architecture sending the command buffer would totally make more sense than scrapping framebuffers.
@@monad_tcp You have no clue about how the internals of modern graphics actually work. It is far more efficient to send the frame-buffer over instead of all the tinny bitty commands and actually programs and hassling around with compatibility and hardware differences all the time.
@@rosomak8244 no, it's not. I literally spent time optimizing framebuffer transfers the other day because I needed to run some Laplace pyramid transform and it's more efficient to do that on the CPU. The trade off was that the CPU could process the last captured frame while the GPU was generating the next. I implement this for both smartphone SoC and PC . Smartphones have shared memory, so no DMA copy, in this case you might be right. But on PC you have to wait for the async signal from the command queue of the GPU for completeness. In both case you don't need to actually manage any memory. I didn't even need unsafe code or any pointer arithmetic, you get opaque pointers from the driver and you just pin them if you are using a GC language . Or in case of Rust , you create a struct that does simple ref counting , which is trivial to do on Rust. That way you can signal the video driver when you're not using that memory anymore. Anyways, you don't even need to care about memory management, just do triple buffering of the surface, I mean, the pixbuf, framebuffer whatever it's called. Which is even better as allocation of framebuffer and memory allocation in general isn't "free", but just go allocating and calling malloc in the render thread. And I'm the one that doesnt know how to program. Programs should not allocate memory in steady state. All of them could use garbage collectors and you would be none the wiser, alas, the GPU driver has a GC for the FBOs , ironically . Its literally better to leave the framebuffer on the GPU and do everything there , than moving back and forth, DMA calls aren't free. You do hassle with hardware compatibility, it's the price to pay for performance. Otherwise you might as well do everything in Python and let pytorch take care of all that if you need it to be portable. Gezz , you guys are really bad at understating systems at multiple layers of abstraction.
I've been running Wayland with kde for a few months now and it has worked fine for me. With the release 5.26 there was a huge improvement in snapiness and I'm definitely not switching back. Stability is fine. I'm not a gamer though, so I can't comment on that.
Wayland is awesome. At first I thought I was having problems with Wayland, but really it my assumption that it's Wayland turns out to be an issue of XWayland which has the issues. Native Wayland has been flawless. That being said, X11 is decent. The problems I've had with X11 mostly deal with multiple monitors with different refresh rates, X11 does not like this at all. I'm also an NVIDIA user, and that's about worst-case scenario. Your video has been incredibly insightful into why Wayland tends to be lighter than X11, I had no idea that X11 used two framebuffers to draw all applications on.
I run Wayland on my openSUSE laptop. It has been flawless. I ran Arch on it for a while and it was flawless as well. My desktop has a NVidia 2070s and I am stuck with X11 on that, but with the new open source drivers coming out for NVidia, I am hopeful.
My notebook have GeForce MX150 (with optimus tech), and 3D offload doesn't work. My next computer (desktop & notebook) will 100% gonna be ALL-AMD (Ryzen-Radeon)
The NViDiA Open Source thing is an ugly gimmick (hiding the good stuff deeper down in a RISC-V chip on the board - making it even harder to reverse engineer).
@@NitroNilz That's true, but if Nvidia is willing to do some serious work on open source drivers, it would help. Even if they would go so far as to say, "we can do X, but if you want Z, you will need to use our proprietary drivers," that would be OK in my book, if they would just give us good proprietary drivers. They ones they give us now still leave a lot to be desired. They can do better.
I think I must be an outlier here, but Wayland has been magnitudes of scale more reliable and provided much better rendering with no screen tear and anomalies compared to X11. I have been using Wayland on my laptop (CF-33 since I got it because I could not get X11 to support the touchscreen whereas when I switched to Wayland I did not even need to calibrate it) and I have just switched over to Wayland on my desktop with an ATI card in it and it feels like a completely different machine. I have written a huge amount of code that relies on ncurses so am a little concerned that X will be depreciated, but as long as Wayland supports X11 applications for as long as is necessary there is little doubt that the move to Wayland is the right one.
Great video but just a small point of fact that was reversed at 10:05; the X Clients did not run on the X Terminal, the X Server did. The X Terminals like the NCD weren't running an OS you could log into or run XTerm or XEyes on, it could only run the X Server. So on your Sun 3 or whatever you'd set your DISPLAY environment variable to the name or IP address of the NCD plus normally a :0 and then run xterm on there on your Sun and it would show up on the NCD (running the X Server). If xdm was configured properly you'd actually get a nice login screen to your Sun workstation displayed on the NCD since xdm can be configured to manage both local and remote X Servers. X Terminals like the NCD were indeed slow :-)
Yes. The X Display server was called a server because it provided graphical display services to its clients. Its clients were the X-Windows applications that the user was running.
good point, so both server and client running on the server because those NCD terminals were not able to run anything? or those were running a terminal software?
@@jnslzr the terminology here is awkward, the NCD hardware is running a program called the X Server, it's job is to receive commands (over the network) to draw the UI, sending back information in the form of events. On your workstation, which in that era would have been a Sun or a HP or similar, running some flavor of Unix, you would set your DISPLAY environment variable to include the network address of the NCD. Then when you ran programs such as xterm, xeyes which X Windows refers to as clients, they would connect to and appear on the NCD. So if it was xterm, when that window appeared on the NCD the shell you'd be typing into was running on the Sun or HP. You can do this today fairly easily with two linux boxes. The trickiest part is getting the authentication to work such that the X Server running on the linux box you want your client to appear on to even allow such connections. This is mostly defaulted to "off" these days, when X11 first appeared it was always defaulted to on. Different times. Hope that helps.
@@jnslzr The Wikipedia entry for "X terminal" explains it well: An X terminal runs an 'X server'. In X, the usage of "client" and "server" is from the viewpoint of the programs: the X server supplies a screen, keyboard, mouse and touchscreen to client applications. This connects to an X display manager (introduced in X11R3) running on a central machine, using XDMCP (X Display Manager Control Protocol, introduced in X11R4). ... In the early 1990s, several vendors introduced X terminals including HP, DEC (including the VT1000 series), IBM, Samsung, NCD, Gipsi and Tektronix. It was cheaper to run a server with a bunch of X terminals than to have to buy the same number of Unix Workstations.
I am very thankful for the knowledge you share in your videos. Thank you! P.S. A collaboration video (or channel) with Wendell from Level 1, and Anthony from LTT would also be appreciated 👍😁
I know, you missed what I was saying. I said they originally tried to run the X-Clients on the terminal but the performance was terrible so they flipped the it to run the server.
@@CyberGizmo No, the terminology is basic to the architecture. The display is the server, the GUI apps are the clients. It doesn’t work if you flip it around.
I'm happy with Wayland and use it this year without any issues and I run a lot of Virtualbox VMs including Windows, FreeBSD and Linux (Wayland and X). The last time I stepped back to X was a month ago for Ubuntu 22.10 in Virtualbox, due to a bug in the cooperation between gnome-shell and wayland.
Great video. I work with Linux on ARM single board computers, and x11 rules the world here. Certainly the missing of good games that support wayland is my main problem. I now have very powerful boards like the Khadas VIM4 and Khadas Edge2 that run on wayland. But I'm finding it hard to make good use out of them. Everything I'm used to runs great in mainline with x11 with the Panfrost GPU driver. Finally after many years of progress. But Wayland is far behind, and I hope it will catch on. The thing is there's such a big library on software for x11. Thank you for the great info, I'm a new sub! Cheers.
I started programming in X11r4 back in '89-'90. I loved the remote display aspect of it. I will really hate to lose that if X11 disappears. I still use things from those days for remote displaying. But with it's age I understand the problems. And I am no longer developing with it. Security was very different in those days. Wish they could rewrite it but keep some of the features I love. But oh well.
As a KDE user I can definitely say Wayland wasn't ready last time I tried it. The basics work, but I would run into problems with drag and drop support between applications, particularly you couldn't pass data between native Wayland applications and ones running in XWayland. Until that can work, its an absolute deal breaker.
It might be interesting to talk about display postscript for historical context. I remember walking noseguy around a room of X11 terminals back in the day.
What motivated the client-server approach that X used was the prediction that computation was all going to be distributed on a network with the graphics and user-input managed locally on a less expensive workstation and the actual program running somewhere else. It’s ironic in that particular use-case for X was not really used nearly as much as just having the apps local.
In order to reduce IPC and/or context switching, migrate the functions of XWayland into the Wayland compositor for a single process. XWayland ends up having all the issues of XNest or Xephyr, in that it's a poor substitute in for Xorg or XFree86.
There are too many show-stoppers in Wayland for me to use as a daily. There are still some programs that have trouble grabbing the display for screen sharing and the lack of global hot keys was frustrating.
On Tumbleweed I currently use both X11 (on Cinnamon) and Wayland (on Gnome) and the only gripe I've had with Wayland is screen sharing. It can work on some apps like Zoom, but my work uses Teams which afaik doesn't support screen sharing on Wayland yet. Otherwise they both feel very stable and mature in my use cases, which isn't surprising for X but a little for Wayland given the comments I've seen around it
Yeah it's basically "If you can, use wayland, if you have to, use X11" and all it comes down to is if it got implemented in your software of choice already or not
Wayland runs perfectly on my main system Silverblue, and EndeavourOS. I do agree that Wayland will be the future, since the devs came from x11 to start the project. I finally decided to stop being a lurker and subbed.
I've been on dwl (wlroots-based wayland reimplementation of dwm) on my main system since I switched away from nvidia earlier this year, and while wayland is not ready for mission critical applications by any stretch, the benefits are worth it for a desktop. I have 3 displays, one of which runs at 144Hz, and there was absolutely no way to make all 3 run at their repective refresh rates without constant tearing, and vsync was not possible on my 144Hz monitor unless the others were disabled. I occasionally run into a bug, but it's worth putting up with for me for how much nicer it is to loom at.
The servers and clients were never moved. They were designed so that the user sat in front of a server and a client was on a remote machine from day one. Performance had nothing to do with it; it was designed that way because of the hardware it was designed to run on. X11 arose out of the minicomputer world. You didn't have your own computer; that would be silly, computers cost hundreds of thousands of dollars. You shared a computer with your entire department and everyone used it at the same time. Your operating systems (UNIX, VMS, etc.) and hardware were designed to support this - multiple users running multiple programs simultaneously. Microcomputers were toys, and no one (so minicomputer people thought) took them seriously. The X11 server/client nomenclature seems backwards to us because we're used to sitting in front of a computer and accessing a remote server. Minicomputer users never sat in front of computers. The computer was most likely in another room with a powerful air conditioner and a raised floor, guarded by operators upon whose good will your access to the computer relied. So you need to consider; what, really, is a server, and what is a client? A server provides a service, and a client accesses that service. In this case, the server provides video output and keyboard/mouse input, and the clients are programs that require those things. That's the definitions the Project Athena folks used, and it makes sense when you consider the flow of data. So a hardware X terminal never ran any clients, except possibly a display manager (a program that gave you an interface to log into a remote machine). The computer you connected to would provide all the clients, including the window manager. The server running on the X terminal provided video, mouse, and keyboard to those clients. A fun (?) project is to build a poor man's X server using a Raspberry Pi. Just put a minimal Linux install on it that starts an X server and runs xdm. Then use xdm to log into a UNIX/Linux box and run a desktop from there. The software to do this is pretty crusty these days and rather insecure, but it all still works. The downside is that modern GUi toolkits such as QT and GTK+ make heavy use of client-side image buffers for window components instead of the primitive drawing tools, so it tends to be slow. Programs using XVideo or OpenGL will just display black windows, as those are meant to be rendered directly by the video card and overlaid onto the screen, which obviously won't work remotely. On the other hand, programs using Athena, Motif, Tk, XView, and similar toolkits will be lightning fast.
I have been away from Linux since about 2016 and there was talk of implementing Wayland back then. I’m surprised and a wee bit disappointed that it has not been fully implemented by now. It’s been seven years! It may have its drawbacks but, it’s a testament to the developers of X that it is approaching its 40th anniversary and it’s still being widely used. There’s not much software out there about which that can be said.
I have been using X11 on Neon KDE for a short time and it has been giving me trouble with the restart and shutdown it takes 5 or more minutes to do either one, but the Wayland it does it instantly and I believe it has been working even better.
Thank you so much for all the work & explaining it in plain English. I'd like to be more than a Linux user, prefer being a Linux Runner that can learn in order to contribute. Don't know that I can since I didn't upgrade my last build for 15 +yrs didn't have to running slackware & now I'm in awe🙉
The client/server distinction was a little confused. Severs and clients aren't determined by speed. I've worked on many slow servers and fast clients. That's not why it's a server. Servers provide services to other programs. It serves services. In this case, the X server is providing graphics services to X clients that need the graphics services. So, the X server is always running on the machine that has the graphics display and keyboard. The client can be running anywhere.
Here a year later and boy has wayland improved. It is so good and easy to configure with desktop environments like hpyrland, sway, and KDE. Ive found it to be a much more enjoyable experience than X11 and simpler overall. I definitely felt the bloat when dealing with applications that configure X11 and that just doesnt exist on wayland.
I absolutely cannot wait for wayland to get better (and nvidia) or we get more options. It's the main problem with linux right now aside from application support. It is really crazy just how long Xorg/X11 have been in use.
I really want to use Wayland especially because fcitx won't work in x11 on my pc for some reason, so I can only use Japanese in Wayland. However yeah, lots of quality of life issues like limited UI sizing and flickering menus on right click that I have to fight with keep sending me back to x11
There's actually more than 3 systems There's also Arcan, and then there's more direct ways to address a display like DirectFB, Google's Freon or going all the way down to the kernel's display stack through DRM. AFAIK, Mir isn't a display server anymore, btw. Maybe in some forked form it is, but the one maintained by Canonical employees is a Wayland compositor with pluggable shells.
@@KaiHenningsen The Quartz Compositor? That's MacOS exclusive and I figured this video was about GNU/Linux (otherwise one might as well mention Windows and Amiga, as well). Display PDF (the origin of Quartz) did once run on GNU/Linux, too. But it's very old
We used as developers because we needed access to multiple machines from a single screen. At one point before X11 came on scene I had 6 monitors on my desk.
Interesting video. However, unless I misunderstood something, you completely forgot to mention the biggest shortcoming in Wayland. Which is the ability of having a process run on machin A while displaying on machine B. In the world I live in, this is a basic requirement, which I use all the time. Unless this gets resolved, Wayland will never be an option for me. Am I misunderstanding? Does Xeaylsnd resolve this shortcoming?
There is a program called "waypipe" that does what I think you want Wayland to do. I've used it once or twice, and it works exactly the same as "ssh -X" does, but it works natively with Wayland without requiring Xwayland.
I play Apex Legends and I want to bind some special buttons that Apex does not recognize. I tried to remap those buttons to another, more common keys, and the only reasonable way I found was in X11. So now I have two scripts that I double click before and after playing to rebind keys. So that is one reason I use X11.
I've been running GNOME with Wayland for 2 years and I really haven't had any Wayland related problems in the last year at all, playing games through Proton but also doing dev work and screen recording with OBS. I think Wayland is ready for most people without frustrations.
As far as Wayland solves "some" issues of X, Wayland does have a lot of significant flaws. One flaw is implicit synchronization leading to issues like if one program (let's say Blender with beefy scene) lags, your entire desktop lags because implicit synchronization forces synchronization to slowest element. This also gave a lot of issues as implementing Vulkan on Linux was painful, this made unironically Nvidia better choice in Linux then open source drivers because initially they struggled to resolve a lot of Vulkan issues. That being said Wayland is on way to improving as contributors from Collabora, Intel, AMD and Nvidia starts to make moves towards explicit sync that should resolve issues Wayland is having now, but standard for that is not yet finalized (there are just drafts for it) and it could take years to make Wayland finally right.
Thanks for the explanation of Wayland. I tried it with KDE and nvidia a few weeks ago. It is unusable, extremely unstable. I hope the future will arrive some time soon.
@@jmwintenn What about AMD? The nvidia card is in my old PC and I plan to buy a ZEN4-APU when they will be available next year. I don't need a dedicated graphics card. Are the AMD drivers better?
Wayland for the win!!! As a new Linux user it's been much more consistent that X11, we just need HDR switching with Wayland and Linux will be a force to be reckon with.
Sorry to see that Wayland has made so little progress over the years (at least they've made some). I remember evaluating it back when it was a new project in 2009 or so, when I was part of the working group for SlickBSD. The team eventually accomplished its goals in this area by using custom solution in the framebuffer. You know, it's not that hard to write a basic windowing system with very little code. Look at classic MacOS. No really, look at the Mac Plus. How big do you think that part of the OS is? Way smaller than either xorg or Wayland! So that's how that was approached. And what you said about the security vulns in xorg is right! It was a major part of the impetus for NOT using it in SlickBSD. Actually I recall there being a couple of MAJOR security vulns released while I was arguing against xorg with a few colleagues.
I would like popular Linux distros to allow choosing which one you want to install, so you can use the one that works better for you instead being forced to Wayland when your favourite distro's team decides to switch to Wayland. I wonder how Wayland performs on old hardware with old integrated GPUs. If it breaks the performance I don't want it to be pushed on people who have already good experience with their OSes.
I play games with a 165hz Gsync monitor, Windows 11, and X11 play them perfectly, Wayland has a ton of stutter and input lag, mainly because it doesn't support Vsync off, and depending on the implementation neither Variable Refresh Rate
I was in graduate school at MIT in 1984 when Bob Scheifler was originally working on the X Window System. I am not much of a visionary, and didn't understand much of his original conception, but in retrospect you have to give him an immense amount of credit for envisioning this system that has persisted for nearly 40 years. An accomplishment almost at the level of the creation of Unix itself, I would say, but vastly underappreciated.
Was at project Athena mid-80’s at MIT taking a class on X internals and probably ran into those guys. We did all of the work on DEC workstations running saber C as I recall.
This is yet another vague underappreciating video.
I was inside my father's balls in 1984.
When did they stop providing the CLU interface to X?
@@GodEmperorSuperStar I can't really tell you. I left MIT in August 1984. My impression was that Barbara Liskov's group had mostly transitioned to working on Argus roughly at that time, and I am not sure how much new CLU stuff went on after that.
Maybe I'm a lightweight home user, but Wayland has been flawless with me for a year or two. Thanks for the video. I always learn much from you.
Hi John, I guess it heavily depends on the desktop environment or window manager that you use; for instance, I found very little glitches when using Sway WM, but a whole lot of issues when using KDE + Nvidia proprietary drivers. There are so many layers in our current digital onions that sometimes our experience vary greatly from user to user even when using the same software and hardware stack, but mixed in a different way!
been using fedora with gnome on Wayland and amd igpu for a while now and I've had no issues. I definitely wouldn't call myself a "lightweight home user"
screen sharing is still problematic, but apps are slowly catching up.
Colour correction is useless. HDR support is nonexistent.
I'm running KDE Plasma through Wayland on Arch. Only problem I remember from the past year or 2 was an update breaking Kate text editor that was fixed next update.
Same, swaywm has been great i3 replacement for 2 years.
I personally have been using Wayland with KDE as a daily driver for the last 2 or 3 months and my anecdotal experience has actually been great. I switched because I use a laptop with multiple monitors in two different locations via docking stations. I was able to get this set up and working with x11, but it was a pain. Wayland, on the other hand, just worked. I’ve also noticed it’s a much smoother experience in general. Between these tidbits and a much nicer codebase, I can’t realistically see myself ever switching back at this point. The only substantial issue I’ve had is that custom scaling can be a bit weird across multiple monitors of different sizes but this isn’t a make-it-or-break it thing for me. The text on my laptop screen, which is effectively a rarely-user 3rd monitor 90% of the time, is just slightly smaller than it would be in a perfect world. This I can live with
I'm also using a docking setup on two different offices with different external monitor setups. It worked great for me on X11 but on Wayland - which I committed to a couple of months back - the experience is not as smooth: mostly Plasma forgets my desktop configuration every few days, reverting to the default "folder view with default wallpaper". I stopped using widgets on the external monitors because of that.
I'm running KDE Wayland too. Finally Linux is welcome to the 21st century !
The Wayland situation I complained about us apparently a known bug that is being worked on and will hopefully be fixed for 5.27
How did you install Wayland over your x11 setup?
I absolutely love what you do, some of the best most in depth videos on distros (technical side) and topics like this
Thanks Simplify I am glad you find them useful
I have been running Wayland on my main machine for development and gaming since Gnome 3 and I do not remember when I last had an issue with any of my various applications. Therefore, I consider Wayland is not only the future and presence, but even the more recent past of compositing under Linux.
Wayland is getting a lot better very fast. I tried wayland a year ago and rolled back. I tried it two months ago and I stayed. Especially on a laptop this lack of bloat allows me not only to have a better experience, but also save my battery. There are of course issues still - discord doesn't let me screen share, and funnily - telegram got worse when it switched from xwayland to native wayland (the mouse doesn't integrate, and you can't use the default system top bar), but they aren't enough for me to roll back like I did a year ago.
So yeah, I too, from the very beginning, thought wayland is the future. I thought it even as I was rolling back to X11. It's just the matter of adoption by other software, but since it's clearly better it's only a matter of time. There are things you can't do on X11 because it's ancient and defunct, and there are things that you can't do on wayland because they aren't ready YET.
*NIX user for 40+ years, here. You are a valuable resource. Keep publishing.
Thanks for the insights DJ Ware! This is the kind of discussion that inspires progress.
Thanks Weldopedia
You have helped me understand be less fearful of Wayland!
Your topics started to be way more interesting for me recently. Thanks for Your hard work!
thank you for doing this videos you sit on alot of info i havent even found in any linux bibles,its very interesting.
Excellent video, love the explanations on the topic. As a sys admin I consider you a professor, thanks. 🙏
Thanks Nicio. Sysadmin? me? naw I'm not smart enough to be one of them. I was a programmer.
Nice, is one thing to read on the subjects and construct visual idea. Another coming from a view of a professional with past experiences. Thanks for your input on each subject. Love the microkernel video, Can't wait for nano.
I worked on a factory planning system back in the mid-90's that used X-Windows to interface with various X-terminals. As part of this we wrote a library of C++ classes to wrap the various X widgets. Good times... 🙂
Yes almost all games whether running through Wine or natively use X11. Luckily XWayland seems to be perfectly handling them, I play a lot of different games all the time on KDE Wayland and they all work how you would expect them to work.
Great video :)
Thanks for the good explanation! I’m using Wayland with Gnome in Fedora and it works just fine for me, even with gaming. If any I’m only having sound issues, not graphics 😁
Thanks for the video. I always enjoy your breakdowns. I will stick with Xorg until Wayland is implemented or supported by desktop environments other than Gnome. KDE would be a good first step if the bugs are resolved. I really want to see Xfce, Cinnamon, and Mate on Wayland before I consider making a move.
Thanks eznix
@@CyberGizmo Alice in UNIX Land by Lincoln Spector, 1989: [...] Soon Alice came upon a large brown table. The Consultant was there, as was an apparently Mad Hacker, and several creatures that Alice did not recognize. In one corner sat a Dormouse fast asleep. Over the table was a large sign that read "UNIX Conference." Everyone except the Dormouse was holding a paper cup, from which they were sampling what appeared to be custard. "Wrong flavor," they all declared as they passed the cup the cup to the creature on their right and graciously took the one being offered on their left. Alice watched them repeat this ritual three or four times before she approached and sat down. [...] The Mad Hacker handed Alice a cup of custard-like substance and a spoon. "Here," he said, "what do you think of this?" "It looks lovely," said Alice, "very sweet." She tried a spoonful. "Yuck!" she cried. "It's awful. What is it?" "Oh just another graphic interface for UNIX," answered the Hacker.
Ngl really solid video, I already knew a lot of the technical underside stuff but you kept it interesting so I watched all the way through. It was also nice learning the roots of x11 that up until late last year was Atlas, holding up every linux desktop environment from xfce to KDE-Plasma to even individual window managers (many of which likely won't ever switch to wayland due to small dev teams and the massive undertaking it requires for a small team
Ive been using Wayland (with xwayland) since January and it has been great. I run games on steam, blender and a bunch of other applications with very few problems.
10:49 Games can run quite fast on X11, by making use of modern extensions such as XRender and shared memory sections. The legacy baggage doesn’t need to slow things down if you don’t use it.
could you elaborate?
@@mikesoto890 I assume this is referring to how in the original design X11 applications would send commands for lines, shapes, and text to the display server, and the server would then perform the drawing operations from scratch in its own pixel buffers. That design could be really efficient when the application was running on a remote computer and the UI design was simple, but the protocol's drawing commands were designed in the 1980s with little to no support for things like anti-aliasing and color blending, and dealing with fonts was an ordeal because they had to be installed on the display server rather than the machine where the application was actually running. This approach is still used by some applications, especially older ones such as xterm.
To get around the graphical limitations in the X11 drawing commands, a lot of modern applications do more of the drawing in the application itself. For example instead of telling the display server "draw the text 'example' at position x,y with the current font and color", they use their own font rendering code and send the characters to the display server as image/pixel data. Some extensions have been added to the X11 protocol over the years to make that work better. The XRender extension provides pixel blending operations which can help with drawing application-rendered text. If an application is going to be drawing the entire window itself, the XShm extension lets the application and display server set up a pixel buffer in shared memory (if they're running on the same machine), so then the application can fill the buffer and tell the server to make it visible, without having to encode the pixels into the X11 protocol or copy them multiple times.
@@dododge9428 Sounds like X11 is well optimized and there is little reason to replace it.
I first learned X11 back in the SunOS days in college. It was fun writing some hello-world, xeyes type of apps.
Thanks for the video. One thing I disagree about is that "the client server protocol got reversed" because of performance reasons. The X terminal is an evolutionary step from the then common text terminals. Multiple text terminals were connected to a big mainframe or minicomputer (in the "server room"). The programs running on the computer interacted with the user by sending text to and receiving text from the terminal the user was sitting at. X made the terminals graphical and applications could send graphical commands like "draw a line", "output some text", "bitblit an image|". The "server" refers to the display server, not the computer in the server room. The display server is a program running at the "tube end" of a connection, the other end being the computer end. These two roles were of course often combined in one package, a graphical workstation.
They DO have the role reversed if you think in 1984 terms. Normally, you, on a small computer, send requests to a Server on a big one which do something useful for you and returns the result. If you use X11, you need to start a server, and the big machine sends you requests to draw stuff on the screen.
@@framegrace1 Yes, I was there, in the eighties. But it is still logical that a display server is where the display is, just like a file server is where the files (disks) are. So what really was reversed, the perception people had about client-server in the 1980's or the X11 protocol? Should the X11 protocol have been designed differently (how?) so that people would have had a better grasp of it, but then reality kicked in and it had to be implemented "in reverse"? I really don't understand what DJ Ware is trying to say with "the protocol is reversed because of performance reasons".
I agree with Johan. X provides the "service" of displaying the output of a program (and sending user input back to it), hence "server". The program at the other end is requesting display service, hence "client". The confusion is purely one of terminology, not of functionality. Once you grok to the idea of network transparency that is (was) central to X, everything clicks into place. Think about having many programs running, all on different machines scattered across the world, and calling into your single X server to request display and input management. It would be absurd for those programs to send their output to their own monitor in Timbukwherever, even if they had one.
Thank you for taking time to tell us about this topic. Much appreciated!
Very nice video, there are a lot of well researched information , and it's all clear, thank you !
This is been quite educational from a historic and functional perspective. Accordingly, now I better understand why my much loved Autokey did not work on Wayland 😢 nor any of the other text expanders I have tried. I run Wayland on my Gnome systems (Ubuntu and Fedora), but my fault driver is still Arch (Garuda Linux) running KDE Plasma on X11. And, other than obvious none existence of a functioning Autokey I am never aware of any performance issues on either platform. Thanks for the education and God bless.
Wayland was slower for me on my intel built in graphics. Also had a problem with automating software which gave key strokes to other apps. So I went back to X11. But will keep an eye on it and see if gets better. Will also check if get a different graphics card or PC.
Had a similar issue with my graphics, turned out to be an issue they fixed later on. So don't you worry.
The automation on the other hand I'm not so sure about, since it sounds like an issue with how wayland is meant to work. Could be unfixable. But maybe, I don't know. Screensharing sounded like that too and yet apps are slowly implementing it anyway.
@Certyfikowany Przewracacz Hulajnóg Elektrycznych For what it's worth, GNOME Wayland has been working just fine on my Dell Inspiron 3793, i5 variant.
I was using wayland already in 2014 on the Jolla phone (Sailfish OS); had it for a couple of years as my daily phone. Sailfish OS is probably the earliest adopter of wayland on a commercial device. I've tried wayland on the desktop from time to time and it has steadily become better. Now there is one thing preventing me from using it: the Nvidia driver. It mostly works, except Gnome nightlight that I like to use. There is a bug open at Nvidia and they've promised to fix it, so let's see.
Very good video - a much-needed comparison between the two systems!
I'd be interested to see a review of *Plan 9's* approach to the gui - their approach looks interesting and quite elegant from what I can see, using the 9P2000 protocol.
All this time and I didn't understand. Those were 19 of the best spent minutes I've ever spent on UA-cam! Thank you Sir!
The thing that was hardest to understand for me is that Wayland is NOT a server. It's just a standard that people are trying to go into. So there isn't a Wayland tool they can use but rather they have to build back-ends so that the Wayland standard can be followed. Wild!
Wlroots helps apparently
There is a reference Wayland implementation called “Weston”.
@@kreuner11 Helps to develop new compositors but we have also KDE's KWin, Gnome's Mutter as parallel implementations.
I didn't know that Wayland still isn't fully supported yet. Thanks for the info and the clarifications.
You are super interesting. Thanks for sharing your knowledge. I am subscribing with the bell. This is perfect. You remind me of the feeling of watching The Computer Chronicles as a kid. The same wonderful explanations.
Wow, thank you Hello World, yeah that show was incredible
Definitely agree about Wayland not being finished on KDE. When I use fractional scaling with Wayland under KDE, menus don't redraw themselves until I move my mouse over them. It ends up looking broken and a total mess.
Excellent video!! A very good introduction and comparison of x11 and wayland. I hope to see more content like this form you and others in the linux community
I was using some Unix systems back in the early 90's as a student. One guy displayed a pic on my screen from across the room. Nowadays we would consider that an obvious security no-no. I hear that X contains a lot of hacks designed for hardware that is long since obsolete. I also heard that it includes an interpreter for ELF binaries, prompting one commentator to say that X is an operating system by itself.
Very similar to a security flaw I found in Sun's workstations, in 1988 or 1989, before the days of X, when I was a sysadmin at Ford. We reported it to Sun. I assume they fixed it. I also remember from that time a display windowing system based on Postscript.
I enjoy your video's .. especially this one! Thanks to you I have started a 2nd notebook. Keep up the great work!!!
haha, thanks David, and I sure will try
One of the features of X that I've always appreciated is that networking was an inherent feature. I have implemented multi-user systems at several local non-profits using discarded older machines as diskless X terminals, net-booting LTSP from a single minimally powerful application server. This is also great in educational settings. The X terminal network can be kept entirely separate from the Internet and other local networks, which somewhat limits the security concerns.
I would be sad to see that capability go. Perhaps Wayland has a built-in way for client apps to connect remotely, but I don't hear anybody talking about it. I've always found stuff like VNC to be OK in a pinch, or for occasional use, but too clunky for everyday applications, while horrible old 'beater' PCs can make very usable X terminals.
that client/server feature had to go because of the change in paradigm. wayland basically is a command-buffer stream for GLES commands going to the GPU, its the GPU that does the heavy lifting, not the wayland, wayland in a way is a "client" of sorts.
it should be possible to do region damage on the framebuffer after compositing together while you know about the data-structures of the wayland to compress the video stream. RDP works that way on Windows, it provides a virtual graphics card framebuffer, it knows enough about the tree structure of the windows (I mean, the components, the buttons, and panels and shit, Windows calls everything windows, I guess that's why its called Windows) to reduce the need for "bitmap" transfer.
Its kind of unavoidable with modern desktops with lots of bells and whistles.
VNC is really, really bad protocol, it is basically dividing the screen in blocks and sending them as JPGs and the algorithm try to detect the blocks that didn't change (I think it can detect if blocks moved, but it is really bad, any MP4 compression algorithm it does better) , its possible to do better because proprietary software do video encoding with good latency, for ex, anydesk, that I'm sure works entirely on the bitmap framebuffer, but I bet it uses the hardware encoding for H.264.
probably all of that is too much for your "beater" PC, I consider anything before the SandyBridge as e-waste, except perhaps for the "nehalem i7" those were really good. but if you are thinking about a core-2-quad, that would be a stretch, they would max out the CPU trying to decode and you are going to get latency.
its probably possible to create a client/server command buffer for GLES as a virtual GPU before Wayland and that would work without even changing Wayland.
that would be a cool experiment.
@@jeremiahbullfrog9288 yeah, in that way we can have back that feature of client/server, but in a way that makes sense for our current architecture
sending the command buffer would totally make more sense than scrapping framebuffers.
@@monad_tcp You have no clue about how the internals of modern graphics actually work. It is far more efficient to send the frame-buffer over instead of all the tinny bitty commands and actually programs and hassling around with compatibility and hardware differences all the time.
@@rosomak8244 no, it's not.
I literally spent time optimizing framebuffer transfers the other day because I needed to run some Laplace pyramid transform and it's more efficient to do that on the CPU.
The trade off was that the CPU could process the last captured frame while the GPU was generating the next.
I implement this for both smartphone SoC and PC .
Smartphones have shared memory, so no DMA copy, in this case you might be right.
But on PC you have to wait for the async signal from the command queue of the GPU for completeness.
In both case you don't need to actually manage any memory.
I didn't even need unsafe code or any pointer arithmetic, you get opaque pointers from the driver and you just pin them if you are using a GC language .
Or in case of Rust , you create a struct that does simple ref counting , which is trivial to do on Rust.
That way you can signal the video driver when you're not using that memory anymore.
Anyways, you don't even need to care about memory management, just do triple buffering of the surface, I mean, the pixbuf, framebuffer whatever it's called. Which is even better as allocation of framebuffer and memory allocation in general isn't "free", but just go allocating and calling malloc in the render thread. And I'm the one that doesnt know how to program.
Programs should not allocate memory in steady state. All of them could use garbage collectors and you would be none the wiser, alas, the GPU driver has a GC for the FBOs , ironically .
Its literally better to leave the framebuffer on the GPU and do everything there , than moving back and forth, DMA calls aren't free.
You do hassle with hardware compatibility, it's the price to pay for performance.
Otherwise you might as well do everything in Python and let pytorch take care of all that if you need it to be portable.
Gezz , you guys are really bad at understating systems at multiple layers of abstraction.
I've been running Wayland with kde for a few months now and it has worked fine for me. With the release 5.26 there was a huge improvement in snapiness and I'm definitely not switching back. Stability is fine.
I'm not a gamer though, so I can't comment on that.
Wayland is awesome. At first I thought I was having problems with Wayland, but really it my assumption that it's Wayland turns out to be an issue of XWayland which has the issues. Native Wayland has been flawless.
That being said, X11 is decent. The problems I've had with X11 mostly deal with multiple monitors with different refresh rates, X11 does not like this at all. I'm also an NVIDIA user, and that's about worst-case scenario.
Your video has been incredibly insightful into why Wayland tends to be lighter than X11, I had no idea that X11 used two framebuffers to draw all applications on.
I run Wayland on my openSUSE laptop. It has been flawless. I ran Arch on it for a while and it was flawless as well.
My desktop has a NVidia 2070s and I am stuck with X11 on that, but with the new open source drivers coming out for NVidia, I am hopeful.
My notebook have GeForce MX150 (with optimus tech), and 3D offload doesn't work.
My next computer (desktop & notebook) will 100% gonna be ALL-AMD (Ryzen-Radeon)
yeah i want to run wayland on my desktop but nvidia sucks BALLS
I have an Nvidia card as well and yeah I hope the drivers improve for Wayland too, because right now they are terrible.
The NViDiA Open Source thing is an ugly gimmick (hiding the good stuff deeper down in a RISC-V chip on the board - making it even harder to reverse engineer).
@@NitroNilz That's true, but if Nvidia is willing to do some serious work on open source drivers, it would help. Even if they would go so far as to say, "we can do X, but if you want Z, you will need to use our proprietary drivers," that would be OK in my book, if they would just give us good proprietary drivers. They ones they give us now still leave a lot to be desired. They can do better.
Yeah, I've been wondering for a while and this was pretty insightful, thank you.
I think I must be an outlier here, but Wayland has been magnitudes of scale more reliable and provided much better rendering with no screen tear and anomalies compared to X11. I have been using Wayland on my laptop (CF-33 since I got it because I could not get X11 to support the touchscreen whereas when I switched to Wayland I did not even need to calibrate it) and I have just switched over to Wayland on my desktop with an ATI card in it and it feels like a completely different machine. I have written a huge amount of code that relies on ncurses so am a little concerned that X will be depreciated, but as long as Wayland supports X11 applications for as long as is necessary there is little doubt that the move to Wayland is the right one.
Great video but just a small point of fact that was reversed at 10:05; the X Clients did not run on the X Terminal, the X Server did. The X Terminals like the NCD weren't running an OS you could log into or run XTerm or XEyes on, it could only run the X Server. So on your Sun 3 or whatever you'd set your DISPLAY environment variable to the name or IP address of the NCD plus normally a :0 and then run xterm on there on your Sun and it would show up on the NCD (running the X Server). If xdm was configured properly you'd actually get a nice login screen to your Sun workstation displayed on the NCD since xdm can be configured to manage both local and remote X Servers. X Terminals like the NCD were indeed slow :-)
Yes. The X Display server was called a server because it provided graphical display services to its clients. Its clients were the X-Windows applications that the user was running.
good point, so both server and client running on the server because those NCD terminals were not able to run anything? or those were running a terminal software?
@@jnslzr the terminology here is awkward, the NCD hardware is running a program called the X Server, it's job is to receive commands (over the network) to draw the UI, sending back information in the form of events. On your workstation, which in that era would have been a Sun or a HP or similar, running some flavor of Unix, you would set your DISPLAY environment variable to include the network address of the NCD. Then when you ran programs such as xterm, xeyes which X Windows refers to as clients, they would connect to and appear on the NCD. So if it was xterm, when that window appeared on the NCD the shell you'd be typing into was running on the Sun or HP. You can do this today fairly easily with two linux boxes. The trickiest part is getting the authentication to work such that the X Server running on the linux box you want your client to appear on to even allow such connections. This is mostly defaulted to "off" these days, when X11 first appeared it was always defaulted to on. Different times. Hope that helps.
@@jnslzr The Wikipedia entry for "X terminal" explains it well:
An X terminal runs an 'X server'. In X, the usage of "client" and "server" is from the viewpoint of the programs: the X server supplies a screen, keyboard, mouse and touchscreen to client applications. This connects to an X display manager (introduced in X11R3) running on a central machine, using XDMCP (X Display Manager Control Protocol, introduced in X11R4).
...
In the early 1990s, several vendors introduced X terminals including HP, DEC (including the VT1000 series), IBM, Samsung, NCD, Gipsi and Tektronix.
It was cheaper to run a server with a bunch of X terminals than to have to buy the same number of Unix Workstations.
I am very thankful for the knowledge you share in your videos. Thank you!
P.S. A collaboration video (or channel) with Wendell from Level 1, and Anthony from LTT would also be appreciated 👍😁
Thanks Zer0Hour, yeah would love to do a collab with them
@@CyberGizmo 👍
Love the HAL status screensaver and camera panel on the wall above it
This was incredibly informative! It's on par with my university courses and you've been kind enough to release it for free. Thanks so much.
10:07 X clients are the apps, running on the main machine in (at that time) the computer room. The X terminal on the user’s desk ran the X server.
I know, you missed what I was saying. I said they originally tried to run the X-Clients on the terminal but the performance was terrible so they flipped the it to run the server.
@@CyberGizmo No, the terminology is basic to the architecture. The display is the server, the GUI apps are the clients. It doesn’t work if you flip it around.
Hey, I also have the HAL9000 on my wall - And I recognized the status monitor below ;-) very nice!
I'm happy with Wayland and use it this year without any issues and I run a lot of Virtualbox VMs including Windows, FreeBSD and Linux (Wayland and X).
The last time I stepped back to X was a month ago for Ubuntu 22.10 in Virtualbox, due to a bug in the cooperation between gnome-shell and wayland.
It was very informative and I enjoyed it. Thank you for your help!
Great video. I work with Linux on ARM single board computers, and x11 rules the world here.
Certainly the missing of good games that support wayland is my main problem.
I now have very powerful boards like the Khadas VIM4 and Khadas Edge2 that run on wayland. But I'm finding it hard to make good use out of them.
Everything I'm used to runs great in mainline with x11 with the Panfrost GPU driver. Finally after many years of progress.
But Wayland is far behind, and I hope it will catch on. The thing is there's such a big library on software for x11. Thank you for the great info, I'm a new sub! Cheers.
Thanks Mate.... Always .... Simply the best explanation... Thank you...
👍👍- Another great explainer. Thanks!
I started programming in X11r4 back in '89-'90. I loved the remote display aspect of it. I will really hate to lose that if X11 disappears. I still use things from those days for remote displaying. But with it's age I understand the problems. And I am no longer developing with it. Security was very different in those days. Wish they could rewrite it but keep some of the features I love. But oh well.
As a KDE user I can definitely say Wayland wasn't ready last time I tried it. The basics work, but I would run into problems with drag and drop support between applications, particularly you couldn't pass data between native Wayland applications and ones running in XWayland. Until that can work, its an absolute deal breaker.
It might be interesting to talk about display postscript for historical context. I remember walking noseguy around a room of X11 terminals back in the day.
What motivated the client-server approach that X used was the prediction that computation was all going to be distributed on a network with the graphics and user-input managed locally on a less expensive workstation and the actual program running somewhere else. It’s ironic in that particular use-case for X was not really used nearly as much as just having the apps local.
In order to reduce IPC and/or context switching, migrate the functions of XWayland into the Wayland compositor for a single process. XWayland ends up having all the issues of XNest or Xephyr, in that it's a poor substitute in for Xorg or XFree86.
There are too many show-stoppers in Wayland for me to use as a daily. There are still some programs that have trouble grabbing the display for screen sharing and the lack of global hot keys was frustrating.
On Tumbleweed I currently use both X11 (on Cinnamon) and Wayland (on Gnome) and the only gripe I've had with Wayland is screen sharing. It can work on some apps like Zoom, but my work uses Teams which afaik doesn't support screen sharing on Wayland yet. Otherwise they both feel very stable and mature in my use cases, which isn't surprising for X but a little for Wayland given the comments I've seen around it
as junior, thank you sir
Man, another awesome video DJ👍!
Thanks Felix
Wayland needs more work,. but I can't wait for it to be mature more. I still use X11 atm.
Yeah it's basically "If you can, use wayland, if you have to, use X11" and all it comes down to is if it got implemented in your software of choice already or not
Wayland runs perfectly on my main system Silverblue, and EndeavourOS. I do agree that Wayland will be the future, since the devs came from x11 to start the project. I finally decided to stop being a lurker and subbed.
Mir is not standalone display server today, just Wayland compositor. 3rd one is Arcan project, made using game engine
Wayland gnome works perfectly for me for months. no issues whatsoever either working or gaming.
I've been on dwl (wlroots-based wayland reimplementation of dwm) on my main system since I switched away from nvidia earlier this year, and while wayland is not ready for mission critical applications by any stretch, the benefits are worth it for a desktop. I have 3 displays, one of which runs at 144Hz, and there was absolutely no way to make all 3 run at their repective refresh rates without constant tearing, and vsync was not possible on my 144Hz monitor unless the others were disabled. I occasionally run into a bug, but it's worth putting up with for me for how much nicer it is to loom at.
What an interesting talk - thank you!
The servers and clients were never moved. They were designed so that the user sat in front of a server and a client was on a remote machine from day one. Performance had nothing to do with it; it was designed that way because of the hardware it was designed to run on.
X11 arose out of the minicomputer world. You didn't have your own computer; that would be silly, computers cost hundreds of thousands of dollars. You shared a computer with your entire department and everyone used it at the same time. Your operating systems (UNIX, VMS, etc.) and hardware were designed to support this - multiple users running multiple programs simultaneously. Microcomputers were toys, and no one (so minicomputer people thought) took them seriously.
The X11 server/client nomenclature seems backwards to us because we're used to sitting in front of a computer and accessing a remote server. Minicomputer users never sat in front of computers. The computer was most likely in another room with a powerful air conditioner and a raised floor, guarded by operators upon whose good will your access to the computer relied. So you need to consider; what, really, is a server, and what is a client?
A server provides a service, and a client accesses that service. In this case, the server provides video output and keyboard/mouse input, and the clients are programs that require those things. That's the definitions the Project Athena folks used, and it makes sense when you consider the flow of data.
So a hardware X terminal never ran any clients, except possibly a display manager (a program that gave you an interface to log into a remote machine). The computer you connected to would provide all the clients, including the window manager. The server running on the X terminal provided video, mouse, and keyboard to those clients.
A fun (?) project is to build a poor man's X server using a Raspberry Pi. Just put a minimal Linux install on it that starts an X server and runs xdm. Then use xdm to log into a UNIX/Linux box and run a desktop from there. The software to do this is pretty crusty these days and rather insecure, but it all still works. The downside is that modern GUi toolkits such as QT and GTK+ make heavy use of client-side image buffers for window components instead of the primitive drawing tools, so it tends to be slow. Programs using XVideo or OpenGL will just display black windows, as those are meant to be rendered directly by the video card and overlaid onto the screen, which obviously won't work remotely. On the other hand, programs using Athena, Motif, Tk, XView, and similar toolkits will be lightning fast.
I have been away from Linux since about 2016 and there was talk of implementing Wayland back then. I’m surprised and a wee bit disappointed that it has not been fully implemented by now. It’s been seven years! It may have its drawbacks but, it’s a testament to the developers of X that it is approaching its 40th anniversary and it’s still being widely used. There’s not much software out there about which that can be said.
I have been using X11 on Neon KDE for a short time and it has been giving me trouble with the restart and shutdown it takes 5 or more minutes to do either one, but the Wayland it does it instantly and I believe it has been working even better.
kde lover and wayland here,because i need it for gaming
nice content Sir
I needed this video yesterday (just emerged X)
I hope it wins
Pshhhh what could my threadripper 3970x and asus Nvidia rtx3070 possibly need that a computer in 1986 couldn't do!
Off-topic, but your channel is awesome. Just subbed.
Thanks Sean
Thank you so much for all the work & explaining it in plain English. I'd like to be more than a Linux user, prefer being a Linux Runner that can learn in order to contribute. Don't know that I can since I didn't upgrade my last build for 15 +yrs didn't have to running slackware & now I'm in awe🙉
The client/server distinction was a little confused. Severs and clients aren't determined by speed. I've worked on many slow servers and fast clients. That's not why it's a server. Servers provide services to other programs. It serves services. In this case, the X server is providing graphics services to X clients that need the graphics services. So, the X server is always running on the machine that has the graphics display and keyboard. The client can be running anywhere.
Thanks for the explanation!
Here a year later and boy has wayland improved. It is so good and easy to configure with desktop environments like hpyrland, sway, and KDE. Ive found it to be a much more enjoyable experience than X11 and simpler overall. I definitely felt the bloat when dealing with applications that configure X11 and that just doesnt exist on wayland.
I absolutely cannot wait for wayland to get better (and nvidia) or we get more options. It's the main problem with linux right now aside from application support. It is really crazy just how long Xorg/X11 have been in use.
Great video. Thank you!
That's a really cool screensaver.
Daily driven KDE Wayland since Plasma 5.23
We'll have a nearly identical video to this on Wayland's 20th birthday. Ridiculous
I guess its true great minds think alike.
Was helpfull now i know i should Go for egl only drop Display Servers be the Displayserver.
Very informative video! Thank you
Welcome Michael
I really want to use Wayland especially because fcitx won't work in x11 on my pc for some reason, so I can only use Japanese in Wayland. However yeah, lots of quality of life issues like limited UI sizing and flickering menus on right click that I have to fight with keep sending me back to x11
I still use X11, but will definitely move towards Wayland when it starts beating out Wayland in usage and support.
I share that opinion, savantshuia
Me also. Xorg "just works" for me, I've no reason to change at this stage.
There's actually more than 3 systems
There's also Arcan, and then there's more direct ways to address a display like DirectFB, Google's Freon or going all the way down to the kernel's display stack through DRM.
AFAIK, Mir isn't a display server anymore, btw. Maybe in some forked form it is, but the one maintained by Canonical employees is a Wayland compositor with pluggable shells.
And I think Apple's thing, whatever they named it, should at least be mentioned?
@@KaiHenningsen The Quartz Compositor? That's MacOS exclusive and I figured this video was about GNU/Linux (otherwise one might as well mention Windows and Amiga, as well).
Display PDF (the origin of Quartz) did once run on GNU/Linux, too. But it's very old
Great video. Thanks
It was designed for interoffice, use and for low resource use.
We used as developers because we needed access to multiple machines from a single screen. At one point before X11 came on scene I had 6 monitors on my desk.
Nice, will you be doing a video comparing pulseaudio and pipewire.
I'll add it to the list, Jared. Thanks for the topic suggestion!
Interesting video. However, unless I misunderstood something, you completely forgot to mention the biggest shortcoming in Wayland. Which is the ability of having a process run on machin A while displaying on machine B. In the world I live in, this is a basic requirement, which I use all the time. Unless this gets resolved, Wayland will never be an option for me. Am I misunderstanding? Does Xeaylsnd resolve this shortcoming?
There is a program called "waypipe" that does what I think you want Wayland to do. I've used it once or twice, and it works exactly the same as "ssh -X" does, but it works natively with Wayland without requiring Xwayland.
I play Apex Legends and I want to bind some special buttons that Apex does not recognize. I tried to remap those buttons to another, more common keys, and the only reasonable way I found was in X11. So now I have two scripts that I double click before and after playing to rebind keys. So that is one reason I use X11.
Thank you for sharing:-)
I've been running GNOME with Wayland for 2 years and I really haven't had any Wayland related problems in the last year at all, playing games through Proton but also doing dev work and screen recording with OBS. I think Wayland is ready for most people without frustrations.
I just wish scaling was better than having to enable "accesibility mode" via large text. tmk Wayland still sucks with HiDPI monitors where
@@df3yt You can enable fractional scaling, and it works pretty well.
@@AssafHershko Via GUI or hack?
As far as Wayland solves "some" issues of X, Wayland does have a lot of significant flaws. One flaw is implicit synchronization leading to issues like if one program (let's say Blender with beefy scene) lags, your entire desktop lags because implicit synchronization forces synchronization to slowest element. This also gave a lot of issues as implementing Vulkan on Linux was painful, this made unironically Nvidia better choice in Linux then open source drivers because initially they struggled to resolve a lot of Vulkan issues. That being said Wayland is on way to improving as contributors from Collabora, Intel, AMD and Nvidia starts to make moves towards explicit sync that should resolve issues Wayland is having now, but standard for that is not yet finalized (there are just drafts for it) and it could take years to make Wayland finally right.
Thanks for the explanation of Wayland. I tried it with KDE and nvidia a few weeks ago. It is unusable, extremely unstable. I hope the future will arrive some time soon.
nothing on linux plays nice with nvidia. dont expect that to change any time soon.
@@jmwintenn What about AMD? The nvidia card is in my old PC and I plan to buy a ZEN4-APU when they will be available next year. I don't need a dedicated graphics card. Are the AMD drivers better?
Wayland for the win!!! As a new Linux user it's been much more consistent that X11, we just need HDR switching with Wayland and Linux will be a force to be reckon with.
Sorry to see that Wayland has made so little progress over the years (at least they've made some). I remember evaluating it back when it was a new project in 2009 or so, when I was part of the working group for SlickBSD. The team eventually accomplished its goals in this area by using custom solution in the framebuffer. You know, it's not that hard to write a basic windowing system with very little code. Look at classic MacOS. No really, look at the Mac Plus. How big do you think that part of the OS is? Way smaller than either xorg or Wayland! So that's how that was approached. And what you said about the security vulns in xorg is right! It was a major part of the impetus for NOT using it in SlickBSD. Actually I recall there being a couple of MAJOR security vulns released while I was arguing against xorg with a few colleagues.
I would like popular Linux distros to allow choosing which one you want to install, so you can use the one that works better for you instead being forced to Wayland when your favourite distro's team decides to switch to Wayland. I wonder how Wayland performs on old hardware with old integrated GPUs. If it breaks the performance I don't want it to be pushed on people who have already good experience with their OSes.
I play games with a 165hz Gsync monitor, Windows 11, and X11 play them perfectly, Wayland has a ton of stutter and input lag, mainly because it doesn't support Vsync off, and depending on the implementation neither Variable Refresh Rate
that's probably mostly because nvidia doesn't care to support wayland properly yet.