 All right, so I guess started them. Yeah, good afternoon, everybody. I have this presentation about WPE, which is a web engine based on WebKit and designed for embedded platforms. So during the talk, I give a short introduction about WebKit, a very short overview. And then I will more focus on applications. How you can use WPE in your application, what are the use cases for it. And I probably, if I have time, I'll give a short demo about something I wrote. All right, so I'm Philippe. I'm WebKit reviewer, just from a commuter, and I work for a company based in Spain called Igalia. We are working on a cooperative and we are currently about 90 IP Igalians across the world. So what's WPE? So it's based on WebKit, which probably, as you know, was a product started by Apple as a fork of KHTML around 2004. And the main goal for them at the time was to build Safari. And since then, other people joined the projects or the companies and the community added new posts. I will talk about that later. So I briefly introduced the WebKit to multi-process architecture. On that diagram, you can only see two processes, but nowadays there are more. There's one about network nowadays, one about storage, and this recently introduced GPU process as well. So the application is called the UI process in that architecture and it communicates with other processes using IPC. And all the done, passing, all the things internal to the web engine are done in those processes, like JavaScript and all those things. So WPE is a port aimed for embedded platforms. Traditionally, WebKit ports are built on top of a toolkit widget. A widget toolkit, sorry. But this port is a bit special in the sense that it decouples rendering to dedicated what we call rendering backends. That means that it gives more flexibility to the application developers and there's more openness about the platforms that you can support using that model. So that means that the rendering is deferred to another part of the port that is loaded at runtime, basically. And the input events are also under using that model. So those rendering backends usually require a thing called Weleon EGL which is a way for applications to share graphics resources between processes. And they have EGL extensions dedicated to that. So there are quite a few backends nowadays. I will just focus on two. The first one is the FDO backend which we'll talk about in a minute. And the other one is the RDK backend which is developed by companies such as Comcast. And they have deployed it in a wide range of set of boxes actually in the world. In the world. So the FDO backend, it depends on any GL. So that means usually if you have a GPU driver that's using Mesa, or probably something that provides EGL, you can have binary drivers. So that backend provides a high level API for applications to be able to get EGL images from the web engine and so that they can do whatever they want with that. And then that's also what we recommend for the WP community. It's the backend used on the build boards and it's the backend we use the most in the community. Then obviously you need a browser or some kind of application. So at EGL, we are working on a minimalistic browser called Cog. It depends on the WP backend FDO. And it's really minimalistic. There's actually no window decresion or nothing. And single-web view, although we are working on multi-web view support. And it also can be controlled using the bus. So in your application, you can like remote control the browser using other applications basically. So as a basic, you need to have a Wayland compositor to be able to run Cog. But since recently, we wrote a new backend that leverages the DRM architecture and thus we don't really require running Wayland compositor. So that's quite cool because it reduces the dependencies that you need for your application. And if you need a full-screen application, you can use that backend. Like kiosks, set-top boxes, UI, any full-screen display. And then the rendering is done with DRM. So the Wayland buffers are imported as GB and buffer objects. And then rendered using the DRM. I have a small use case for, small showcase for that. It's basically a thing I did in my free time. I was a bit tired of using Kodi at home. So I wanted to have a minimalistic media center self-contained. So I built a web extension for WP. That can be loaded at runtime by the web process. And in that web extension, I use a UPNP library, I called LibG UPNP. Zishan is here. Okay. So I use that library to discover the media servers on the network. And then for each server, I modify the DOM and add these elements to the HTML page rendered. So then I make a little build a web page based on what's on the network, basically. And then I can do the video playback with the normal video element that's stand out nowadays in WebKit. So there's a demo, it's really 30 seconds. If you want to look at it on your phone, you can scan that code, otherwise I can just move on. But yeah, it's an interesting showcase of what you can do with code and it gives an overview of really what you can do. Another thing I wanted to discuss about is acute applications. As you probably know, Qt is used while you're using the industry nowadays. And if you have a web engine in your applications such as Qt WebKit or Qt Web Engine nowadays, you probably would like to have an alternative because Qt WebKit is not maintained anymore. It has a lot of security issues. And some people don't like Qt Web Engine because it's too big, yeah. So this is an alternative to those two options you have. So what we did in upstream WebKit, we've built a QML module that can be swapped in instead of the Qt WebKit based QML module. So if you have an application using Qt WebKit, you can directly use that module. And it will use internally WP instead of Qt WebKit. So what you gain is maintain Web Engine with security releases. And so in that sense, it's quite a good advantage. There are some drawbacks though. It works only on Linux. So if your application needs to run on Windows, you're a bit screwed. And then there's dependency on well and EGL, but that we can't really work around. And it works currently in the EGL FS, QPA, and well and EGL as well. So that means you can work on desktop and on embedded platforms. So to enable it, you just need to download Qt WebKit, WP WebKit, sorry. And turn on that CMake option called enable WP Qt API. And then around time, you just need to make sure that the SO file is in your import path. And then I have a small code snippet, QML snippet there, that shows how to basically use that WP view in your application. So the changes compared to Qt WebKit is that you just need to change the import line and the module name is WP view. But in the Qt WebKit world, I think it's a different name. Otherwise, the API is similar. So on title change here, that is already available in Qt WebKit can be used as it is. All right, so. And then the last thing I wanted to talk about is how to use WP in multimedia application using this streamer. That's a bit of an over way. Think about streaming browsers or HTML overlays in live TV, for instance. So that could be a use case for WP. Just a brief overview of our budget streamer. Woo-woo hasn't heard about this streamer. Nobody, yes? Okay, so basically it's a multimedia framework based on graphs. So in your application, you build a graph and the data flow will flow from the source to sync and there will be data processing like decoding and rendering. There's many plugins. I won't go into details. But what I did is write a new plugin that uses WP and I built a source element for that so that the video, the web view can be outputted as a video basically, as a video stream. And it's quite cool because we have zero copy from WebKit world into just from our world using the ChargedGL context. So there's no memory copies in there. And the use cases, as I said, HTML overlays and the streaming browsers. I've started, so that's a demo I wrote. On the right side, you can see some HTML and on the left side, the preview of it with a live video behind. And then you can stream that. I can show you, show it later. And when you update the HTML, it's updated in the video, of course. So that's for the TV broadcasting world. It could be useful, for instance. Some ongoing work I've been doing lately on that plugin, adding audio support. I've put a type already. I need to upstream it. And then the navigation events in Gistrima are not really, have been designed many years ago and it's to be modernized a bit so I started working on that as well. Mainly adding mouse score support to achievements and improving keyboard support as well. So the code is in WPWP.org. We have a Yokto layer. The support is upstream in butthole as well. This has been working quite well on AMX6, AMX8M platforms, Raspberry Pi, 3 and 4. And it's deployed in the wild already. So you can use it now. I guess I have time for a demo, maybe? Okay, if it works. Okay, it doesn't work, but... But yeah. But you can install it with... There's a flat pack available and you can install it quite easily on your desktop. I can provide the flat pack ref later on if needed. But I don't have it installed yet, sorry. No, it's not working. Anyway, so yeah, that's it. If you have any questions, I will be happy to answer. Yes, a question? So how's platform support? I've seen some support for AMX6, AMX8, right? Anything new and notable in that? Sorry, can you... Anything new and notable from platforms supported by WPWP? Yeah, so I can say that. I've been working on, most especially on AMX8M lately, on adding WPWP, making sure that WPWP works with the AdNative driver, graphics driver, instead of the Viviente. And apart from that, I'm not sure what you were asking about. Yeah? Sorry, quick question. Sorry if it's basic. Just wanted to know what the license for WPE is. Yeah, so the license is BSD and LGPL, too. Okay, thank you.