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.
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.
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!
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 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.
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 😁
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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 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 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 challenge the claim that Wayland has "a lot less latency". While it may (?) be true IF a compositor is run alongside x11 - it is simply not the case for a "barebone" x11 session. For competitive gaming / e-sports this is a problem, and that's a problem I don't think will go away anytime soon because how Wayland is designed. Best future scenario IMO would be too scrap both Wayland and x11 and do redesign / rewrite of X. X12 in Rust perhaps? ...Not likely but one can always hope ;) Good video nonetheless - Cheers!
@@CyberGizmo I'm a regular at mr. Larabels eminent site and I can't recall seeing any game latency measurements there. I can be wrong but I don't even think game latency measurements is part of the phoronix test suite (?). With all due respect sir, could it be that you've browsed some articles in a bit of haste and mistook frame time graphs for latency measurements? I mean they're after all both specified in "milli seconds". If not, please point me to the article in question and I will stand corrected. Thank you!
@@jonbjorkeback9499 I found about quote a few some of them show X11 ahead (NVIDIA) some show Wayland ahead (AMD) probably more: www.phoronix.com/search/Wayland Probably speaks more to NVidia lack of support for Wayland than X11 ability. My real issue with X11 has more to do with its lack of support from Xorg Foundation, no major updates since 2012 and they only fix major bugs...not good
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 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.
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'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.
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.
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.
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.
Very good video. 2:17: You are confusing the topic here. X11 and Wayland, are not display servers, but display server protocols. Mir is a display server and it uses Wayland. People were a bit confused by Mir in the beginning, because it intentionally hid the display server protocol by requiring Unity client applications to rely on libraries implementing the display server protocols. This was to enable fast development for its primary audience, which were people wanting to write converged apps for Ubuntu Personal, which would be adaptive apps being able to run on both phones, tablets and desktops. This made it special, as you need more efficiency if you want to run a desktop system from a phone and you would need ways to better utilize RAM, hence the opposite approach to buffer allocation.
@@CyberGizmo: It's the difference between specification and implementation. You usually have the specification first, so there's no problem to have a specification without an implementation. In the case of Mir, they had an implementation but not a specification, because you weren't supposed to rely on the DS protocol directly anyway. Most X11 software don't implement X11 directly, but rely on toolkits and such.
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.
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.
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
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.
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.
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.
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 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.
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 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.
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 found the diagram at 0:39 to be quite hard to read. I'd recommend using a tool like excalidraw, which will keep the hand-drawn feel while being much more legible.
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.
Wayland on Plasma 5.25 was giving me a weird issue where my PC would wake up from sleep, but my monitor's display wouldn't. In some monitors, trying to shut down my PC would shut off the display but leave the PC running. On Plasma, X11 will remain my default until I feel confident running Wayland again.
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.
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
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 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 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.
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
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🙉
I'm sure Wayland will be great long-term. At the moment, however, it's not usable for me. As of COVID, desktop video conferencing is ubiquitous, and Microsoft Teams doesn't support Wayland. Not sure about the other video conferencing systems, but it doesn't matter. As long as one of the popular systems is unsupported, Wayland isn't usable. I need to be able to use whatever the other people in the meeting are using.
One thing I've always wondered - why is it X11, eleven, not some other number? I had assumed in the past that the first X was improved and called X2, then X3, etc. and maybe in the future we'll see X12, X13... but that hasn't happened. Just a bit of talk. I do recall in the late 1990s an attempt at something called "Y Windows" but it vanished.
I've tried wayland on KDE and it works great mostly, unfortunately the reason I even switched to it - better performance in a particular game - also created problems (that I personally blame on the game), namely weird mouse jumping issues and worse support for switching resolutions. Also one KDE update broke positioning of all KDE-native control panels so start menu, bluetooth menu, battery menu, etc were all horizontally centered. I wish it were even better supported, bc I did have significantly better performance in that game in particular (20-50%) so I'd switch to wayland whenever I played that game despite not being able to use the mouse in that game.
@@nonholographic It's the critically acclaimed MMORPG Final Fantasy XIV, which has a free trial including the entirety of A Realm Reborn AND the award-winning Heavensward expansion up to level 60 with no restrictions on playtime!
I am Using now KDE Plasma Wayland for years as my daily driver and for me it is better than X11. I browse with it look youtube, email/office, play all the games without problems. Also recording the screen does work. there may be a feature i may not use and is not implemented, but i don't know any for now. everything works for me and also is very performant. When you are looking to test wayland you have to judge every implementation seperately, it is not like it was with X11 where everyone used the X11 server as basis. Every Desktop ist virtually implementing it for themselves ofcourse (hopefully) always compatible with the Wayland Protocol Rules. (for years is now like ~ 2 years without going back to X11 i don't know it exactly i didn't mark it in my calendar :D) [of course AMD Radeon Graphics Card user with open drivers]
I had to check the date this video posted thinking it posted in 2019, when problems with wayland were exactly as described. I'm on manjaro-kde with wayland and play many games, steam games (proton), do godot game dev, OBS screen record for my youtube, etc... all the stuff that he says wayland (specifically kde) isn't ready for. Maybe this guy is using an LTS from 2019?
The KDE list came from KDE's website, and were current open issue, one of the devs said those issues have been closed as a reply to this post...maybe they need to update their web site.
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.
Thanks for the insights DJ Ware! This is the kind of discussion that inspires progress.
Thanks Weldopedia
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.
*NIX user for 40+ years, here. You are a valuable resource. Keep publishing.
Your topics started to be way more interesting for me recently. Thanks for Your hard work!
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.
You have helped me understand be less fearful of Wayland!
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 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 :)
thank you for doing this videos you sit on alot of info i havent even found in any linux bibles,its very interesting.
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.
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 😁
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.
Love the HAL status screensaver and camera panel on the wall above it
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.
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.
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.
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.
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.
All this time and I didn't understand. Those were 19 of the best spent minutes I've ever spent on TH-cam! Thank you Sir!
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
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
I first learned X11 back in the SunOS days in college. It was fun writing some hello-world, xeyes type of apps.
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.
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.
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.
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.
I didn't know that Wayland still isn't fully supported yet. Thanks for the info and the clarifications.
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 nice video, there are a lot of well researched information , and it's all clear, thank you !
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.
Thank you for taking time to tell us about this topic. Much appreciated!
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.
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.
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 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 👍
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.
Mir is not standalone display server today, just Wayland compositor. 3rd one is Arcan project, made using game engine
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
I challenge the claim that Wayland has "a lot less latency". While it may (?) be true IF a compositor is run alongside x11 - it is simply not the case for a "barebone" x11 session.
For competitive gaming / e-sports this is a problem, and that's a problem I don't think will go away anytime soon because how Wayland is designed.
Best future scenario IMO would be too scrap both Wayland and x11 and do redesign / rewrite of X. X12 in Rust perhaps? ...Not likely but one can always hope ;)
Good video nonetheless - Cheers!
Go check out Phoronix's benchmarks, he's already proven it as fact.
@@CyberGizmo I'm a regular at mr. Larabels eminent site and I can't recall seeing any game latency measurements there. I can be wrong but I don't even think game latency measurements is part of the phoronix test suite (?).
With all due respect sir, could it be that you've browsed some articles in a bit of haste and mistook frame time graphs for latency measurements? I mean they're after all both specified in "milli seconds".
If not, please point me to the article in question and I will stand corrected. Thank you!
@@jonbjorkeback9499 I found about quote a few some of them show X11 ahead (NVIDIA) some show Wayland ahead (AMD) probably more: www.phoronix.com/search/Wayland
Probably speaks more to NVidia lack of support for Wayland than X11 ability.
My real issue with X11 has more to do with its lack of support from Xorg Foundation, no major updates since 2012 and they only fix major bugs...not good
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.
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.
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.
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'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.
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.
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.
Yeah, I've been wondering for a while and this was pretty insightful, thank you.
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.
Very good video. 2:17: You are confusing the topic here. X11 and Wayland, are not display servers, but display server protocols. Mir is a display server and it uses Wayland. People were a bit confused by Mir in the beginning, because it intentionally hid the display server protocol by requiring Unity client applications to rely on libraries implementing the display server protocols. This was to enable fast development for its primary audience, which were people wanting to write converged apps for Ubuntu Personal, which would be adaptive apps being able to run on both phones, tablets and desktops. This made it special, as you need more efficiency if you want to run a desktop system from a phone and you would need ways to better utilize RAM, hence the opposite approach to buffer allocation.
nit picky - but show me please how you can have a protocol without a server. it is both my friend
@@CyberGizmo: It's the difference between specification and implementation. You usually have the specification first, so there's no problem to have a specification without an implementation. In the case of Mir, they had an implementation but not a specification, because you weren't supposed to rely on the DS protocol directly anyway. Most X11 software don't implement X11 directly, but rely on toolkits and such.
It was very informative and I enjoyed it. Thank you for your help!
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.
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.
Hey, I also have the HAL9000 on my wall - And I recognized the status monitor below ;-) very nice!
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
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.
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.
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.
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?
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.
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.
👍👍- Another great explainer. Thanks!
kde lover and wayland here,because i need it for gaming
nice content Sir
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.
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 found the diagram at 0:39 to be quite hard to read. I'd recommend using a tool like excalidraw, which will keep the hand-drawn feel while being much more legible.
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.
Wayland on Plasma 5.25 was giving me a weird issue where my PC would wake up from sleep, but my monitor's display wouldn't. In some monitors, trying to shut down my PC would shut off the display but leave the PC running.
On Plasma, X11 will remain my default until I feel confident running Wayland again.
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.
Thanks Mate.... Always .... Simply the best explanation... Thank you...
thank you for a clear and excellent talk.
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
2:08 Ubuntu Mir Protocol is dead. There is still a display server called "Mir" from Canonical, but it uses Wayland nowadays.
They did another release on 24th of October, its not seems to be dead, also why they dont use MIR in Ubuntu?
@@StefaNoneD Oh, thanks for correct me
2023, still using Wayland and have not rolled back. Chrome, MS Teams, VS Code, the entire corpo basket works.
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
Wayland gnome works perfectly for me for months. no issues whatsoever either working or gaming.
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.
What an interesting talk - thank you!
Nice, will you be doing a video comparing pulseaudio and pipewire.
I'll add it to the list, Jared. Thanks for the topic suggestion!
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.
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
Off-topic, but your channel is awesome. Just subbed.
Thanks Sean
as junior, thank you sir
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🙉
Man, another awesome video DJ👍!
Thanks Felix
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!
I'm sure Wayland will be great long-term. At the moment, however, it's not usable for me. As of COVID, desktop video conferencing is ubiquitous, and Microsoft Teams doesn't support Wayland.
Not sure about the other video conferencing systems, but it doesn't matter. As long as one of the popular systems is unsupported, Wayland isn't usable. I need to be able to use whatever the other people in the meeting are using.
One thing I've always wondered - why is it X11, eleven, not some other number? I had assumed in the past that the first X was improved and called X2, then X3, etc. and maybe in the future we'll see X12, X13... but that hasn't happened. Just a bit of talk. I do recall in the late 1990s an attempt at something called "Y Windows" but it vanished.
I've tried wayland on KDE and it works great mostly, unfortunately the reason I even switched to it - better performance in a particular game - also created problems (that I personally blame on the game), namely weird mouse jumping issues and worse support for switching resolutions. Also one KDE update broke positioning of all KDE-native control panels so start menu, bluetooth menu, battery menu, etc were all horizontally centered.
I wish it were even better supported, bc I did have significantly better performance in that game in particular (20-50%) so I'd switch to wayland whenever I played that game despite not being able to use the mouse in that game.
what was the game if you dont mind me asking
@@nonholographic It's the critically acclaimed MMORPG Final Fantasy XIV, which has a free trial including the entirety of A Realm Reborn AND the award-winning Heavensward expansion up to level 60 with no restrictions on playtime!
@@vocassen... Even here this meme finds me. I play on sargatanas lol
I am Using now KDE Plasma Wayland for years as my daily driver and for me it is better than X11. I browse with it look youtube, email/office, play all the games without problems. Also recording the screen does work. there may be a feature i may not use and is not implemented, but i don't know any for now. everything works for me and also is very performant. When you are looking to test wayland you have to judge every implementation seperately, it is not like it was with X11 where everyone used the X11 server as basis. Every Desktop ist virtually implementing it for themselves ofcourse (hopefully) always compatible with the Wayland Protocol Rules.
(for years is now like ~ 2 years without going back to X11 i don't know it exactly i didn't mark it in my calendar :D)
[of course AMD Radeon Graphics Card user with open drivers]
I had to check the date this video posted thinking it posted in 2019, when problems with wayland were exactly as described. I'm on manjaro-kde with wayland and play many games, steam games (proton), do godot game dev, OBS screen record for my youtube, etc... all the stuff that he says wayland (specifically kde) isn't ready for. Maybe this guy is using an LTS from 2019?
The KDE list came from KDE's website, and were current open issue, one of the devs said those issues have been closed as a reply to this post...maybe they need to update their web site.
Keylogging does actually work with wayland too, there is already a prove of concept.
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.