 I'm turning to my clock, so welcome Maven and Vlad for the Wayland Gold 2021 update. Please go ahead. All right everyone, so as Adam said, I'm Miren and I'll be presenting with Vlad Zahorodny our progress of the Wayland Gold. Next we'll have a simple agenda and be introducing a bit of what is Wayland for people who aren't yet aware. And then I like some key improvements that we have made since last academy. And then Vlad will talk about the next goals and objectives and improvements that we are planning. And we'll have a speculative timeline in the conclusion at the end. First, what the heck is Wayland a bit? Wayland is the future of desktop on Linux. Well, it's progressing at least that way. And it was necessary. It's an improvement of our Xelevan. Xelevan has been the display server for many years now, but it is really showing its age. It doesn't have great support for ITDPI. It has really poor security model. And for all those reasons, XDPI has put together a new architecture to replace it, which is Wayland. And Wayland is not directly an implementation, but rather an architecture to simplify its implementation of new compositors. And Queen is one of those. And as such, the whole plasma is moving towards Wayland, because Queen is becoming a full-fledged Wayland compositor. And in 2019, the KG community elected this goal to finalize the transition to Wayland. And so that's why we are here today. So I like a few improvements that were made since last academy. First, just a reminder is that one of the main things that went on the lows is to have mixed refresh rates. By that, it means that different outputs can have different refresh rates, so that you can have a higher refresh rate on the side and a different one. Or if you have a game that's really heavy on the GPU, it can lower the refresh rate on there compared to the second screen. And really on X11, it wasn't possible by design. And that's one of the features that Wayland allows. And it's worth highlighting now because we have a few features relating to that that build on top of that. One very user-facing improvement that Alex did was the screencasting and Windows unveils of Windows. Output screencasting was improved drastically. It got a new implementation and rendering so that we can have nice thumbnails in Wayland just as we had in X11. And along the way, it improved screencasting functionality by allowing OBS, for instance, to properly record Windows and not just the whole output. Before, previously, it was only possible to record the whole output. Then we had a very nice improvement made by Vlad, which tried the improvement to the sub-surface implementation. It's a bit technical, but in Wayland, applications can divide themselves in sub-services. And previously, we didn't have a very good implementation, but now it's been sorted out. And it's been very visible for applications that make use of sub-services, like Firefox, OBS, or KMA, and has been a great improvement for the application compatibility. And I'm very pleased to use, to me, what's the main feature that allowed me to run most of the time on Wayland, just for the Firefox browser, maybe. We have a talk, we have currently an ongoing effort throughout making Queen Wayland more robust, so that we can have the common Queen Wayland dash-replace, as we had for X11, sort of. And David will talk a bit more on Sunday about it. I would go to much more detail, but it's quite important to have more robust sessions. We have activities. Cavin implemented the grounding work for proper activity support in Wayland, so activity allows Queen to handle windows and group windows by this intermediate grouping sort. And this grouping logic is now implemented in Queen as well. It still misses a few pieces, but most of it is here. It still misses a few pieces compared to X11 support, basically. And Alex did great improvements on the XDG activation and startup feedback. So that's a great work that needed to be done upstream within XDG protocol specifications, so that applications can send activation requests, so that an application can say, when you click in a link in CarMail, that you can have Firefox focused afterwards. Firefox opened the URL and focused. And in Wayland, we treat security seriously, so we need to have a chain of responsibility, or an application must give explicitly the focus to another. So this protocol allows this to request that another application will be focused on behalf of another. And as I said, it needs to be cross applications to work, so it needed a standard protocol. And all of this also allows us to add the very famous bungee icon animation, so that we can have the application icon bouncing around the cursor while the application is starting up. It still needs application support to have proper support for it. But it's at hand. And then we have DRM backend improvements. So great shout out to Xavier Hogle, who did most of this work, and sorry for his last improvisation. We had a great improvement on the DRX scanout. So DRX scanout is great for gaming. It allows the application that's full screen to take control over the screen and queen the compositor will just fade away and just give all the GPU and CPU resources to the application so that it can run directly to the screen without any interference from the compositor. We have adaptive sync aka VR or variable refresh rates. It's great also for gaming to avoid stuttering. So if you have monitors that support it, we can have this feature. And another feature that was worked on back then was the multi-GPU and GPU outplugging support. It's about many laptops with discrete GPUs and well, with laptops that have integrated graphical units and then discrete GPUs also. So it allows to move over buffer data from GPU to the other and just allow better support for this type of hardware. And there are a lot of other improvements as well. So we had great screenshot optimizations. Now screenshots are really fast and it doesn't need to copy as much data between the compositor and the inspector code. We have color integration. Before we had the night color and color D. Color D is a demo to handle blue light depending on the time of the day. And we had night color. We did the same thing and the two would clash sometimes if you had the two installed on your system. But now we have a better integration and now they sort of complement themselves or at least they don't step on each other's toe. And so we have much better color D integration. And this is not about Queen but quite important as well for the stations. SDDM will have a gritter implemented using well on. So it's great for speed up. We can expect SDDM to start a lot faster because X11 is slow to start whereas a small compositor can be really more efficient. And with all those points said, I will leave the mic to Vlad so that he can introduce you to the next goals and next evolutions to Queen. So I want to talk about the next improvements that we want to make so where one becomes the default. So the first thing that we want to change is the scene. So the scene is a key abstraction that's used to describe what goes into every frame. Currently one of the biggest next goals is to make Queen Queen scene abstractions suitable for Wayland. But before we dive in, let's have a look at the current state. So the current scene design dates back to the inception of compositing in Queen. So it's somewhere around 2006. So conceptually the scene is just a list of windows sorted from bottom to top. So from my professional drawing, you can see that we have seen and it just contains some windows. So nothing more, it's that simple. So while the current scene design served as well on X11, an X11 compositing manager just needs to take off Queen buffers, compile them, compose them in a single buffer and put it on the screen. On Wayland it's a completely different situation. So the Wayland compositor has more responsibilities than an X11 compositing manager. It compiles its windows but it's also responsible for input handling, painting cursors, etc. And we constantly hit the limitations of the current scene graph. So to begin with, we want the scene graphs sometimes include items such as cursor or the drag and drop icon. But since the scene graph can only contain windows, we cannot do that. So we work around that by having role-specific painting code paths. It's a huge no if you're Wayland developer but we don't have any other choice right now. So ideally we must share code that paints windows surfaces, cursor surfaces and so on but we cannot do that. Another flaw is that all the current scene design is that it's not possible to have the painting scheduled automatically. So say a window is moved, window management code will have to schedule a repaint manually. As the past shows it's too error-prone and it's sometimes just too hard to get right. Another painful aspect of the current scene design is that it doesn't really work well for cursors. So as I said previously, Queen has service role over a painting code. And it sometimes doesn't work for drag and drop icons. So, yeah. Another outcome of having role over a painting code is that Queen is able to paint cursors only with certain client buffers types. So for example Linux domain buffers are unsupported which means that if a video game paints cursors using OpenJet or Vulkan, you won't see that cursor because Queen doesn't understand it. Which again is a violation of protocols and we need to fix it. It's a serious issue. So another painful thing about cursors is that they can have extensions. So in some cases such as creating a subsurface for the cursor surface are weird but there are also valid use cases. So the most notable example that I can come up with is using VP viewport extension to implement animated cursors. So if an application wants to display an animated cursor it could upload all cursor sprites in a big buffer called spritesheet and simply move the viewport inside the spritesheet. So this way the application will have to do less work on every frame. And it seems like the presentation doesn't play the animation but you should see the red rectangle move on every frame. So in order to handle this case, compiler needs to perform compositing. But again we can handle this case properly. So the root cause of all our problems is that thing that is that thing in terms of windows. So what if we break every window into smaller and reusable pieces? That's the main idea of the single redesign. The smaller building blocks of windows are called items. So on the picture on the left you see that we have a shadow item, decoration item and service item. And window item aggregates them into one window item. So with the same graphic design we want to fix the issues with the existing missing graph and make it more extensible for new features. We also like it to be declarative so meaning that Queen just needs to describe what it wants to be rendered and the same graphic design and the same graphic renderer will figure out how to do that and what parts of the screen needs to be repainted. Since there are things in terms of items, it can now contain arbitrary things. It's not limited to windows only. So as you can see the single graph can now contain windows as well as some other special purpose items such as cursor or drag and drop icons. So another goal is to... So you can view a monitor as a device with a rectangular region filled with a bunch of pixels but the compositor will use it as something more complex. So every monitor has at least associated hardware planes and plane just represents an image source that can be blended with or overlaid on top of other planes with a monitor. So the most important two plane types are primary and cursor. So the cursor plane represents just a regular mouse cursor and the primary plane is usually used to present other graphics contents such as windows or normal windows, desktop, background, etc. The key thing here is that planes are blended by hardware. It allows the compositor avoid performing compositing if the cursor moves. The compositor will just update the position of the cursor plane and the hardware will blend it with other planes. No compositing will be performed, which is really, really good because we do less work and it's better for power consumption and it's more efficient. So in order to benefit from hardware planes we also would like to have a scene graph per every hardware plane. Since we want the scene graph to be declarative the effects also need to change. We need a declarative effects API. It's worth noting that the animation effect already provides such an API. So we need to see if we can extend it and port the remaining effects to it. The JavaScript effects will probably not require any changes. More complex effects such as desktop, or present windows need to be really implemented using QML. The last two effects are a bit special because the previous QMaintenor already discovered issues with present windows and desktop windows, desktop effect. And there is a task to reimplement them using QML which dates back to 2012. So it's a bit old task. So the next question is when it's going to be finished. So some of the scene graph design changes already merged in or landed in 5.22. So you should see less visual effects in applications such as Firefox or other applications that use subsurfaces. There's still a lot of work ahead of us, but so it's going to take a while before we are done with this task. On a related note, I would like to discuss a bus to talk briefly about QT Quick and Queen. So QT Quick is simply an amazing piece of technology and we use it extensively in Plasma. So after trying it, you don't really want to go back to QT Widgets. So it will be nice to see Queen as a QT Quick Waylon compositor. We will share the same technology stack across Plasma which will open Queen for more Plasma developers. So it may not happen now, but I have noticed that it's going to happen at some point in the future. So Queen will become a QT Quick compositor. Currently, we have a few integration issues that are kind of big workers for the Switch. Besides that, there are performance concerns specifically QT with a default renderer that doesn't track damage. So it tries to repaint the entire window on every frame. So it means that if you use the blur effect and watch a video, the background behind the panel will be blurred on every frame, which is a kind of serious performance issue. So QT Quick 2D looks very compelling as it does track damage, but it supports only software rendering and we need something like QT Quick 2D which also works with OpenJOOHRI. So I don't expect the current situation to change in the nearest future, but if there are QT community members that are familiar with QT declarative code and want us to help with this, please contact us in the Queen IRC channel and we will discuss more in detail what needs to be done to make QT Quick compositor. So that's about Sincere. So the next kind of tricky topic is the timeline. So Waylon has been in the... Waylon session has been in development stage for quite a while and it raises a natural question when is it going to be finally ready. So here's my optimistic timeline. So in plasma 5 times, we're definitely going to stick with X11. In plasma 6 though, I hope that plasma session will mature enough so we can safely start recommending Linux distribution just to make the Waylon session the default one. It's also noting that Fedora is ahead of the curve in this area. They made the Waylon session default in Fedora 34 and they provided us inviolable feedback so it's really cool to see more first adapters of Waylon like Fedora. In plasma 7 or somewhere late in plasma 6, I hope that the X11 session will be dropped in favor of Waylon. As I said, it's a very optimistic timeline but I hope that it is going to be true. So in the conclusion, the plasma Waylon session is improving on a steady pace. With every release, we try to resolve as many as possible blockers. For basic usage such as simply browsing or watching movies, anything that Waylon session is already really good. You may experience some issues, minor issues with web browsers but for me, Firefox with native Waylon support has been working really, really good. For other usages, it may need some more work and in general, the transition to Waylon requires an enormous effort and it needs the community help. So there are multiple ways that you can help us that you can help us with this. So for example, test beta releases, file bug reports or submit code changes. For more details, please visit the Waylon wiki page. I think that's all from my side or from our side. So questions? Okay, thanks Vlad. Thanks, Meven. I guess you want to rejoin in case there are questions. So far, we don't have questions. So people, you know, at this point, you should know how to ask questions. There is a widget in the Matrix application. You need to use the webchat.kde.org. But apart from that, if you go in the panel, in the information of the room, you will see two widgets. And right now, for technical reasons, they are both called custom. One is the media stream. The other one is the questions. But the link to the question has been shared also in the chatroom. And we have one question. So from David, how much code for things like input can be done in cooperation with other compositors? How do technical problems create fragmentation? I don't quite follow the question. So we share some code with other way-long compositors. So we have a library called lip-input. So it takes care of the most of the nastiest input-rated stuff. We need to implement some way-long specific stuff. But I don't think that we can share that much code there. No other question for now. You mentioned at least one buff during the presentation. If I remember correctly, do you want to advertise it more? Yes. I still need to find a slot for... Basically, we want to have a buff about effects. So basically what we need to change about them in order to make them work with a senior designer. Please check the buff pages. So I'll try to find a slot that works for us. Okay. There are really no other questions. So I guess you will rejoin again in a few minutes for the community goal if I remember correctly. So there will be some time for other questions. Okay. So thank you again for this. A lot of work going on. Much appreciated. So we have a few minutes. We will start again... Now I have to not confuse the time zones. So nine minutes, let's say. Oh, we have another question that just came out. So maybe we can just continue with that. So this is a repeat question from last year. What is the status of color management in Plasma Wayland? So we landed some initial support for uploading gamma ramps. But basically if you talk about things such as HDR, so no, we want to implement it, but nobody has put any effort into it. There is upstream work, and I know that Wayland western has some improvements. But yeah, so we plan to fix it. People probably have found the links for the questions because they are now coming in. So recently Zingo S added some good gestures in K-Win. Should we look into this? What did they add? So I didn't hear. Good gestures. Oh, most gestures. The question doesn't say. Just say good gestures. So I'm not sure if it's about gestures. Well, I don't know them. So maybe they're interesting. Maybe it's just something that others can duplicate the configuration on their own distro. Maybe. I'm not sure. Okay. Let's see. Nicolo is saying something, but I guess you can probably get that in the next session. There is another question, which is gaining a lot of support. You mentioned this from David, another David that I don't know. You mentioned the scene redesign and the K-Win work as the next big thing to do. What are other big things need to happen? Or is it just small bits there and there? So right now for the scene redesign, it's mostly in K-Win. So off top of my head, I can't really answer this question. So I need to think about it. I see a few subjects like input methods. Currently an area where we need to still find a consensus with the wider community. We could have better implementation on our own, but then it would need input methods for CGK languages in particular and for more context. And here we don't have a very good experience currently and it will need some standardization ideally. So that's an area, for instance. A smaller thing is output management. I'm looking into it right now and the big other things on top of my head are drag and drop issues and X-Wallon compatibility in general. Those are smaller things, but they are really spread out at different angles around those. Let's start. There is time for another question. What is the state of copy from John? What is the state of copy-paste between X-clients and Wailon clients, especially with respect to the clipboard history? I don't know the state here. It should be working, but I think we have some issues there. Well, copy-pasting particularly, but regarding the history specifically, I don't have no knowledge. Fortunately, maybe Vlad, you have. So as far as I know, David was looking into this, so he probably knows better what about it. But yeah, clipboard stuff is a bit painful on Wailon session. There are some suggestions from the chat, like David saying, we know we have some issues in some conditions, more help narrowing this down would be appreciated. There is another comment saying, I think the state should work, if it doesn't file a bug. Community for the app. I think we have just two minutes. There are no other questions, I think. Let me reach. No, no other questions. So thanks again. As people were suggesting, the answer is always come to the booth and discuss that. So there will be more time for that. We are going to take two minutes of break, probably before the next talk. Thanks again.