 Hello, everyone. I'm sure everyone can hear me now. And my name is Neil Gomp. I'm a KD SIG member. I'm here to tell you about Fedora's journey to Wayland with KD Plasma. So let's see. Before we get started, I wanted to just talk a little bit about myself just real briefly. I'm an open source advocate. I'm a contributor and package maintainer in Fedora, open SUSE, MAGIA, and OpenMendriva, as well as a number of other distributions, but those are the most notable. I'm a member of the Fedora Engineering Steering Committee, and I'm a member of the Open SUSE board. Professionally, I'm a senior DevOps engineer at Datto, who's kindly also a sponsor of this lovely event. I'm a developer and maintainer of package, build, and release pipelines using the OpenBuild service, and I'm a packager and back porter. I'm going to talk to me like afterwards and we'll get a, we'll have a fun conversation about how, you know, back porting is something everybody does and it still sucks. So that out of the way. Let's talk a little bit about Fedora KDE. So Fedora KDE slide should show up about now, right? In theory. So Fedora KDE is a special interest group. It packages and maintains the cute stack of the KDE software ecosystem for Fedora, and Red Hat Enterprise Linux starting with RAL8. We produce the KDE Plasma Spin, which is the main deliverable of the KDE SIG, and it offers a curated experience to showcase KDE technologies on the Fedora Linux platform. I'm not sure why it lags so much between me pressing the button and the slide changing. That's interesting. So we're here to talk about Wayland and KDE Plasma, but before we kind of do that, we should go over some basics here. Wayland the protocol. So it's not quite the replacement for the X11 protocol. It's intentionally designed to be quite different. It restructures the graphics stack to simplify the pipeline. You know, as I like to say it from program to pixel. Another way that people say this, it's about, you know, ensuring perfect frames, making sure, you know, that, you know, the delivery of graphics is straightforward and simple. So it prioritizes minimizing latency and context switches for rendering graphics and provides a framework to easily layer more capabilities as protocol extensions. The very core Wayland protocol actually doesn't do a lot in order to have a functional Wayland based desktop environment, whether it be a simple window manager like Sway, or a full blown desktop environment like KDE Plasma. So you need a number of extensions that protocol extensions to support various functionality that these environments require. And the reason for that is so that the process in which all these things are done are well defined and able to be secured because these extensions also means that you understand like how these things are being done and it's very straightforward and standardized. This is in contrast with how things are done in the X world, where you wind up seeing a lot of different approaches for doing the same thing kind of based on architecture and lack either with full knowledge or lack of knowledge of how the stack is supposed to work. And actually, that causes a lot of problems when they're moving from X to Wayland because there may be impedance mismatches. But, you know, as I mentioned, there's, you know, differences between X and Wayland. And a lot of people will say something about, you know, Wayland the server maybe like they'll think of it like as if they're it's a thing similar to X 11 but it's not exactly a thing so unlike with X 11. It doesn't separate the desktop window management service which you know you either call a window manager or composite or a desktop compositor from the desktop rendering service which is the X server. These two are merged into one which Wayland terms the compositor it directly interfaces with the hardware through the direct rendering manager in the kernel along using things like kernel mode setting and stuff like that. The compositors are part of the desktop platform rather than separately developed so generally speaking you tend to see that, you know, for a desktop environment or user experience that is graphical. The compositor is actually essentially part of the experience as a whole is developed together with it. So there's, you know, pluses and minuses do it but the main advantage here is that you can build a very tightly integrated experience where you have a seamless pipeline, again from program to pixel, where everything understands how it's going to work and that and the way that things actually happen in your desktop are reliable and and performant. So, Wayland on Katie plasma is done using the Quinn, Katie window manager, which is the compositor used in in Katie plasma there is a fork of Quinn base called Quinn FT. It's basically like gutted everything and, and built it on the WL roots library for building Wayland compositors. But ignoring that for a little bit with Quinn, which is what we use in fedora Quinn, essentially interfaces with the plasma shell environment to directly orchestrate how the desktop manages the graphical environment. And this architecture is in contrast with GNOME which has a library lib mutter that is pulled into GNOME shell, which makes it a unified process for GNOME. There is an advantage here and that the unified process makes it simpler for carrying data between these things because there's no IPC involved. Sorry, inter process communication, otherwise known as IPC. There's no IPC involved, but it does make it less reliable because in the event that something goes wrong at the compositor code, your whole desktop session goes down. The Katie plasma implementation of this implements a level of separation that allows for the compositor to to gracefully fail and restart without completely taking down your session and all your applications. A complaint that a lot of people I hear talk about with Wayland is that, you know, if the Wayland compositor dies, everything goes with it. This is actually not a requirement. This is more how the desktop or the wind advantage or whatever environment tends to implement this. So GNOME, sway and a lot of others, they tend to do this single process model where there is no recovery mechanism for when, when it fails. But in Katie plasma, because of the architecture between Quinn and plasma shell, you don't tend to you can actually recover from a failure without taking everything down with it. So we should go on to Wayland then right. So onward and upward, onward and upward, as I said, and that means, you know, making the changes so I switched plasma workspace. But by default with Fedora Linux 34 and we switch Quinn as well. That seems like it should be enough. I assume right like that's what the change said so it says we're done now right. Well, exactly, not quite it's not exactly done here. So those were the basic changes to start having the desktop environment preferred but as it turns out there was some work to be done. So SDDM, the simple desktop display manager is the login manager. Front end creator such that is used with Katie plasma desktop, unlike the rest of Katie plasma this is actually not part of the Katie project and this separate project, but it needed some work done to like make the wayland thing go properly. So the first thing to do was to make it so that preferred Wayland sessions over X 11 ones. If Wayland and X 11 are installed in the same system, we should select Wayland first. Easy peasy. But then there were some other issues like we discovered that the shell isn't getting correctly set so if you used an alternative shell on your desktop environment like I did, I use fish and my desktop. So running in Wayland it just didn't do it. It just sort of said, you know, and whatever, but that's not great. And having bash always even when you don't want it is not what anyone particularly likes. It took a while to figure this out. Embarrassing long while to figure this out but went through finally figured it out and fixed it. And so that means, you know, we had the login shell correctly, but there was still one more other thing that wound up initially like really screwing the environments up. And they discovered at some point that Anaconda just kind of refused to start in the Wayland session. Took a bunch of, you know, crazy debugging sessions and I got some help from some folks I knew who are like real big into the Wayland space and they helped me like diagnose the problem. I eventually filed a bug report with Katie upstream and they were super prompt and found a fix and I back ported it. And we got Anaconda working. So we're good now right like right right we're good. Everything should be great like we have the installer working we've got, you know, the sessions are preferred it will boot up it like loads the desktop looks great fixes coming in for 521 that were like super Wayland focused. Well, not exactly. Like, there was a last minute bug of doom and this last minute bug. As I say last minute, I kind of mean this. This bug showed up one day before, before the final before Fedora limits 34 is GA, and it was a doozy. Basically, the desktop didn't load when you were running in basic graphics mode like so if you and if it turned out like kernel mode setting wasn't working or like you were on the Nvidia driver. You're in the hardware and the and you need to go back to basic graphics mode like your Wayland session would just basically be stuck. It wouldn't load turns out in a Wayland environment, you actually need kernel mode setting. And while it is while Katie plasma does have a fallback mode using the frame buffer device, so called FB dev mode. It doesn't work. And nobody's entirely sure why it doesn't work, but we also all know that FB dev in the links kernel has been deprecated for like a decade. And so we really don't want to go there. So we didn't. Instead, I sort of hacked in support into SDDM for automatically disabling the Wayland session when you don't have the ability to use kernel mode setting. So that's what happened and then I made the changes to SDDM so we added a patched SDDM that is downstream in fedora that basically checks to see if no mode set is if there's a flag file on disk and if that flag file exists. Hide all the Wayland sessions just don't process them and don't show them up. And then, and then after that, I had to make sure that the Udev rule that we used actually worked. So we made the Udev rule that actually generates this file to fire whenever the no mode set command line option is passed to the kernel, which covers the wide gamut of cases where this could be a problem. But we weren't exactly done yet because well we did fix it for the installed system but we still didn't have the live environment done so the last bit to actually, you know, fix this bug of doom to so that we could release fedora Linux 34 was to implement that logic into our horrifyingly large weird script that actually is used to boot the live environment. It's called live sys and live sys late. And basically we had to like inspect the kernel parameters and like generate the file manually the same way that you would with the Udev rule, except we had to do it during live sys because that's how that had to work. And in the end, we actually did make it we we leaped into the future. And now Katie plasma runs with wayland by default, rather than the legacy excellent session with all the caveats that I mentioned earlier, right like there's, we still can't do it with no mode set we still can't do it with We still, while it does kind of work with Nvidia, my understanding is that multi monitor is kind of broken. That is supposed to change. As there are improvements coming down the pipe from upstream in Mesa, and in the Nvidia driver. That'll hopefully land within fedora Linux 35 timeline so I'm crossing my fingers and hoping that that'll actually come because that'll make things. So much easier. But this gives us a ton of benefits we get smoother graphics greater performance and lower resource usage. Like I clocked it and actually checked in the on my computer. So I'm not saying that everyone will see this but at least on my computer. The, the wayland session is a full 120 megs of RAM, lower than the X 11 one. And that's fantastic, like that's a lot more free round to be able to do other things. And the plasma session itself is with Quinn and all that stuff is, according to the C group where it all starts in with plasma system monitor. The total, very neat, actually does a good job of like showing you how much resource usage you have the total amount doesn't really exceed 200 megabytes of RAM when idle, which is impressive for such a featureful desktop environment using I have never seen that on another desktop environment running at all, whether X or wayland with the kind of services that have to run in the background to support a full desktop environment. My laptop that runs fedora workstation, you know, I have one that does. And it's almost like more than two or three times as much RAM for just the idle basic desktop environment. The fact that Katie plasma is so small is amazing. And like it's, it's really, really good. So what's coming in the future for this like obviously the basic stuff is done and we've got all these caveats and things. So what are what are we planning to do next to kind of, you know, make things better. So on the bucket list, I have SDL one being replaced with the compact library SDL one to compact, which shims SDL one applications to use SDL two. That's landing with the door Linux 35 that that's coming now it's already done the works been implemented. This gets us onto a more more modern code path and gets us to being able to get better performance for games, even in a wayland environment, even running on X, even when the games are ex wayland. It's going to be SDL two preferring wayland native by default as opposed to running an ex wayland. That's going to come either in fedora Linux 35 or 36 this sort of depends on how things kind of hash out with the upstream wayland protocols and stuff. It may not even arrive like in GA it may arrive as a post GA update with the next version of SDL. And there's been a ton of improvements and a lot of focus on improving wayland support in SDL upstream and there's been a lot of great work working with the folks at at GNOME working on live decor to get, you know, the client side decorators and versus service side decorator problem sorted out for GNOME for games with SDL. And we're basically all go except for there's like a wayland protocol extension that needs to be implemented. And there's some bugs within video that hopefully will be resolved in the near future to make it so that SDL upstream will choose to prefer it. We may do it earlier because of what our support matrix is a bit smaller than than SDL upstream, but we'll see I'm, I'm keeping a close eye on that and and we'll hopefully have some further news to share there. So SDDM using wayland is something that I'm targeting kind of for door Linux 36, maybe a little bit later it sort of depends. This is kind of contingent on SDDM next release coming up sooner rather than later. And also some patches that are our downstream SDDM that are SDDM package has that we need to clean up, we need to figure out and and and do stuff around that upstream SDDM recently game support for running in a wayland reader right now what actually happens we start an X session, just for SDDM and we throw it away when we're done to load the plasma desktop. We want to get rid of that that slims things down simplifies the pipeline and let's us do fancy things like, you know, direct fadens like all kinds of cool stuff smoothness. And of course further improvements in the wayland experience in collaboration with the Katie community there. I am pretty much regularly giving feedback to Katie upstream about the sort of stuff, seeing what I'm doing file bug reports, you know I know racks and and Jan gruelik are both like working hard with me on this to try to make this work so we have a fantastic experience. And I'm just super excited about where things are going to go because with this with this work that we've done upstream for and to make wayland like something that is really in great shape in Katie plasma and showing that off in fedora first it, it brings us to the forefront in the Katie community brings us up to the forefront for the Linux community, and we're driving innovation forward and making the best Linux desktop experience that I think we could ever give. And I am really, really looking forward to making it even better. So, you know, if any of this stuff excites you of course, come and join us. And, you know, in the fedora Katie sick. We have our issue tracker on Pagora oh got a mailing list, our matrix room, and our IRC channel. Most of us are actually in the matrix room and our IRC channel is bridged into the matrix room. And of course if you're more of the async type the issue tracker in the mailing list are great ways to collaborate with us. So, any questions from anyone. I know I kind of went a little bit fast but I wanted to give a lot of time for people to, to ask me about details and stuff because I think this is this is the good stuff. And, and frankly this is I, you know, I want to give a lot of thanks to the Katie community you've been really helpful with making this happen and it's just been such a solid experience and Katie Plasmon Wayland is so good. Okay, I don't see any questions in the thing let's go look at the chat. So, someone's asking do I believe Nvidia will support Wayland fully at all. Yes, I do. I am surprisingly optimistic about this which is weird for me because I don't really like Nvidia very much. So some context here, the, the folks at Nvidia have been contributing to Mesa lately over the past like six, eight months they've also done some work on ex Wayland itself. And this is something I want to congratulate the folks at the Red Hat desktop team because they've been working really closely with the folks at Nvidia to make this a make this possible and they're they're working really hard and I think that they are going to because one of the things that they changed was one of the things that they changed recently was that they added to Mesa the ability to use alternate back ends for GBM. For some context here GBM is the generic buffer manager I think is what it's called. And this is the this is the underlying mechanism that is used by all of the graphics drivers except for Nvidia for for handling buffering graphics requests pipeline shaders and stuff and passing into the GPU and doing stuff. Nvidia uses EGL directly through the technique called EGL streams, and this is incompatible with GBM. And the consequence of this is that for compositors to support Nvidia properly. They have to do the work to support to code paths for this and EGL streams isn't exactly well adapted for all the cases that GBM actually handles and thus Wayland requires. And for a long time it looked like Nvidia was never going to do anything about it but this year, they did work upstream to make it so that they could add their Nvidia drivers a back end for GBM. And they did a bunch of work to support x Wayland hardware accelerated rendering. So what it looks like is that we're going to see the Nvidia driver updated to have a GBM driver module that will plug into Mesa and it will get auto selected and there are other benefits to this I don't fully understand everything that's going on with it but like from the best I can gather with what limited knowledge I have of the stack, you know with the way that this architecture works it's also becomes possible to smoothly handle the graphics as part of it like you can do Mac OS style smooth like this application needs to run with the dedicated GPU so transparently switch the desktop over, and we can do this as a very minimal copy and write operation into the memory into the GPU memory because between the two GPUs we can seamlessly switch back and forth with no flickering. That's the kind of stuff that these improvements will bring to the table like we've already had this for a while with AMD and Intel, and having this with Intel or AMD with Nvidia is going to be stellar and it'll be something that I don't even think I'm not sure, but I don't think Windows can do this. And so that's going to be really a game changer for a high quality desktop experience. So, someone mentions in the Q&A I think this is a comment and a question. Oh yeah, Katie is a spin. I think it's the only one that spin that blocks the release. Yes, so this is a spin that blocks the release which essentially gives it the same kind of QA attention and quality transition. And the second part of this, are there any plans to give it more visibility and to stop being called the GNOME flag distro? Well, I want to. This is something I've had a conversation with Fedora Council about. We are trying to become more prominent in this. We actually sponsored Academy earlier this year at the highest tier. And I am so happy to see that this year's Nest, we have so many KDE centric talks. It shows that there are people really excited about KDE technology in the Fedora community, and I think it's just fantastic. I don't think we'll stop being called the GNOME flagship distro, but I would like to also be known as the KDE Plasma Flagship Distro. Being the flagship distribution for both is not a bad thing. That's a great thing. So yeah, like, I absolutely think that's going to be fantastic. So another person's asking, when will it be available for REL? And Troy Dawson actually replies in here. It should be an Apple 9 haven't tested in CentOS Stream 8, REL 8.5. So I have actually tested in REL 8.5. So it will be available for REL because it will be available with REL 8.5. Most of the stuff that I did is actually included as part of our rebase to Plasma 522, and Plasma 522 is going to be an Apple with the REL 8.5 release. It is not perfectly functioning right now, and my understanding is that we are going to work with the Red Hat folks to get the necessary backports for the LibWailin components to the REL.5. So expect to see a lot of this coming in the near future, like this fall. So we're going to talk about this in detail, but we're going to put a lot more attention on supporting REL than we have in the past, and that includes having a fresher KD experience. And if you're interested in that, please attend the talk about that. That's I think tomorrow, or it might be Saturday. I don't actually remember, but it's on the schedule. So someone asks, how are the integration of GTK apps on KDE Plasma? They're pretty good. So we went with a, okay, so Troy Dawson actually mentions it's Saturday, the KD and Apple talk. Going back to what I was actually asking is saying how is the integration of GTK apps on KDE? It's about as good as it's going to get. So we use, because Fedora naturally has to ship a fair number of GTK applications, we make sure that the GTK experience isn't terrible. So it looks, it looks fairly good. It renders fine and stuff and the, we have mostly fixed the bugs that were related to GTK and Qt application interoperability on Wayland. So that's all settled and sorted. The X Wayland to Wayland clipboard stuff is mostly sorted out. There's still glitches here and there, but should be mostly fine. For GTK applications, the main thing is that the styling is I think for some reason we're still defaulting to Adwaita, even though we've told it to use Breeze, but Breeze is there and whatever. We use the Breeze Twilight theme to make it explicitly so that GTK applications don't look ugly. Because when you use the Plasma Dark theme, GTK looks, GTK applications look like crap, especially GNOME ones where the theming is just broken. It doesn't flip the text colors correctly. So the dark on dark, it's just unreadable, that sort of thing. So with the Breeze Twilight setup that we have now, that's all fine. Everything looks great and we have a, and the GTK applications and the KDE Plasma applications read and render perfectly fine. Let's see. Any other questions or comments? Okay, someone says, my main, their main issue with Plasma Wayland is the absence of session support. Could you clarify what you mean by that? Because I'm not sure what you mean by session support. Session management. Rex, does this person mean like fast user switching and multi-session management? Is that what they're referring to? Because otherwise I'm not sure, because the KDE Plasma session works, it runs. Oh, that! All right, so the remembering, so to clarify this means remembering where windows are placed when you log out and log back in. So this is, so this is actually the code has been written. It's done. The Wayland protocol for this is called XDG activation that's been approved and implemented in Quinn for Plasma 5.23. So when we upgrade to Plasma 5.23 sometime in early November, I think is when we plan to do it, we will have that feature back. Because the reason why it didn't work was that there just basically wasn't an implementation for it. Like there was there was no code to like be able to provide that privileged operation to do that. The way it worked before in KDE Plasma was with the X session is that they basically monitored all of it and it basically logged where the applications were. And so that was done and now we have that stage and it's going to come with Plasma 5.23 in the fall. Oh, look, there's more questions. Oh, this is the session support Plasma Wayland. Yeah. So the person that asked this just to reiterate Plasma 5.23 coming this fall to Fedora Linux 35 and I think we're going to do also 34. Rex, correct me if I'm wrong, but I think when Plasma 5.23 releases, we will backport it also to Fedora Linux 34 because I don't know why we wouldn't. Yeah. Yeah, so Rex confirms. Yeah, we'll have it. So for Christmas or Thanksgiving, more accurately probably in time for the US Thanksgiving. So someone asks, do you think, do I think that X Wayland will become a drop in replacement of XOR? It already has. So a couple of things, a couple of the factors for this is that with XOR with X11 as a whole. The XOR implementation, which is the descendant of the X386 server, the one that has all the device dependent drivers and all that stuff for running X directly talked to hardware, all that stuff is effectively deprecated. So there is no expectation that there's going to be any real major further development or further releases within the next couple of years. And the Red Hat desktop team who has been maintaining it for the past decade and a half is set to pretty much stop doing this by the end of the 2008 lifecycle, which is in 2028 or 2029 rather. So anyway, because it's really going to go away in that timeframe, you know, getting up to speed and ramping up into a Wayland world was very important. And in this world where, at least in KDE Plasmus case, I mean, I can't speak to all the desktop environments. In KDE Plasmus case, X Wayland is for 99% of users pretty much at the point where it functions the same way that you'd get effectively the same experiences you would if you were running X11 natively. So if you're using pro-server applications that tended to do fancy tricks and stuff or they need hardware acceleration in the application, even with NVIDIA that is now working out of the box and NVIDIA has done a fantastic job in the KDE community to make sure that their stuff is working. So there's been a lot of effort in the larger gaming community around KDE Plasma because Valve has selected KDE Plasma as the foundation of the desktop technologies that are used for the Steam OS 3.0 that's going to ship on the Steam Deck. So, you know, I fully expect that to be a stellar experience. And the rumblings I've heard though I don't have confirmed confirmation yet is that Steam Deck will actually ship with KDE Plasma running Wayland because that gives them the best performance. And I actually game on KDE Plasma on Wayland. That was one of the original motivators for me to switch KDE Plasma to Wayland because I noticed that the frame rates were like 30% higher on one of my laptops with Wayland over X. Someone's asking, does that mean new NVIDIA cards or does that include relatively old ones? C cards released in 2018-2019. So, the X-Wayland hardware acceleration stuff was included in the NVIDIA 470 driver series. That's the driver series you need to get the X-Wayland hardware acceleration. I am crossing my fingers and hoping, though I do not know for sure, because again, don't work for NVIDIA. I don't know anything about them. Though the actual GPM enablement will also be in the 470 series, I'm not sure it will be. It may not be because it's a significant refactor for how the driver works, so that might be a new driver series. The problem then is that a lot of the older cards, like I think 2016 or 2017 or older may actually kick the bucket or 2015 or older. I don't know. I'm not too familiar with how the NVIDIA hardware versioning works, but I would assume that the next driver series that includes the full Wayland enablement will actually also include this in there, so it may be fine. But note, even today, you can use NVIDIA with Wayland with EGL streams on plasma. You'll have to go through some efforts to turn it on, and there's glitches with multi-monitor, pretty annoying ones actually. But it works, and X-Wayland hardware acceleration will work in that environment too. Let's see, questions. So someone's asking, are there any tiling extensions for Quinn on Wayland? So I don't actually like tiling, so I don't know too much about this. I know about Cronkite, which is the Quinn extension for tiling in plasma. Honestly, I kind of wish they would just build in the Papua style automatic tiling into Quinn itself, because that would be fantastic, and it really doesn't need to be an extension. And being able to have it in there and then configure key bindings for it would be a major step up. So I would personally like to see that, even though I'm not much of a tiling person, I like some of the tiling bits, so it'd be nice to have some of that workflow available in there out of the box. So someone's mentioning something about FreeSync for AMD cards is only supported on Wayland. If you have different screens with refresh rates, yes, that's true. So two things. Very high refresh rates are supported on KD Plasma Wayland. Different refresh rates per screen or display head or whatever terminology you want to use, that's also supported only on KD Plasma with Wayland. You want the best possible like high end experiences. Plasma Wayland is the way to go. Let's see, is there anything else from the chat or anyone else having anything to say? Oh, Joe, is this where a no user sits snugly with our fancy G2K problems? Funny. Eddie, I want to give KD another, you want to give KD. Yeah, if you, Eddie, if you find KD Plasma to be interesting, like, come along and try it again, like, we're always improving. And because we update KD Plasma continuously, like it's even in the Fedora stable releases, they're always improving. And, and yes, I am the person on Linux unplugged. Yes. Hi. Let's see, what else? I wonder, David, did I convince you to probably try KD Plasma as your main desktop? It's cool. Yeah, so I guess that's it. And I guess I'm going to give you all 10 minutes back because it doesn't seem like anybody else has anything else. Actually, you know what, let's add a little poll. Well, you try KD for a KD. And there we go. A little poll for funsies, you know, since everyone else loves doing polls during the sessions, I figured I might as well try it while we've got a couple of minutes here. Come in. And let's see how this goes. Someone actually answered, I like program manager, whoever you are, you make me, you make me chuckle, you're great. No joke though, program manager was like the first graphical environment that I actually used on Windows 3.1. So, you know, if you use Fedora KD with X, someone's asking, what if you use KD with X, if you use KD with X, try Wayland again. Just, just try it. Someone has, oh sure. Someone has a question out of curiosity. Well, go ahead and ask it. We're here. So someone asked, why doesn't why KD doesn't recommend changing the window manager? Oh boy. All right. So in, so this requires some, some background context here. Same goes for no. So there's a bar some background context. All right. So, in the X 11 world, there is this, the separated parts of the rendering stack. So you have, you have your render server, which is the X server, then you have your, you have your window manager component, which actually does the drawing and of the window borders and things like that. And then sometimes you have a third piece, which is a compositor, which does hardware accelerated rendering of the stuff inside the window borders. Most modern desktop environments actually merge window manager with the compositor. So they're one piece in the Wayland world, we take all three pieces and merge them together. Now, the reason why both KD Plasma and GNOME do not recommend changing the window manager and actually in GNOME, you can't do it because if you do, you will break a whole bunch of things. The reason why that's the case is because there is a lot of privileged service interaction that are actually implemented in the window manager for the applications and various desktop services. So, for example, you have to use mutter to load GDM for login, and mutter is required for GNOME shell to run. All of that is tied in because mutter is a library, that's the window manager part, and the compositor part, and that's a library that's pulled in by the applications. So basically do IPC with each other to hand off buffers and screens and stuff in KD Plasma world. It's a little bit more loosely coupled. There is some swap ability but like any, anything you swap has to implement all of the private privileged operations between plasma shell and the compositor. And so today, you basically only have Quinn and Quinn FT which are actually both descended from the same code base. In the Wayland world, you basically lose the ability to freely switch window managers and be able to have your full desktop environment function, because as part of the Wayland Arc, most, most desktops are making with their Wayland architectural changes. They're making the compositor contain the privileged desktop APIs. And so like swapping them essentially says you're okay with breaking a whole bunch of the desktop services. Actually, someone Jeremy. Oh yeah so someone is saying a fair number of machines I use are running the UEFI frame buffer which basically happens with no mode set so those machines are still using KDX 11 because it doesn't work otherwise or it didn't month or so back. You're right it still doesn't work. So here's the thing. There is a light at the end of the tunnel. And I forgot to put this in my slides and I should have but like there's a light at the end of the tunnel. There's something called simple DRM which was added to Linux and 514. So the simple DRM driver essentially replaces the framework that is used for FB dev UEFI FB and all these sort of things that so that you have, it takes the UEFI frame buffer or from and change it changes it over to kernel mode setting so like the the visa FB UEFI FB. So these things, they, they basically map over to the simple DRM driver. And while simple DRM pretends to support all the different DRM API things will just they'll just like do the proper thing to silently quit or fail or like return the correct responses. But most importantly, since it's in the direct rendering manager framework. Since it supports kernel mode setting, even if the kernel mode setting just say we can't switch modes. But because it's kernel mode setting. Wayland works. And so I am crossing my fingers that we're going to have this in either Fedora Linux 30. Fedora Linux 35 36 or so, whenever, but I'd really, really, really like to have it back ported into rel 9. I'd really like to have this feature enabled in rel 9 because having that feature in rel 9 means I have the confidence to completely get rid of the x 11 session because gnome is also affected by this problem for gnome, you cannot run wayland at all without kernel mode setting. So it actually will just not start and it will auto fall back to x 11 with no mode setting. So we just copy that behavior. If we have kernel mode setting, even with the UEFI frame buffer, we're in fantastic shape. We are able to use wayland without any terrible, terrible hackery. Another thing to point out specifically KDE Plasmash, there is a frame FB dev mode for KDE Plasmash for Quinn. It doesn't work. I don't know why. If you want to spend any time like trying to figure out how to make that work be my guest. I just don't have a clue how to figure it out but if you're if you're skilled in figuring that out work with the KDE folks upstream. And if, if we can get that working that I'm happy to remove that the fallback anyway and just fall back to FB dev. But it just doesn't work, which is why it why I had to do this. I was not expecting to have to do that because I expected FB dev to work but it just doesn't and I don't know why. Wow, three people like program manager. But I do like seeing that there's there's a good chunk of people who will try Fedora KDE with wayland. I'm looking forward to seeing all those new folks, you know using KDE technologies on Fedora with wayland. I'm looking forward to seeing all those new folks here who are already doing it. Cool. Well, let's see. I think that's it. We're at, we're like a couple minutes to time and giving, and I don't really have anything else to say. Well, someone saying there's a long way for KDE to beat I3WM. Well, well I disagree. I think I think KDE Plasmash beat an I3 handily. Now if we were talking Sway, then there's a different story here. Carlos, best way to jump on the KDE, use the spin. The spin's better because then you get all the presets done and it loads up correctly. Oh, hello person who I definitely know, or I definitely do not know, depending on your point of view. Sounds appealing but unfortunately multi monitor supports kind of a deal breaker. If you are not using. So multi monitor support does work with everything but EGL streams and video right now. At least as of the last time I got a bug report about it. So the thing is, I don't actually have any Nvidia hardware myself to continually test this. My hardware is so old it actually only works with Nouveau. So everything works for me, because I'm using the open source driver. And even though it's dog slow, all features work including multi monitor. But if you have the hardware, you don't come by and test and I know that the KDE community folks would be having to get feedback. Yeah, so if you're using Intel I GP or AMD or whatever. All of this works out of the game. So you should be you should be in good shape to be able to try Katie plasma. And like if you do have issues, come by to the sick. We're on matrix. We have a mailing list. And we have weekly meetings on Mondays at 1700 UTC, which I believe is 1pm Eastern's daylight time. And actually, I should admit reword the statement. It is code in the meeting is actually set against Eastern day Eastern time so it floats right now it's at 1 it's at 1pm Eastern so whatever that is in UTC will change based on whether we're in DST or not. So, yeah, if you have issues or if you want to come chat with us and sometimes feel free to hop in onto it our meetings are every Monday they're open to the community. The notifications with the link to the meeting thing is sent to the Katie mailing list for Katie mailing list every Sunday. So you'll always get a reminder if you're subscribed to the mailing list. So, yeah, come by, give it a shot. Totally. And yeah, I totally want more visibility for for Katie. I am really hoping that we can do that more as with all the stuff that's going on. I'm excited I'm pumped. I think we're the we're doing way better than we ever have before, and we'll keep getting even better. There's only a couple minutes left and I definitely want to give people the opportunity to go go to other talks get like staged up and ready. So, thank you all for coming to my talk. I'm glad that you all excited and I'm looking forward to seeing more people coming on to the Katie community through Fedora Katie. See y'all. Bye.