 Okay, let's get straight to the point. From now on, the GNOME development is doing its first step towards deprecating drumroll the X11 session. In fact, as you can see in MergeAquest 98 and 99, the ones interested by the change were talking about the GNOME xorg desktop file is being removed along with the GNOME session X11 systemly targets and the whole code related to them. However, there's no need to panic because even if the 98 MergeAquest LAN sub-stream X11 functionalities will still be there. They can be simply restored by reinstalling the desktop file that I mentioned previously in the appropriate location because that's the only change in this MergeAquest. Basically, nothing is important enough to block this because it's an important next step to make sure that developers understand that GNOME won't offer support for X11 for much longer and users as well. So the plan is to push this change in the near future. The 99 MergeAquest, though, cannot be reversed because it deletes a significant if not all of the code related to the X11 implementation in matter. As a result, there is a significant debate surrounding this issue. People are worried that it could cause problems with the desktop, so one idea is to postpone its implementation for a few years. Particularly important for the discussion is the fact that many other desktops use matter as their window management. I'm thinking of something like Badge, I think, and also maybe elementary as this kind of thing, although I didn't check. So what would happen is that if matter drops all the code related to X11, then those projects would have to either drop X11 as well, even if they are not ready to do that, or they simply would have to fork matter and maintain their own, which would be a lot of resources wasted just because of that. So you can see the controversy. So let's dive into this discussion. Why are they dropping it all off so suddenly? Well, actually, if you look at this article on GNOME's website, it's clear that their intentions to support Wayland over X11 is deeply rooted back in 2017. They stated, X is showing its age. It has been kept alive for a very long time by means of adding more and more extensions to the core protocol. The Wayland protocol is a much linear definition of a modern compositing base display system. We don't need to carry around many obsolete parts of the X protocol any longer. Some problematic parts of the X protocol, such as grabs, are simply not present under Wayland, which avoids a whole class of problems. As we all know, less code means less vulnerabilities. So this decision would make the codebase easier to maintain and improve, which would lead, ideally, to a more stable and feature-rich GNOME experience. Matter developers could focus, as an example, on adding HDR support and better multi-monitor support. When is that coming? That sort of things. Many might argue that a lot of X software is not capable of running under Wayland, but or might even be seriously broke. By the way, just before we go on, this video is unsponsored. Nobody pays for it except for donations and much less of ad revenue from it. So if you want the writers to keep writing scripts and me to keep recording everything and the editor to edit everything, and this happens every three days, because I do publish a video roughly every three days. That is a lot of work from each of us. So I would seriously appreciate if you could help me reach the goal that's now floating above my head. It's a monthly goal. And to reach that, I've got Patreon, got LibraPay, Ko-Fi, PayPal, anything you can think of. But let's get back to Wayland, because this is important. How come that these two ways of interpreting the role of a display server protocol cause such differences? So let's make that clear. A display server is a program that coordinates the input and output of its user with a writing system, hardware and other users. It communicates using the display server protocol. This protocol is crucial in any graphical user interface, specifically the windowing system, which is handled in KDE by Kevin and ignored by Matter. In X11, the window manager of the desktop environment puts windows where they should be and makes the title bars and frames. In Wayland, the display server and the window manager are being handled by the Wayland compositor. In order to create the window needed for the application to render properly, the client's application must talk to the X11 server before the compositor creates it. This system works, but it operates slowly compared to modern standards and newer systems like Wayland. On the other hand, Wayland chooses to rely on client-side rendering, where the application talks directly to the screen handler without a middleman server. This approach can reduce load times and facilitate easier implementation, thanks to Wayland's very simple code base. Wayland also offers support for sandboxing and isolation. Editor just keep all three, one of them is going to be correct, which makes it more difficult for malicious applications to interfere with the other applications on the system. However, GNOME project managers and developers are in a tough spot because not everybody agrees with these requests and their concerns are about what we talked about earlier. They fear the inconvenience of missing some features in Wayland that are well implemented in Xorg or having some incompability between software. As a bit of a personal story, I still cannot use Wayland on my laptop. Actually, yes, I can use it on my laptop, but not on my main computer because I do use a graphic tablet drawing tablet, sorry, instead of a mouse, and the drawing tablet support is sadly not as good. So there is a large pool of people running GNOME desktops every day begging not to drop X11 support for a while. Among the comments on the two merger quests mentioned earlier, there are more than a few expressing dissatisfaction, showing some problems that could be defined as blockers, something that could stop these merger quests from passing through. People are, as an example, talking about accessibility support in the Wayland session. According to these users, it lacks some accessibility features users depend on, such as screen reader keyboard shortcuts. There is an ongoing effort to achieve this, but sadly, the fact is that today accessibility still works better on the X11 session, and that's something that many people just cannot give up. Or even artists demand to be heard, as the GIMP maintainer says, we are still ready to accept the inconvenience of a less optimal support over completely dropping support. Because in one case, we can still at least use GNOME, whereas in the other, we are forced to do something else, to use something else. Or X11 still has a slew of features that on Wayland are either incomplete or outright nonexistent. And there are still issues with remote streaming applications from Wayland, and GNOME Remote Desktop isn't a solution for everybody. If I could do the same thing in Wayland with almost the same performances as X11, I would be happy to use Wayland, but sadly, it's still not the case. So this is a very serious topic for those who rely on X11 for some features that are not so good on Wayland, such as, sadly, me. Some may feel that those concerns are excessive. If you are not very well versed in GNOME and Wayland, it may come as a surprise that unresolved problems can cause users to switch to X11. But the situation is even worse if you happen to use NVIDIA drivers. Properties in NVIDIA drivers do not offer the same user space API as their open source counterparts. While the open source drivers for Intel and AMD facilitate the widely utilized GBM API, NVIDIA opts for the less commonly adopted AGL Streams API. Only GNOME and CADD Desktop or Compositors fully accommodate AGL Streams, and GBM API support has only been added by NVIDIA starting from driver version 495. However, this situation is not as smooth as it should be. The same happens with CADD. In fact, it is not possible to configure it if the NVIDIA driver is older than version 495.44 because KWIN is no longer compatible with those previous versions. Another issue worth mentioning is MATRA's situation. MATRA is a Wayland display server, an X11 window manager, and a compositor library. It juggles between the two different roles depending on which protocol is used. When used as a Wayland display server, it runs on top of KMS and LibInput. It implements the compositor side of Wayland core protocol, as well as various protocol extensions. When used on top of Xorg, on the other hand, it acts as a X11 window manager and compositing manager. GNOME itself isn't the only one deprecating its X11 session, though. Fedora is also planning to drop Xorg support on either Kiri Plasma 6 and GNOME for its 40th release. They, in fact, stated in a proposal, Wayland has been our default session for a long time and has matured considerably. At the same time, the X11 session isn't getting the testing it needs and is an additional resource burden. So now we know for a fact that Fedora 40 will be shipped only with Wayland support, and that's huge news, because that would only be the start of a chain reaction. However, it's worth to note that the support for XWayland will not be interrupted, obviously, and it will still be possible to execute X11 software on Plasma Wayland. Speaking of KD, how does it fit in this context? Well, as you can read on the KD website, the aim is to be able to run the same banners under both X11 and Wayland, but I have to say the KD community is trying hard to locate and resolve the Wayland problems that cause a worse user experience than X11. In particular, Plasma needs Wayland support as we are hitting on the limitation of X all the time. We are aware that the X protocol was created for older use cases, and Wayland will allow us to composite the screen in a more useful way. Considering that KWIN was created as an X11 window manager and eventually developed as an X11 compositor, it seems reasonable to ask, why not build a new Wayland compositor entirely from scratch? And the answer is, sure, do you have like a million bucks handy and like a couple of years time? Sure. What question is that? The majority of KWIN is X11 independent. KWIN is a very complete and stable window manager. It has been developed for over a decade. Creating a new Wayland compositor with the same capabilities seems almost impossible if started from scratch. In the last KD iteration, our focus was on migrating Plasma to the new Wayland display server technology, and the process has been quite a challenge. But despite the difficulty of the work, it is proving successful as Wayland offers several new ways of interacting with your desktops and new features, as you can read in the latest release notes on the official KD website. The Wayland support in Plasma 5.27 is better than ever with numerous backfixes and improvements in reliability. Also, artists will be pleased to learn that design applications such as Krita can now recognize pen tilt and rotation on drawing tablets. Plasma on Wayland now enables smoother scrolling through long views with its support for high resolution scroll wheels. Moreover, it has added the global shortcuts portal for the standardized user interface in settings and editing global shortcuts for Wayland apps. Additionally, Plasma on Wayland can now automatically adjust to the scale factor of your screens, saving you the hassle of doing it manually. As the developer Nate often says, I think publicly as well, but he said it to me at least once privately, switching from X11 to Wayland is not switching from a version that's more supported and has less back to something that is less supported and has more backs. It's not like that. You switch from something that has significant issues to something else that, yes, also has some significant issues, but at least Wayland is supported and those issues are being worked upon. In conclusion, I believe that the benefits of merging this request outweigh the costs. I do think it is good to merge this request to remove xorg and make Wayland only, but this should only take place if the transition is gradual and does not burden the user experience. When the time is right, this natural evolution to a more advanced solution will be the better answer for everybody. I want to add that Wayland is the future of Linux, no question about that, and it's crucial for GNOME to be able to be at the forefront of this change. By becoming only compatible with Wayland, GNOME can help speed up its use on Linux and eventually all application developers will switch to Wayland. This will benefit all Linux users, not just those who use GNOME. By the way, I'm still not sure about the lights, maybe I should have turned this off, I don't know. Thanks for watching.