 And we'll start now with QT in Automotive, and Johan is going to explain that to us. Yeah. Hi. The microphone seems to work. Strange echo right away. So I'm going to talk about QT in Automotive, or rather QT in Automotive, and how we can use it outside of Automotive would be my key takeaway. So very quickly, I'm Johan Tillin. I work at a company called Luxoft. Used to be called Pelagicor. I did a year at Nokia QT Frameworks, which used to be called Trolltech. I do mostly QT on embedded systems these days. But this is what I built work time wise. Don't never mind the star on the steering wheel and these things, but it's infotainments of car interiors. How many here are actually working within Automotive or with Automotive customers? That's like 10%, 15%, which is great, because this is what I want you to take away. What problems do we share? I'm going to describe a bit what we do, but also what solutions can we share? Because Automotive is a fairly small industry when it comes to the number of open source developers. So if we can share solutions and sort of solve the same problems together in a way that works both in Automotive and outside of Automotive, I think we can gain a lot more momentum. I'm going to talk about the QT Automotives use. And to those of you not familiar with it, QT basically comes in different packaging. So for us doing open source and just if you use the Git packages or download it into your distribution, you don't really care. But as a commercial paying customer, you either buy Qt or you can buy Qt for device creation, which brings you slightly more, and then you can buy Qt for Automotive Qt, which brings you even more on top of Qt for device creation. But what's important for us is to realize that it's all of Qt, it's all of the embedded Linux stuff for Qt and then some more. So what's in this box some more? We have a number of Qt modules, the application manager, something called Qt IDI, a Geneva module, then we have some tools around this. I'm going to touch on some of them, unfortunately not all. I'm going to run out of time, I already know that. We also have an example called NetTune, which is a reference UI, which contains both the center stack. So what used to be the radio and the instrument cluster, so the dials in front of the driver. It also has a very naively implemented app story is to show that we can actually be app oriented and download apps independently onto the systems. And then we solve a number of things that are important in our industry. We do notifications and we can prioritize and sort of mute notifications in certain scenarios. We have tools for measuring performance because we need a good frame rate and low latencies in all situations. We need to start quickly and so on. We manage applications that we start and stop, install and uninstall, and we have a chain of trust from your application package to actually the Wayland surface being showed on screen. This is how it looks. So kind of fancy, but instrument cluster and different views that you would have in the center stack. There's actually a face lift that was showed of this in CS, but I don't think that's available on a public yet yet. I guess it's still being polished code wise. And what does the customer then have to do? Wouldn't you as a car maker? I mean, we provide a reference. We show how we think it should be built, but we don't build a specific car. So you have to integrate it to your vehicles, to your electrical systems, to your can network. You have to add your own features. Everyone has something fancy. You have to add your look and feel and so on and you need to have your own infrastructure for deploying apps and upgrades. But I want to spend some time on the three components that we have, the three Qt modules. And I want to spend most time on the application manager because it's the biggest one. But first I just want to do QML 101. Who knows QML? That's a little under half. So I just want to show some concepts. QML is a bit like HTML. I usually say HTML done right, might be a bit provocative, but it's a declarative language for page layouts where you can do event management and so on. But it's not oriented around laying out text on a page and then sort of put into a device situation. So I just wanted to show you that all these things starting with a capital letter like rectangle and then followed by color braces and text and mouse area, those actually instantiate an element. That's your opening tag basically. And then the other one is your closing tag. So that creates an object on the C++ site or an object instance. And then all these assignments as it looked like, width 360, height 360, these are actually bindings. So I mean, this is an example where I don't really use that because the right side is always constant. But if you would have had a variable on the right side of the colons, it would mean that it's reevaluated every time the expression changes. So you can do quite fancy things and make the shadow follow your element and things like this. And then with the same syntax confusingly enough, you can also react to what Qt calls signals, but basically events. So if I say on clicked, that means that the clicked signal was emitted by the mouse area element. And then you put a piece of JavaScript in there and do something. In this case, we're quick. But just to orientate you roughly in how it looks. So Qt Appman provides the mechanisms to build a user interface, but it doesn't build the contents, the apps or the look and feel. So what we want you to do is to take Qt Appman and you build what we call a system UI on top of it. And that's a compositor, but it's usually also like the fixed parts of the UI. So you have a top bar, you might have some climate controls, really tightly integrated functions. And you put that in there. And that's what we call the system UI. But you have four APIs or four key APIs in the application manager. And one of them is what we call the application manager, which is what you use for launching, stopping and sort of monitoring the processes that you start your apps. You have the application installer, which takes the slightly larger life cycle for the apps. So it's installation updates and removal of the actual packages on your disk. The window manager, which is used to implement a Wayland compositor. It's built on Qt Wayland, so it sort of extends on that. And then the notification manager, which is an implementation of the server side of org feed desktop notifications, but with some cavits to meet the requirements that we have of prioritized notifications. And yeah, we let you put more than markdown in the text fields, basically. And we interpret that. So how do you then start an app? And now I hope you're all up to speed on your QML. Let's see if I can do a mouse pointer here. So list view here is a view of a model. So it basically shows you a list of things. And the delicate here is what's instantiated for every item in that model. And the model itself is this application manager, which contains a list of all your installed applications, all the available applications and systems. This is a very naive implementation because it just shows everything you've got. And in the delegate, we show a text that just says name and the reverse DNS ID for the application. And then if you click it, we tell application manager to start that application. And that's a trigger launcher that works and you can launch applications. Then we hook into some signals. So we say that we want to know when surface items appear, when they're closing and when they're lost. So when the application is started, it will start to create a wavelength surface, which means that it is ready after a while. And then we have a handler for ready. And again, this is a super trivial full screen window manager implementation. But what we do is that we pick it up in our container. We simply put the surface item inside that container and boom, it's composited onto the screen inside of the QML scene that is your system UI. So as you know in QML, I haven't told you, as some of you know in QML, you can do shader code and stuff in QML as well. And you can just apply that inside your compositor on top of the window surfaces. So it's really powerful to get it in there. And then what we add on top of this, I mean, you mix the launching and installation and starting of applications with the compositing. But the cool thing is that we tie it together. So from, let's see which direction do I do this? I did it from the window manager from a wavelength surface. You can say what application ID does this one have, which is a unique ID pointing to that application. Now you can ask the application manager who knows about the installed applications and just say what are the capabilities? So like a list of strings describing what this application is allowed to do for that ID. And then you get a list of strings and you can take action. So is this window supposed to go to the instrument cluster or the center stack? Is it allowed to be visible when you're moving the vehicle? All these things, does it have to be in a container or can it be run natively? And it's super easy to sort of pull the string through it. And we application manager guarantees the chain of trust all the way from your application bundle that you install to the actual wavelength surface being showed on screen. So you know that it's the same manifest and it's the same file being installed. It's a process that you launched and so on. Then you can do the exact opposite. You can run QML applications inside of application manager. And I say QML here, but QML can load C++ extensions. That I have to start it from the QML side of things. You can't have a C++ entry point. And that means that you can actually run apps and deploy apps independently of the system UI in systems that are not capable of running Wayland. Or it could be very early in your project. The Wayland isn't stable or you want to run it on windows for development purposes inside just a window. And you can do that. And also you do this really early. You don't spawn an additional process. So you save time as well. So during early startup, which is a really important use case for automotive, you can do this. And then you know that you're running inside your compositor. So of course you have all the security concerns associated with that, but you can do it and still decouple it as an app. So you can choose your priorities. You can run it in process in the system UI. You can run it out of process as a Wayland client. Then you can also run any other tool kit. It's just a Wayland surface. Or you can even put it inside a container. And these mechanisms from where you run it is actually a backend that's abstracted from the Qt application manager. So you can write your own. There is a pre-integrated container based on LXC, but you can put another container in there if you like to. It's your sponsor process inside a container that you have to create. And it's a traditional engineering trade-off. This is fast and dirty. This is decoupled, flexible, secure, whatnot, so I mean, the further you go there, the slower it will be, but also the better from sort of a stability and decoupling standpoint. Qt API, moving along to the next module. I'm so short on time. So it's more or less a pattern for how to create an API for your applications. I mean, the problem in Automotive is that all car vendors have different features. So you can't get them to agree on a single API. And even if you got them to agree on a central API, they would all sort of differentiate by adding their own functions. They would still have different APIs. So we decided let's just do a pattern for how we want this done. We have some reference UIs for vehicle functions. I think it's windows and climate controls. You can do fancy demos and just show how the APIs are supposed to look. We also do media index and play back control, radio tuners, these sort of functions that we don't think are that different between cars. So what we do is to show how to use the technology. For the rest, you can either write your own code if you want to do the integration, but we also provide a tool called Qface, which is a Qt-oriented IDL from which you can generate stuff that binds onto whatever the car maker has underneath. So what Qt-IVI does from a Qt perspective, which is kind of interesting, is that it separates the front and from the back end, which means as QML is declarative, you don't have to, imperatively, in JavaScript, instantiate elements and bind to them in JavaScript as they become available. Instead, you bind this climate control facade object, and that one then loads the back end and becomes available later on when the back end is there, which means that you can write QML the way that QML is intended, but the back end can appear as they come along or as with cars if you paid for it, so depending on the options package you picked with a car, some of these might not ever become valid. So this is just a very, you need to set the auto discovery to true to get it to automatically load the first back-end encounters, otherwise you need to tell it which back-end to load, and then you get this, it's valid changed, and you check that it changed to true, then you can start interacting with the back end. And I mean, what we use this for, you can have different hardware in the back end, usually during the project, you might have different maturities rather, so you have the simulation and then you get an actual production hardware, and then you load different hardware, but we don't have to change the QML or the application client code to cater for that, but we can also do simulation back ends that you can deploy onto your desktop that even has a UI of its own, so a bit like the Android emulator where you can sort of stimulate the system, but you never change the binary interface or whatever your application code is linked towards, and also testing. I mean, this is a structured way to just inject back ends where you can modify the system state and also read out the system states without asking through the official APIs so you can make sure that it behaves as expected. Then we have Q-Face, which I find cool just because of the simplicity. So it's an IDL. The IDL addresses some of the problems that we had first, that Qt has some higher level concepts that weren't available in other IDLs. Primarily Qt has something called item models, which is basically a big table that's loaded dynamically, and you can express that there, you can express signals and slots and all these Qt concepts. Yeah, and you can do interfaces and whatnot, and you can add annotations so as you can pass data outside of the language to your custom generator. But the cool thing is that the generator is based on GINJA. So you don't write C++ code or Java code or whatnot to sort of concatenate strings, which is super boring and it's hard to see what you actually type because you need to run it and see what ended up because there's so much coding between you and what you actually output. Instead, we take some Q-face IDL code, put it into a structured model. This model you can then traverse with GINJA code and simply output stuff. This is a very trivial generator, but basically it looks for every module in the system. So we step down in the tree and then for every interface in the module, we step one more step in the tree. We print out service module.interface and then we continue for the structures with a structure model and so on. So it's quite easy to understand what you're doing and all you're doing is traversing the model, but it's powerful enough to actually export C++ code that binds onto different types of backends, things like that. So you can put this on top of Qtremote objects, for instance, to get a network transparent APIs, things like that, and also put it on top of other IPCs provided to you by your customer if you're forced to bind Qt to something that has no Qt binding. And it also means that the template code here is separate from the generator. So you only change the template. You don't change Q-face itself if you want to support a new backend, which is quite convenient. It's easy for you to maintain your own backends outside of the actual generator. You don't have to fork the generator to support more. Then I just want to, oh shit, five minutes. Then I just quickly want to mention the Qt Genevieve Extras module. It's one extra module. We welcome more modules to integrate more systems. This one integrates the categorized logging towards the Genevieve DLT component. You can see it all in the source, skipping ahead. Then I want to talk very quickly about the tools. We have something called QML Live, which is a live reloader. Super convenient to just save your code. It reloads the project as you go along. Everyone uses it, but this one has server client. So the reloading can be done over a network. So you can actually have the QML Live server running on your target, on your actual physical screen, the one you want to use with the right backlog and the right touch interface and everything with your finger instead of your mouse pointer. And at the same time, as soon as you save an asset in the project, it could even be pictures. You can give this to a designer who doesn't know how to code or how to set this up or anything. As soon as they save an image, the scene is restarted on the other side and they can see it on their target. It's kind of fun because we did this together with a customer and we reduced the round trip time for the designers from six weeks to 400 milliseconds. So it really changes the way that you can iterate and work agile with your design. And this is kind of fun. We get contributions from YOLA here. I don't know if there are YOLA people here, but thank you. They are a big one. I don't know if anyone else contributed as well. I just had a quick look. But this is a tool that's completely non-automotive and it happens to sit in the automotive module, which kind of makes my point. We also have tools in application manager or support APIs to measure performance, which I think could be interesting outside as well. So we have this start timer, which allows you to simply say, I'm a checkpoint A, I'm a checkpoint B, I'm a checkpoint C as you start your program. And then you get these fancy graphs with basically reporting where you're at, where you spent your time, what's going on. So you can measure the startup time. You can do these both for the system UI and for application instances. And then we also have these process monitor and system monitor APIs, which usually goes into the system UI or debugging service where you can measure things like frame rate for an individual process or for the whole system, how much CPU are you using in total or for an individual process and so on. So it's a good debugging tool there. Then I wanted to point that code.qt.io. There you find all these repositories. Look for Qt application manager or Qt IDI and so on. You can also look at the automotive suit documentation where you get an index, what are the modules that are in the automotive suit and they're generated the documentation. If you just want to get started real quick you can see the Neptune UI running on top of a Linux system. We also have a system called PLUX from the good old Pelagic or Ace. So I was happy that we bought by Luxsoft because the name still makes kind of sense. But there you have all the Yocto layers pre-integrated. You can, for instance, build a Raspberry Pi image and just boot it and you have the full system there so you can play with the working system and not spend time on the integration. Then I just want to fall back to this. Was any of these problems a problem that we share across industries and are any of our solutions of interest to you outside of automotive? Can we share code? Can we cooperate together? Thank you.