 Okay, so now I've got a talk from Martin Gussin who, if you don't know, is the maintainer of William. The only thing that doesn't make him want to destroy that computer. And he's going to talk about William. The talk announcement was welcome to Massachusetts. And given recent developments in the plasma phone, especially as you have seen, we are running full valent on the plasma phone. I thought it's not fitting and I want to say we are on the road to valent. We are in valent. So welcome to valent. What you've seen here, running on valent with Aqualar running on valent with Aqualar running on valent, that's when powering everything. We don't have proper multi-screen support yet, so it might be that some areas are cut off. So please excuse that, that's still under development. Some people were not able to deliver the case screen changes. Also we are not yet able to find the cursor. So that's why we have the cursor. So in this talk, I want to first again give a small look on the current architecture. Then I want to talk a little bit about the evolution of Quim. So the things we actually change to be able to become a valent compositor. Then I want to talk about something which we genuinely call the QuimD project. And last but not least, a short little look on what will be next. So what will come in Plasma 5.5 and Plasma 5.6 and so on. So let's start with the architecture. That was the architecture slide I presented last year. Most notably, we still have a few red arrows, red map arrow thing, which wasn't implemented at that time. And we had here a question in between. So we were not yet able to handle valent clients. We were not yet able to handle input. And we still needed another valent compositor to do our valent work, our low level work. So we'll change in between. Our architecture doesn't have red arrows anymore. And for those people who remember, that was the final architecture stage which we will reach in my presentation at the desktop summit 2011. So we have reached the final architecture stage. We are a valent compositor. We get input events directly from the kernel. We render directly to the kernel using direct random management and kernel mode settings. We have a rootless X server to support legacy X applications. Our Plasma shell is running at the valent client directly connected to the valent server. So yes, everything from an architecture point of view is done. Now the slide which I didn't change is not completely correct because that is not the only way we support winning narratives because nowadays we also have backend plugins to support different platforms. So to say it's a little bit of an internal platform abstraction. So a little bit like QPA. And we use it for very similar things like QPA. So this platform abstraction creates OGL context for us. It powers the QPainter backend because we need platform specific code for that. We get output information like how many screens are connected. Like in this case we have two screens. So our backend needs to provide hanging here are two screens. And some backends need to provide input handling. Not all do the input handling themselves. For everything else we have the input which is currently used in this presentation. So the following backends are currently available. Oh we have five backends. Two of them are nested. That is X11 and Valent. The X11 one of the one I use for development narratives. The Valent one is basically the state of last year with the best in between. So that hasn't changed a lot. Both of them support OGL and QPainter compositing. And both of them obviously have input support. On the full platform side we provide three backends. We have the primary one. That is the direct rendering management interface. We still have a few problems here like windows always go on top. So let's focus back on our presentation. Direct rendering management supports OpenGL and QPainter. We don't get input events. We use libinput for it. Then we have frame buffer device. So just for an entity that FB0. That only QPainter. Mesa doesn't support OpenGL or frame buffer anymore. So that never would implement it. And obviously for our own phone project we also have a hardware composer. libhypers enables backend. That one is a little bit special because it only supports OpenGL. And it only does input. And it also does input. So we cannot use libinput on that platform. Which is a little bit unfortunate thing. But that's the way it is. So the platforms are relatively small in curve. So for example the hardware composer. Backend suggests around 800 lines of curve. And 200 of them are input event curves. The hardware composer is a little bit special. Because the Kagris is a Apache 2 license. Which is incompatible with GPL version 2. So if you use the hardware composer backend. It will returns GPL version 3 for later. So that is now a small overview of our architecture. We are adding some benefits. We support rootless, excellent. We get input events directly through libinput. We render to DRNKMS. Or to nested outputs like X11 or Wayland. So a little bit on the evolution of QPainter. So that was a basic simplified architecture of QPainter in 2010-2011. We had our huge workspace class. So the workspace was basically everything about window management. Everything about compositing. So all in one class, a protocol object. The header was something like 2000 lines. So changing back meant that everything in QIN got recompiled. So we have windows represented by the top level class. The top level is in the xpeak window. Which is apparent directly to the root window. From that we subclass the client. Which are the actual windows which we manage. And unmanaged. Which is what you know as perhaps overwrite redirect windows. Or in QtSpeak, bypass window manager hint. And as a last one, the deleted. When we close the window copy of the actual content of the window. For the failed animation. So this architecture did not serve us well for going to Wayland. Because we had this huge, huge, huge X11 dependent class. So what we did, we started splitting up. So this is now extremely simplified. And actually I want to zoom in a little bit. So what we have nowadays on the window in front. Not so much change. We still have our top level. We still have our deleted in our image. But we have a new class abstract client. Which is basically an abstract interface. For representing anything QIN manages. And we have introduced a new class shell client. Which is for Wayland clients. So that was a huge stage. And once we had that in a QIN. Committed a few months ago. We were able to manage Wayland clients. The workspace got split up in many, many different classes. So we have composite as split out. But then we also have things like a screen class split it out. Which has either X render specific implementation. Or on Wayland backend specific implementation. So by that we were able to get in the information which we need. From various Wayland backend. Also we have screen edges reflected. And we now have something like an edge. And it can be either on X11 a window edge. Or area based edge. Which means we get here the screen edge support. So the next thing about the evolution I want to talk about. Is actually starting our Wayland server. So we traditionally as an X11 application. Which means we use X11 in repair. And pretty much only to start up. And without an X server we are doomed. So what we needed was to start X Wayland somehow. Now the problem here is. In order to start X Wayland. We need a Wayland server. Which we supposed to be. Now the Wayland server can only be started once. Which is provided by the Q application. Now because we needed the XCV plugin. We needed to be on X11 for the Q application. Now what does Q application do if you don't have an X server? It just fits. Which is sensible. So overall we had a wonderful dependency loop. So here we see it a little bit again. So the solution for this problem was obviously. To move away from the XCV QPA. Because we cannot provide it. I got a planning to start a Wayland server and X Wayland. Before starting the Q application. But that caused a different problem. Because X Wayland is only able to provide. OpenGL support. If the WLTR interface is present. And that is only present once we have started the composite. And exported to ETL that as our Wayland server. So yeah it was not possible to do that. And X Wayland especially didn't pick up later on. That the interface is now available. So we needed to change. We needed to get away from XCV. And switch to QTWayland. And for that we needed to reorder the startup. And there our refactoring really became handy. Because we had no multiple areas built out of workspace. Because huge X11 dependent class. And these areas were no longer X dependent. Like we have the screen class. Which didn't use the XWayland backend. But the XWayland specific backend. So we were in a very comfortable state. To actually reorder the startup. So now we have a startup. Which first starts the Wayland server. Then creates a Q application. We still need to create first the Wayland server. Then the Q application. Because of your beta. Also checks whether I can connect to QTWayland server. Then we start up our composite up. Which allows us then to start XWayland server. We wait till XWayland is ready. And then continue with the startup of the Xcode. It's pretty fast actually. We have hardly any waiting time. The only waiting time. At the start of XWayland. And luckily that's pretty fast. But we still have similar problems. As we have this XTV. With the QTWayland plugin. And most of your biggest problem. Is that QTWayland. Performs round trips. In the main GUI thread. Now because we start the Wayland server. Before we start the Q application. We are not able to put it into the thread. Because we cannot create a Q thread. Before you create a Q application. And that means our Wayland server. Currently lives in the main GUI thread. Now QTWayland. During startup. Performs a blocking round trip. To the Wayland server. And at that time. Our complete application is just frozen. That will never wait up. So what we did. Was create a run-on event dispatcher. Installed it on the QTWayland application. And make sure. That QTWayland. Proces this event dispatcher. While waiting for the event. If it has not created an event dispatcher. So with that. We got the startup solved. But nevertheless. We still have a few work around. For QTWayland. This is an example. Like. So when. You first create an OpenGL window. For example for Qt Quick. Qt tries to create an OpenGL context. To check whether. Threaded rendering is possible. And stuff like that. And it does it on the thread it's in. So if you create Qt Quick. From your main GUI thread. It will. Create. OpenGL context in your main GUI thread. Now that's not appropriate. But Lisa performs a blocking round trip. To the Bayland server. And once again. We are. That. Frozen. So what we have here. Is trying to trigger the creation. Of. Simple. OpenGL window. In an offscreen thread. Before. When. Internally. Somewhere. Triggers a kill plot. Which would create. OpenGL. Contents inside Qt. Another problem. That turned out really tricky. For. By. So. By. Means. On. To. Set. So. That. The window. Doesn't. The. That's something. We need to do. For. Now. The. Is obviously. Resulting. In. To say. That. Doesn't make sense to us. We just. Don't. Show. The window. So. Was not able to show any. Of its own windows. So what we do here. Is. We have a global. Event. Listener rebate. For. Any. When you show everyone. We check. By. The flag. Set. We destroy the window. Unset the flag. Create the window again. And show it again. Not nice. But. It works. So. The question is. Wouldn't it be better. To create. Around Qt. Day. I mean. After all. We have a few problems. Like. Cannot share. The. Context. Which. Would be really handy. Because we could. Send. Our own. Window. Text. Which we have. Anyway. Into the. Context. To. We could. Read. To. And. Completely bypass. The. Windows. Stuff. A. Window. Shower. From. With. Processes. The events. Also. And. Forwards internally. We have. To. Create. We have. To. Create. So. Whatever. The Qt. Does. So. Me. To. Create. Just. To. No. Long. To. Cheese. So. And I can't. These. Don't want. To. To. Have to get off. Of. Lines. Of. To. Could. Activate. Me. person. Ellivan. Maybe. Ofike. For that I have a quote from Kai Ruber, I prefer to rename print to printly because it follows all features. So it's obviously a joke, but all jokes have some truth. The truth is that we want to fix the security issues with XLM. Examples for that are that K-Global XL is a global keylogger. We don't want global keylogger features in Raven, we want to be secure by default. We don't want that applications are able to block your keys. So secure by default means K-Global XL cannot work anymore. We know that screen locking is completely broken on X11, so it just doesn't work. I've blocked about it back in January. So we want to have secure screen locking. How does Cosme, a desktop shell on X11 actually manipulate windows like sending them on a different virtual desktop? It's like modifying properties on the window of different processes from a security perspective. That's just horrible. We allow any process to modify any aspect of a window that's just narrow. Windows can place themselves. So let's assume I have here my nice Firefox and I'm serving to KDE.org. And now I have a motionless application. So what could I do? But I could create my own window. I could place it exactly at the top of the address of Firefox. I could render to it that you are on KDE.org and send the browser to a different location for the user to look like he is on KDE.org because the browser says so. But actually it's a different window. It could steal the input. It could move the pointer. It could do whatever it wants. So from a security perspective that's just all horrible. So we need to get away from these issues. And that means that in many, many places we need to move more control into the compositor. We need to make sure that the compositor knows about what's going on. For example, KGlobalXR moved into Win. That was needed because we don't have global keyloggers. So Win processes the global shortcuts directly and by that enables global shortcuts to work without anybody else reading to input events. Similarly we need to move screen locking into Win. Currently my screen locks. But what I can do is just press other four to quit the screen lock and the screen is unlocked. So yeah, we need to move screen locking into Win. And that would give us a better control because then Win knows that it's the screen locker window. And we can secure it. We can make sure that no other window gets input before the screen lock is shown. We can make sure that no other window gets red light or if the screen lock is shown. So yes, we need to move the screen lock. We need to know which window belongs to the virtual desktop. That was to the virtual keyboard. That was something we discovered during the film project which will become handy for Touch on Aboard notebooks as well. Because the virtual keyboard we actually want to go on top of the screen locker. So there we have our first exception. And we want to place the virtual keyboard also on a full screen window. But at the same time we never want the virtual keyboard to become the active window because that would break other applications. We need to know which process is the desktop shell. We need to know which process is the screenshot application. We need to know which process sign-up for our management. So there are all things which need to communicate with the window manager or the compositor in a way that Win has knowledge about it. And in general we need to authorize processes to special interfaces. So for example recently I added support for KDE Connect by implementing the fake input protocol. It's currently enabled by default. But actually we don't want that. We want to limit that and we want users to actively say yes, I want KDE Connect to access now my cursor and send input events. So overall that's rather tricky because we don't want to duplicate code. I don't want K-global example put into print. I don't want to have the screen looker code put into print. And we also don't want to depend on specific technologies. I don't want for example PowerDevo to be the only application which is able to communicate with Win regarding screen brightness because I want Win to be a technology not just for Plasma but for example also for ASQ or for other smaller desktop environments which don't have the manpower to write their own beta compositor. We need to stay flexible in that regard. We need to have standardized protocols that are allowed to do that. At the same time we don't want to have user experience. So when for example the desktop shell pressures and Win had started the desktop shell to know which one is the privilege process to accept those interface we don't want the user to connect with A. The process Plasma shell now wants to access the window management interface. Do you agree? So we need to find very smart solution for that. And in that regard we also have to think about KDAT because if KD Connect or K-global would access the special interfaces that would be KDAT 5 wants to access this interface. So it's something which needs a little bit smarter solutions. We have the problem already on X11 I think you have all seen that KDAT asked to open the K-Ballet and that's kind of for the user a little bit pointless to show such process. So we need smart solutions for that and suggestions for that are obviously appreciated. So let's have a look on what's next on the stage. So first of all we need to add support for XCG shell. So currently we only support WL shell and that's a rather limited interface and we made it kind of work because there's a cute extension a cute extended surface which allows us for example to close windows but overall it's not a good solution for us yet so we want to support best in demo clients and GDK clients in the future as well. The XCG shell is still under heavy development which makes it rather tricky for me to integrate it because I need to provide purpose for them in the K-Ballet repository and we provide binary stability for that so that's a little bit tricky for me from the development point of view and also because it's an unstable protocol pretty much GDK, QT, Wayland all have different versions and are not interoperable anyway so I can only work against one so my idea here is to work now on master to follow Wayland development in some way and obviously we need to make sure that we get our needs to the XCG shell protocol and that means we need to start implementing it. A different problem to solve are window declarations so maybe you have seen my screenshots of the wonderful new QT clients at declarations they are ugly and they have no distinct state shown for an active window the minimized button doesn't work because the WL shell doesn't provide minimized we cannot configure the button orders we cannot add our own button order our own buttons so narrow on all desktops for example and overall it's just not a client-side declaration so if you compare a normal GDK application with their client-side declaration yes it looks good but Qt doesn't and Qt doesn't have any API for doing proper client-side declarations so overall I think this declaration architecture is not a solution for us in Plasma I see two possible solutions one is to implement a better plugin using KDK operation when I rewrote KDK operation lately I have that in mind so it's designed that could work also in Qt Wayland but overall I'm more tending to disable the Qt current runtime there's an environment variable for that we use that for example on the phone and we export the firmware's window hint in the extender surface so that when you can narrow which window should have a declaration or not and then just use a good old X11 decode for all Qt windows and GDK applications would have their client-side declarations so hopefully that makes everybody happy and of course there are lots and lots of features which just are missing and which need to be implemented most importantly currently we cannot move windows at all that's a little bit of a problem especially for dog fooding we need to export window types so that we can have better semantics about them so that the notifications do not pop up over our running application we need to improve the Intectionless Plasma there's a broth for that on Tuesday we have many many bugs between fixing we need the window rules framework we need to import the window rules framework that's a little bit tricky because it operates on window IDs which we normally don't have we have a query to do kei.org with many many tasks like that and most of them are really really easy so if I pick a task from there I'm mostly done in less than half an hour so they are small tasks and the code base is new it's easy to get into you can ask people who actually work on that who normally don't contribute to within a way and they were able to fix their stuff so please help we need many people working on that another big topic is kei.miniour.system kei.miniour.system is an awkward framework so it's completely mobile about X11 it used to be even called preliminary.miniour.system so our equipment system or something like that so it was really modeled around X11 and somewhere in the pre-40 area someone had the idea of making the cross-platform and adding support for OSX and Minios but that just never really worked because it's too X11 specific and now obviously also Wayland is too different for kei.miniour.system to work on that so the idea we're currently trying around is to create a new API which just expels us a QF strict item model over all Windows and that could then be used by the task manager we already have a QF survival model in kei.miniour.system which then exports all the Wayland clients to PLUSNOM and of course we need to publish, publish, publish if you want to test you can just run nested quill or quill on the area with quill underscore Wayland dash dash x Wayland and if you want to start a complete PLUSNOM session it's the start PLUSNOM compositor from your TTY so PLUSNOM 5.4 will be a technology preview for PLUSNOM Wayland so we are now in the stage where we can accept our reports and Tuesday is our Wayland day so in the morning we have a session on a parallel case screen then we have a big session on PLUSNOM and in the afternoon I'm providing some help for application developers on porting their application to Wayland now maybe you think hey I'm only using Qt and I have no X11 specific code in it yes you do I've seen lots of application code our application code is all going back to KB2 so yes you have X11 specific code whether you know it or not and come to that they have a small presentation showing you all the things you shouldn't do and you should not do those things on X11 either so mostly if you do that it's also wrong on X11 and with that I'm at the end of my presentation and open for questions so ideally yes but that means that GNOME developers support it I'm not absolutely confident that we will get that into you because it's against GTK's design or GNOME's design on Windows? No because we spent lots of time to remove the useless CMake switches for compiling on Windows and making all X11 optional so be thankful that we don't do that anymore I think it's a better choice to not do that