Device Tailored Compositors with the QtWayland Compositor Framework
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Cord-Landwehr, Andreas
In this talk, I will give an introduction into the QtWayland Compositorframework and show how to use it to create a Wayland compositor from scratch.The QtWayland Compositor API is rather new and just got its first stablerelease with Qt 5.8. It can be used to create Wayland compositors from scratchwithin only a few hours and completely adapt them to the UI concept of yourembedded device. My talk focus on how to use the framework within a complexmulti-application automotive scenario. Wayland is today's standard to perform window compositing on embedded Linuxdevices. In cars, one typically uses the automotive specific "IVI" protocolextension to talk to the compositor. This works well if you have a UI withonly limited window dynamics or animations, like a static display of windowsfrom different processes (e.g. display consisting of a radio control window, aclimate control window...). But if you want to add fancy window animationsand/or have a certain complex workflow for your UI in mind, the IVI protocolshows its limits. However, writing your own Wayland compositor is no option insuch a case due to the amount of work and the introduced complexity/bugs. Inthis talk, I will explain why and when the QtWayland Compositor Frameworkprovides you with a new alternative. The QtWayland Compositor API, which only recently entered the realm of stablereleased Qt API, makes it almost trivial to create your own Waylandcompositor. Even adding your own protocol extensions, for which your UXdesigners can add any fancy (QtQuick) animation you can dream of, is simple.In my talk, I will give an introduction into the QtWayland Compositorframework and show how to use it to create a Wayland compositor from scratch.I will focus on my own experience as an embedded device developer from usingthe framework in real-life automotive scenarios. However, like most people inthe embedded world, I cannot directly talk about my projects, but instead willtalk about a hypothetical "Kitchen HMI" project, which yet will cover the fullcomplexity of a multi-application device. Specifically, this Kitchen HMI willfeature the following: * The windows from different example applications (clock app, tea cooking timer app, egg cooking timer app) will be composed in a uniform UI by a QtWayland based Wayland compositor. * The compositor provides a custom protocol extension for alarming ("hey, your tea is ready!"). * The windows will have nice animations, actually you can handle them the same as QtQuick items in the canvas of a QtQuick application. Attending the talk will provide you with the required knowledge to do all ofthe above on your own and specifically show that window handling in aQtWayland compositor "feels" the same like doing simple declarative QtQuick UIdevelopment.
 You hear me? I hope so. If you can't hear me, ah, I hear the speaker, so it works. Okay, welcome to my talk. My name is Andreas and I will talk about the device tailored compositor with a cute veil and compositor framework. It's a very long title and I will explain it to you in a minute what I want to tell you. Shortly about me, you can find me on several IFC channels. I was the KDE project since about seven years. I did a PhD and some theory set up and today I'm doing completely different things at class assistants, the company that are doing these big agriculture machines. It's a really nice green, much nicer than the green of the competitors. And we are hiring by the way. But this talk is somewhere between my KDE work and my professional work. It's about really, really nice technology that you can use from various devices for displaying stuff from several processes, so from several applications. With this talk, my goal is to give a short practical introduction to this framework, tell you how to use it, how you can experiment with it, and make you eager to really use it, and it's extremely cool. I'm not from the cute veil and compositor devinopers. I know them. I work, well, I share a lot with them, but I'm not completely from them. I'm looking more from the really usage point of view on these frameworks. Okay, it's always very hard to talk about embedded stuff in the car industry and automotive industry. I thought about a really nice practical example where I won't get any problems about this funny confidential stuff. That's my kitchen. And assume I want to have an embedded device somewhere here that helps me in the kitchen. Yeah, what do I want to have on that embedded device? I want to have some applications that help me. For example, for cooking eggs, and for cooking a tea, and maybe it's a current time, and some other applications. I want to have a really nice seamless UI between these applications. So no borders. They should be really nicely aligned. I want to have some touch gestures like swiping to the left, to the right. And I'm using some nice hardware like Raspberry Pi or some other embedded hardware that has a GPU. So a little bit of 3D acceleration. That means I can use Qt Quick, which is part later in the stock. Actually, no one else can use it without 3D acceleration. I'm not sure about this framework, but it's always a plus. And well, as I said before, the important point about having several applications there is I have several processes that I somehow have to compose on the screen. So I need a compositor. So usually a rallying compositor. And yes, everything that I explained there is much material to achieve with a simple process application. But if you're looking at the modern use case in the automotive industry, or for example in the agriculture business, where we have really, really hard requirements with really heavy applications running on this machine at the same time that you have to compose. So much harder use case actually in the automotive industry. Well, I want to have several processes there. So I'm going to do a small picture about what I explained to you. That's the size of the Raspberry Pi display. I want to have the applications aligned horizontally. I want to have the swipe gesture left and right. I want to have navigation information, so where I'm currently on my screens. And I want to have some notifications that should be send it from the applications and shown in the compositor, which is actually not that trivial as it sounds in the first hearing. Okay, and the rest of the talk is how can I create such a device with a Qt rallying compositor framework. And actually I want to show a compositor that fits on one slide for achieving this. So a little bit about Valent, I assume that all of you have heard that name at least once. It's a protocol that explains how you communicate between a client and a display server. So between an application with a window or several windows and the application server, the display server, which is a Valent compositor, which is responsible for putting the windows somewhere on your screen and also for import handling and so on. So it's really about this communication. And then that it was since several years, it's the default standard. Nobody is using X anymore. At least I don't know about anyone. There are a lot of Valent compositors since it's simply protocols. So you can implement your own compositor. You can find the western that's the reference compositor. You can find in the desktop environment a lot of different compositors. For example, we have our own one, Quinn and KDE. Gilon has its own, Enlightment has its own. I actually also encountered proprietary compositors somewhere in the field. And Valent gives you a basic protocol. Sometimes you need a little bit more. You need one to have your own custom protocol extension. For example, in KDE, we had the extension for snapshots that you can ask for a snapshot of all the windows together. How they are currently displayed on the screen. That's a simple protocol extension. How a client communicates with the server and says, I want to have the picture. Can you start somewhere? Those protocol extensions are well, great defined and well-defined standard. Then you have some tooling that creates boilerplate code and connects it to your programs. And then you can simply use it. There are different available shells, which is, well, it's kind of which language do you speak to your compositor. The default one is this WL shell that was introduced in Valent 1.0. And we have the XDD shell, which is the actual successor. And we have in the automotive field, especially this IV shell extension, which gives you a small, tiny interface how you can communicate with your compositor. And with the goal that it's interchangeable. You can take any compositor that speaks IV shell and you exchange it. However, that is really limited in what you can do there. And in my use cases, it never worked until now. So I looked at this framework, at this cute Valent compositor framework. Resistant framework. I don't know how many of you are used to cute quick before. I see a few hands. It's a declarative language that, well, it's a declarative language. Looks like little bit like Jason. Where you say what you want to have. Like I want to have a rectangle, then you have a rectangle. And you can do the same or you can now do the same with the cute Valent compositor framework. You can say I want to have a compositor. I want to have an output. I want to put my window somewhere in the output and everything works nicely together. So it's really the power of declarative language for creating such things. And this cute Valent compositor framework since, I think, two weeks ago, we have this cute 5.8 release, now we have this. For these protocol extensions, I talked shortly about last slide. You can also get a little bit more tooling that you get cute style C++ API, not only the C-style APIs with this framework that's automatically generated there. You can, of course, what you want to have are several screens. If you have a device and several monitors, that's nice to have. It has, it implements all these different shells I talked about. And the core is actually stable and, well, it's there since several years. I think at least since the cute 5.0, only the API is new. So it's a really stable piece of software or framework that you have here. And what they did here is really this really nice cute quick style API to use it in a really nice way. I shortly talked about this Ivy shell extension. My problem recently or until now was that it only fits, at least from my point of view, for really static settings. Like I have a screen and I have some windows that I want to put statically somewhere on the screen. That's really nicely doing with Ivy, but with global guest shell control and other stuff I wanted to have, it didn't work. And for such requirements, I would actually have to share a work directly on my balance server and I didn't want to hack on Vestn, so it's really not my experience, what I can use there. So looking a little bit more deeper, what we can do with the Venn Compositor, how possible system architecture would look like. We have several applications. We have a Compositor and possibly you also have intermediate application, which I simply called a shell. So you have the apps. The apps are talking to the Venn Compositor by the default Venn protocol. Within Qt, it's abstracted by the Qt platform extraction layer. You call it, if you simply use minus platform valent and it works magically. You can also use your custom protocol extension, for example, for notifications, which I will introduce in a few slides, how you can add a small extension for notifications. Or you could also have an appoxy in between. So you have architecture on the right side where you have a shell that gets all the information or all these IPC information by some mechanism and then that is the only real Venn client that's talking your protocols and talking to the Compositor. If you want to have a little bit more stability and encapsulation of the really critical stuff, you never want to have your Venn server being crashy and you can put a little bit more critical stuff in the shell. I will look at this more simple architecture here, but the other one is also really simple to achieve. And well, that's my inflight of this talk. That's my Compositor for what I told you. I will talk a little bit about it on this slide and then I will go a little bit deeper in the next slide. So like I said, it's declarative. I did some imports for the basic stuff I need there. Then I said, well, I want to have a Venn Compositor and then I want to have an output. Like, well, you want to have something on your screen. Here below I have the WL shell. From that I get the notifications, hey, there's a new surface, so a new window from application. And if I get such a window, I put it into a list model. Since that's nicely to use here, since I want to have the windows aligned next to each other, and I simply use the default Qt QuickStuff for aligning items, vectoring the items somewhere on the screen. And I put it in a wrapper called a shell surface item and then Qt did everything for me, what I wanted to have here. But look a little bit more deeper into it. So we always have, typically we have as a root, this Venn Compositor. It's the actual representation of the Compositor in the background. Everything is created for your Venn Compositor. And usually you should have an output. Otherwise you don't see anything. You should have a shell extension to get information that you have, that there are surfaces to be presented. The shell extension actually gives you information sent by the Venn Compositor. Here we have this WL shell and we get the information that the surface created. If I add my own custom extension there, I can add several extensions there. I can also get these information, that I get a signal from application like your t is ready. And we have other shells, but for the valid use case it's usually enough to simply use this WL shell, since we don't have a fully-fledged, the learnings nest appear. Then we have the surface item and the Qvalent QuickItem, which are nice wrappers around the surfaces. So the surface is simply a field where you have some image data and you want to put it on your screen. So you put it into such a wrapper that you can use it exactly like a typical Qt QuickItem. So that's the actually nicest thing about this whole technology. You handle windows like they are not windows, but simply rectangles with some stuff on it. And so a simple Qt Quick developer can simply use it with all his intuition from what he usually does. Just consider, well, the surface is a rectangle and I move it and I do some animations on it, I enlarge it, I turn it, I put a shader on it, and all the stuff you can do. And that's really nicely, since you're working on compositor like it's a simple process application with a little bit of Qt QuickItem that you get from somewhere. And that's the real power of it, that you can get on a high level really nice effects, nice implementations without being brought with all the technical stuff below. Yeah, and well, what do I have here? Yeah, it's doing the visibility, it's doing the input stuff, so I can deactivate the input stuff, I can hide it, I can show it, and well, it's really acting like a typical item. And of course I need an output that's simply in the rectangle area where I show my results of the compositor. And of course I can have multiple of them. I talked a little about protocol extensions for my use case that said, well, I want to have notifications that by clients, since they are like, your T is ready, your X are ready, time to go to bed, or whatever my applications want to show globally on the screen. And what you see here is a typical XML snippet which describes such a protocol. You can use a typical valent tooling, the valent scanner to get the binding for it. Here I'm using the Qt tooling since I get a C++ API. I can run it over it, and of course all the code and the talk slides and everything is available in GitHub with all history. And what I said, you are running your tooling over it, you get your boilerplate code, your bindings, you put it into your applications, and it works. And so you can have typical signals and slots where you can connect to, where you can send data, and everything works. And, well, actually that is what I did from my initial idea, what I have for my kitchen application. That's, well, I got a notification, your T is ready, I have two applications running here, and I will try if I get a live demo running here. Let's start my compositor. There's a compositor. And I, X application, let's see, oh, there's an application. And maybe T application. That is, and maybe another application. Then we have a little bit to see here at my application bar, and I can move it, and, well, I can just move it a little bit down. I can simply run the applications and, well, it's easy to achieve something like that. And if I would have time, I would have had time, I could have put it on my Raspberry Pi and it works. I did several similar things, but it is ready. And it's really nicely working also on a lot of the better devices. So I was faster than I thought. So we have a little bit of time for questions later on. You can already see things starting, start thinking. So again, what I wanted to show you in this talk is where this new Qt-ValentCompositor framework, allows you to simply create a ValentCompositor tailored for the specific use cases and wishes for your embedded device. You don't have to take a stock ValentCompositor. That is, maybe Kambasom makes problems with Qt event loops, which are also I've seen with proprietary compositors. You can tailor it directly to the user interaction concept your designers give to you. It's actually a huge, quick designer work. What do you do here? The compositor I created here, it's literally a one-day job to create such a compositor. Even the first time I worked on it, at that time I took two days to get it working. That's really nice thing and you can use it for fast prototyping of compositors. You can also use it for doing real compositors that you want to use later on. The power, as I already said several times, I think the power of this framework is that it gets the right abstraction to get you into a position where you create a compositor or user interface without thinking about all the complicated, Valent-related stuff far below the surface. But you can really look at the UI, the UI compositing and the overall interactions you want to have there to get a really cool and nice user interface. The best thing is really to try it out. You can see my code here. You find a lot of example codes in the Qt repositories. There's also a little bit of documentation, however the examples are sometimes more helpful currently than the documentation, I think. There are a few slides. Three pointers. A nice talk about the same framework at QtCon. There's the online help and most importantly the ISC channel. Thanks a lot for your attention. Any questions? Yes? I saw an example in my office not yet, but it really works that you have several displays and several outputs. There are also example codes for exactly that use case. The multiple screen demo. There are Qt repositories. Can the compositor distinguish different types of screens like an tablet mode or a window mode? Again. So if you have the compositor trying to composite the tablet mode, what does it composite the same way as it works with desktop mode? In desktop, for example, we have like a window mode with shows and a next slide. Just implement it into your compositor. That's your freedom. You have the compositor framework and then you look at what you want to see there and the compositor should handle it. It's your task to create all these effects in the compositor. It only gives you a framework to use it with Qt Quick and then you can implement it. No more questions and thanks a lot.
 You hear me?  I hope so.  If you can't hear me, ah, I hear the speaker, so it works.  Okay, welcome to my talk.  My name is Andreas and I will talk about the device tailored compositor with a cute veil and compositor framework.  It's a very long title and I will explain it to you in a minute what I want to tell you.  Shortly about me, you can find me on several IFC channels.  I was the KDE project since about seven years.  I did a PhD and some theory set up and today I'm doing completely different things at class assistants,  the company that are doing these big agriculture machines.  It's a really nice green, much nicer than the green of the competitors.  And we are hiring by the way.  But this talk is somewhere between my KDE work and my professional work.  It's about really, really nice technology that you can use from various devices for displaying stuff from several processes, so from several applications.  With this talk, my goal is to give a short practical introduction to this framework,  tell you how to use it, how you can experiment with it, and make you eager to really use it,  and it's extremely cool.  I'm not from the cute veil and compositor devinopers.  I know them.  I work, well, I share a lot with them, but I'm not completely from them.  I'm looking more from the really usage point of view on these frameworks.  Okay, it's always very hard to talk about embedded stuff in the car industry and automotive industry.  I thought about a really nice practical example where I won't get any problems about this funny confidential stuff.  That's my kitchen.  And assume I want to have an embedded device somewhere here that helps me in the kitchen.  Yeah, what do I want to have on that embedded device?  I want to have some applications that help me.  For example, for cooking eggs, and for cooking a tea, and maybe it's a current time, and some other applications.  I want to have a really nice seamless UI between these applications.  So no borders.  They should be really nicely aligned.  I want to have some touch gestures like swiping to the left, to the right.  And I'm using some nice hardware like Raspberry Pi or some other embedded hardware that has a GPU.  So a little bit of 3D acceleration.  That means I can use Qt Quick, which is part later in the stock.  Actually, no one else can use it without 3D acceleration.  I'm not sure about this framework, but it's always a plus.  And well, as I said before, the important point about having several applications there is I have several processes that I somehow have to compose on the screen.  So I need a compositor.  So usually a rallying compositor.  And yes, everything that I explained there is much material to achieve with a simple process application.  But if you're looking at the modern use case in the automotive industry, or for example in the agriculture business, where we have really, really hard requirements with really heavy applications running on this machine at the same time that you have to compose.  So much harder use case actually in the automotive industry.  Well, I want to have several processes there.  So I'm going to do a small picture about what I explained to you.  That's the size of the Raspberry Pi display.  I want to have the applications aligned horizontally.  I want to have the swipe gesture left and right.  I want to have navigation information, so where I'm currently on my screens.  And I want to have some notifications that should be send it from the applications and shown in the compositor, which is actually not that trivial as it sounds in the first hearing.  Okay, and the rest of the talk is how can I create such a device with a Qt rallying compositor framework.  And actually I want to show a compositor that fits on one slide for achieving this.  So a little bit about Valent, I assume that all of you have heard that name at least once.  It's a protocol that explains how you communicate between a client and a display server.  So between an application with a window or several windows and the application server, the display server, which is a Valent compositor,  which is responsible for putting the windows somewhere on your screen and also for import handling and so on.  So it's really about this communication.  And then that it was since several years, it's the default standard.  Nobody is using X anymore.  At least I don't know about anyone.  There are a lot of Valent compositors since it's simply protocols.  So you can implement your own compositor.  You can find the western that's the reference compositor.  You can find in the desktop environment a lot of different compositors.  For example, we have our own one, Quinn and KDE.  Gilon has its own, Enlightment has its own.  I actually also encountered proprietary compositors somewhere in the field.  And Valent gives you a basic protocol.  Sometimes you need a little bit more.  You need one to have your own custom protocol extension.  For example, in KDE, we had the extension for snapshots that you can ask for a snapshot of all the windows together.  How they are currently displayed on the screen.  That's a simple protocol extension.  How a client communicates with the server and says, I want to have the picture.  Can you start somewhere?  Those protocol extensions are well, great defined and well-defined standard.  Then you have some tooling that creates boilerplate code and connects it to your programs.  And then you can simply use it.  There are different available shells, which is, well, it's kind of which language do you speak to your compositor.  The default one is this WL shell that was introduced in Valent 1.0.  And we have the XDD shell, which is the actual successor.  And we have in the automotive field, especially this IV shell extension,  which gives you a small, tiny interface how you can communicate with your compositor.  And with the goal that it's interchangeable.  You can take any compositor that speaks IV shell and you exchange it.  However, that is really limited in what you can do there.  And in my use cases, it never worked until now.  So I looked at this framework, at this cute Valent compositor framework.  Resistant framework.  I don't know how many of you are used to cute quick before.  I see a few hands.  It's a declarative language that, well, it's a declarative language.  Looks like little bit like Jason.  Where you say what you want to have.  Like I want to have a rectangle, then you have a rectangle.  And you can do the same or you can now do the same with the cute Valent compositor framework.  You can say I want to have a compositor.  I want to have an output.  I want to put my window somewhere in the output and everything works nicely together.  So it's really the power of declarative language for creating such things.  And this cute Valent compositor framework since, I think, two weeks ago,  we have this cute 5.8 release, now we have this.  For these protocol extensions, I talked shortly about last slide.  You can also get a little bit more tooling that you get cute style C++ API,  not only the C-style APIs with this framework that's automatically generated there.  You can, of course, what you want to have are several screens.  If you have a device and several monitors, that's nice to have.  It has, it implements all these different shells I talked about.  And the core is actually stable and, well, it's there since several years.  I think at least since the cute 5.0, only the API is new.  So it's a really stable piece of software or framework that you have here.  And what they did here is really this really nice cute quick style API to use it in a really nice way.  I shortly talked about this Ivy shell extension.  My problem recently or until now was that it only fits, at least from my point of view,  for really static settings.  Like I have a screen and I have some windows that I want to put statically somewhere on the screen.  That's really nicely doing with Ivy, but with global guest shell control and other stuff I wanted to have,  it didn't work.  And for such requirements, I would actually have to share a work directly on my balance server  and I didn't want to hack on Vestn, so it's really not my experience, what I can use there.  So looking a little bit more deeper, what we can do with the Venn Compositor,  how possible system architecture would look like.  We have several applications.  We have a Compositor and possibly you also have intermediate application, which I simply called a shell.  So you have the apps.  The apps are talking to the Venn Compositor by the default Venn protocol.  Within Qt, it's abstracted by the Qt platform extraction layer.  You call it, if you simply use minus platform valent and it works magically.  You can also use your custom protocol extension, for example, for notifications,  which I will introduce in a few slides, how you can add a small extension for notifications.  Or you could also have an appoxy in between.  So you have architecture on the right side where you have a shell that gets all the information  or all these IPC information by some mechanism and then that is the only real Venn client  that's talking your protocols and talking to the Compositor.  If you want to have a little bit more stability and encapsulation of the really critical stuff,  you never want to have your Venn server being crashy and you can put a little bit more critical stuff in the shell.  I will look at this more simple architecture here, but the other one is also really simple to achieve.  And well, that's my inflight of this talk.  That's my Compositor for what I told you.  I will talk a little bit about it on this slide and then I will go a little bit deeper in the next slide.  So like I said, it's declarative.  I did some imports for the basic stuff I need there.  Then I said, well, I want to have a Venn Compositor and then I want to have an output.  Like, well, you want to have something on your screen.  Here below I have the WL shell.  From that I get the notifications, hey, there's a new surface, so a new window from application.  And if I get such a window, I put it into a list model.  Since that's nicely to use here, since I want to have the windows aligned next to each other,  and I simply use the default Qt QuickStuff for aligning items,  vectoring the items somewhere on the screen.  And I put it in a wrapper called a shell surface item and then Qt did everything for me,  what I wanted to have here.  But look a little bit more deeper into it.  So we always have, typically we have as a root, this Venn Compositor.  It's the actual representation of the Compositor in the background.  Everything is created for your Venn Compositor.  And usually you should have an output.  Otherwise you don't see anything.  You should have a shell extension to get information that you have,  that there are surfaces to be presented.  The shell extension actually gives you information sent by the Venn Compositor.  Here we have this WL shell and we get the information that the surface created.  If I add my own custom extension there, I can add several extensions there.  I can also get these information, that I get a signal from application like your t is ready.  And we have other shells, but for the valid use case it's usually enough to simply use this WL shell,  since we don't have a fully-fledged, the learnings nest appear.  Then we have the surface item and the Qvalent QuickItem,  which are nice wrappers around the surfaces.  So the surface is simply a field where you have some image data  and you want to put it on your screen.  So you put it into such a wrapper  that you can use it exactly like a typical Qt QuickItem.  So that's the actually nicest thing about this whole technology.  You handle windows like they are not windows, but simply rectangles with some stuff on it.  And so a simple Qt Quick developer can simply use it with all his intuition from what he usually does.  Just consider, well, the surface is a rectangle and I move it and I do some animations on it,  I enlarge it, I turn it, I put a shader on it, and all the stuff you can do.  And that's really nicely, since you're working on compositor like it's a simple process application  with a little bit of Qt QuickItem that you get from somewhere.  And that's the real power of it, that you can get on a high level really nice effects,  nice implementations without being brought with all the technical stuff below.  Yeah, and well, what do I have here?  Yeah, it's doing the visibility, it's doing the input stuff, so I can deactivate the input stuff,  I can hide it, I can show it, and well, it's really acting like a typical item.  And of course I need an output that's simply in the rectangle area where I show my results of the compositor.  And of course I can have multiple of them.  I talked a little about protocol extensions for my use case that said,  well, I want to have notifications that by clients, since they are like, your T is ready, your X are ready,  time to go to bed, or whatever my applications want to show globally on the screen.  And what you see here is a typical XML snippet which describes such a protocol.  You can use a typical valent tooling, the valent scanner to get the binding for it.  Here I'm using the Qt tooling since I get a C++ API.  I can run it over it, and of course all the code and the talk slides and everything is available in GitHub with all history.  And what I said, you are running your tooling over it, you get your boilerplate code, your bindings,  you put it into your applications, and it works.  And so you can have typical signals and slots where you can connect to, where you can send data, and everything works.  And, well, actually that is what I did from my initial idea, what I have for my kitchen application.  That's, well, I got a notification, your T is ready, I have two applications running here,  and I will try if I get a live demo running here.  Let's start my compositor. There's a compositor.  And I, X application, let's see, oh, there's an application.  And maybe T application.  That is, and maybe another application.  Then we have a little bit to see here at my application bar, and I can move it, and, well,  I can just move it a little bit down. I can simply run the applications and, well, it's easy to achieve something like that.  And if I would have time, I would have had time, I could have put it on my Raspberry Pi and it works.  I did several similar things, but it is ready.  And it's really nicely working also on a lot of the better devices.  So I was faster than I thought.  So we have a little bit of time for questions later on.  You can already see things starting, start thinking.  So again, what I wanted to show you in this talk is where this new Qt-ValentCompositor framework,  allows you to simply create a ValentCompositor tailored for the specific use cases and wishes for your embedded device.  You don't have to take a stock ValentCompositor.  That is, maybe Kambasom makes problems with Qt event loops, which are also I've seen with proprietary compositors.  You can tailor it directly to the user interaction concept your designers give to you.  It's actually a huge, quick designer work.  What do you do here?  The compositor I created here, it's literally a one-day job to create such a compositor.  Even the first time I worked on it, at that time I took two days to get it working.  That's really nice thing and you can use it for fast prototyping of compositors.  You can also use it for doing real compositors that you want to use later on.  The power, as I already said several times, I think the power of this framework is that it gets the right abstraction to get you into a position  where you create a compositor or user interface without thinking about all the complicated, Valent-related stuff far below the surface.  But you can really look at the UI, the UI compositing and the overall interactions you want to have there  to get a really cool and nice user interface.  The best thing is really to try it out.  You can see my code here. You find a lot of example codes in the Qt repositories.  There's also a little bit of documentation, however the examples are sometimes more helpful currently than the documentation, I think.  There are a few slides.  Three pointers.  A nice talk about the same framework at QtCon.  There's the online help and most importantly the ISC channel.  Thanks a lot for your attention.  Any questions?  Yes?  I saw an example in my office not yet, but it really works that you have several displays and several outputs.  There are also example codes for exactly that use case.  The multiple screen demo.  There are Qt repositories.  Can the compositor distinguish different types of screens like an tablet mode or a window mode?  Again.  So if you have the compositor trying to composite the tablet mode, what does it composite the same way as it works with desktop mode?  In desktop, for example, we have like a window mode with shows and a next slide.  Just implement it into your compositor.  That's your freedom.  You have the compositor framework and then you look at what you want to see there and the compositor should handle it.  It's your task to create all these effects in the compositor.  It only gives you a framework to use it with Qt Quick and then you can implement it.  No more questions and thanks a lot.
Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_0_131.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_132_611.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_612_2483.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_2484_3071.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_3072_5411.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_5412_6575.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_6576_10559.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_10560_14519.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_14520_18491.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_18492_20087.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_20088_22871.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_22872_24083.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_24084_24683.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_24684_25163.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_25164_25331.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_25332_25403.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_25404_25463.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_25464_25559.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_25560_25619.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_25620_25667.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_25668_25811.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_25812_25859.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_25860_25979.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_25980_26027.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_26028_26123.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_26124_26183.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_26184_26915.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_26916_26999.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_27000_33443.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_33444_33539.png Device_Tailored_Compositors_with_the_QtWayland_Compositor_Framework_33540_33564.png