 All right, welcome back everyone after lunch to a series of three Crisp short lightning talks Our first speaker is Mario's flood Who will talk about the AGL Wayland compositor? Take it away. Hello. Hi everyone Thanks for attending this talk. So today I'm gonna talk about the AGL compositor, which is the Wayland compositor we're using in the AGL project First of all a few words about myself on parts of the graphic part of the graphics team at Colabra I work on the Western compositor and I'm the AGL compositor maintainer So I'm gonna touch three points today about well and ecosystem try to provide some kind of sort of a common ground in terms of terminology and and Provide some kind of a side-by-side comparison or with X Components and yeah notions talk about a bit about the IVI shell and Well the requirements that we have in IVI and auto in automotive and finally about the AGL Wayland compositor and how we implement those requirements and Yeah, it's particularities So Western itself, it's just a protocol. It's just a specification It works locally over a unique socket whereas the XCOR protocol well the closest you can think of naturally works over the network a server implementation of the Wayland protocol is a Wayland compositor and You can think similar to that as a X server which has a built-in compositing manager We also have the notion of a shell. So this defines how the user interacts with the UI and similar to that to X We have this well this big desktop environments like kitty like gnome Well, these are like different types of the same desktop shell in the Western project. We also have a Desktop shell using the same the same name Next also we have something called window managers, which is more familiar to people coming from X. So multiple implementation of the same interface is Well, we can think as a window manager now all Wayland protocols are made of of interfaces and if you have like an implementation for that interface and Here's an example with Wayland's shell, which is a deprecated interface in the Wayland protocol in the EEG shell We also have something called well of protocols, which is a big repository of well other Wayland protocols The aim is to standardize different kind of operations The examples big examples here are the XDDG shell, which is basically the defect of protocol for desktop clients and Linux DMA buff. Well, there are many more protocols here rather than but these are like the biggest ones I can well add it here if you are like a Wayland compositor and you like to have like this big huge use base you would like to implement as many protocol as you might find here and Finally, we have something called compositor private extensions So these private extensions are locally just to the compositor In Western for instance, we use these private extensions to implement this GPU bypass and debugging and screenshoting One thing that I would like to note here is that between X and Wayland there is like a change of paradigm So whereas in X we basically have Well applications and tools basically split into different projects in Wayland we try to aggregate them into a well Commonplace. I'm not saying this is bad or wrong. It's just it's different and requires to well accommodate with this idea right, so Fast to IVI shell so obviously in automotive industry We have different requirements that we would have in on the desktop. Basically. We don't have any user interaction window positioning spanning and dragging and well UI wise you can think as something like a tiling window manager with customizable well window placement basically Furthermore, we have something of policy You would like to well hide or show different kind of windows and different well events and conditions like when you're Putting the car in reverse. You would like to show the rear camera Now as far as I know Well IVI shell itself was well The specification themselves was an effort that by well former Geneva Alliance now called Covisa Itself IVI shell is a private extension inside the Western compositor based of multiple components Still retains the idea that we have basically different projects and processes scattered in the different places and Yeah, our clients will need to have an implementation for that IVI shell A component here import important in IVI shell is a controller Basically which acts as a window manager It's the one that manages layouts and window positioning any OEMs or company private entity that we like to well Make up for your infotainment system with would need to implement its own controller in the Western project We have one for example that you can use to well implement your own controller It's called the HMI controller and one thing that I've added here all surfaces Are basically identifiable using an integer number Now not everything is doom and gloom with IVI shell some recent efforts Made it so it can also display desktop clients So clients that can run normally on the desktop would also be able to to run on the IVI shell And I personally seen a lot of changes Coming in them landing into the the Western project to be able to well improve the IVI shell overall but the the matter still remains that we have maintenance for multiple components and dependences associated it and I believe it's still the departure from the well well and compositor paradigm and This is where the HL well and compositor well steps in and the first question that you might well pose yourself is Wouldn't be like a bigger issue to actually write a compositor rather than just provide your own controller, but Well in truthness It's far more simpler. We basically share a lot of code with Western We went through this fitness process where we have less components and in the same time less maintenance and It's customizable to an entirely different degree because you basically own the entire hashtag rather than just one component Just as Western The HL compositor is a user of the library LibWestern So you take LibWestern you slap some startup code and you have the well and compositor All the way HL and AVI functionality is provided by two extensions. Well one now One of them is implemented. It's a HMI Client side protocol all other window management functionality happens with the help of gRPC proxy In terms of clients all the took its implement that exdg shell protocol that I mentioned earlier and For application identification. We don't use a number. We use the application ID Which is a string and comes in with the exdg shell protocol This diagram shows how the compositor stacks together different Surfaces with the help of those private extensions on the left. You would see the HMI client That if capable of managing multiple window surfaces at the same time it can do so On the center you see Multiple applications stack together and how that happens and on the right You we have like a free-floating Window that we can place on different position on a different output Alternatively we have another way of letting the HMI clients Use their own surfaces or manage their own surfaces rather than just Having well multiple surfaces. They can basically designate a certain area. They would like to display all the other Clients and we have like in that private extension. We have this request which allows you to customize that That's it. Thanks