WPE_PLATFORM for RDK devices

[asurdej-comcast]

I'm evaluating the possibility of integrating new WPE_PLATFORM APIs for our devices and I would greatly appreciate your support and guidance regarding this effort.
The goal here is to replace libwpe that we currently use with new WPE platform implementation based on Essos/Westeros

My understanding is that WPE_PLATFORM is a replacement libwpe.

What we are using right now is WPE_RENDERER with libwpe, backed by Essos WPEBackend-rdk implementation. That enforces AcceleratedSurfaceLibWPE, PlatformDisplayLibWPE and others libwpe impls. Rendering happens directly in WebProcess to platform surface and the web process controls native window. UI process receives notifications only, key events, etc but doesn't play any significant role in rendering.

With new approach WPE_PLATFORM I see that expectations are slightly different. WPEWebProcess doesn't create native window any more but it renders to suffaceless buffers that are then passed to UI process for display. That requires support for sufraceless EGL rendering (EGL_MESA_platform_surfaceless) or direct rendering with GBM/libdrm

I don't think we support any of that so at this point we would like to stick to current rendering stack, where the WebProcess does all the job.
The question is if that's even possible?
From my initial analysis that would require custom PlatformDisplay impl that will do similar to what PlatformDisplayLibWPE is doing but with WPE_PLATFORM Apis, new AcceleratedSurface and inputs, etc, but that sounds like against wpe platform ideas...

Could you please share your thoughts on that as well as the overall ideas behind WPE_PLATFORM.

[magomez]

I'm evaluating the possibility of integrating new WPE_PLATFORM APIs for our devices and I would greatly appreciate your support and guidance regarding this effort. The goal here is to replace libwpe that we currently use with new WPE platform implementation based on Essos/Westeros

That's great!

My understanding is that WPE_PLATFORM is a replacement libwpe.

It's a bit more than that. Libwpe gets removed, yes, but as you mention below, the new architecture means that the WebProcess will produce frames into some mechanism that allows sharing buffers with the UIProcess, and the UIProcess is the one in charge of interfacing with the system to put those buffers on the display.

What we are using right now is WPE_RENDERER with libwpe, backed by Essos WPEBackend-rdk implementation. That enforces AcceleratedSurfaceLibWPE, PlatformDisplayLibWPE and others libwpe impls. Rendering happens directly in WebProcess to platform surface and the web process controls native window. UI process receives notifications only, key events, etc but doesn't play any significant role in rendering.

With new approach WPE_PLATFORM I see that expectations are slightly different. WPEWebProcess doesn't create native window any more but it renders to suffaceless buffers that are then passed to UI process for display. That requires support for sufraceless EGL rendering (EGL_MESA_platform_surfaceless) or direct rendering with GBM/libdrm

It doesn't need to render to a surfaceless buffer. It can be a pbuffer as well. The key here is the mechanism used to share the buffers between processes. By default dmabuf is used. This allows a dmabuffer to be mapped into a texture inside the WebProcess, render to it, and then pass the dmabuf handler to the UIProcess. Then the UIProcess can deliver the dmabuf handler directly to the compositor (when the system susports that), or pass it to drm, or do any other operation with it. So for each platform we need dmabuf or an equivalent, and we need to implement how to pass the frame to the essos compositor. We have an implementation for the latter that involves the UIProcess creating the essos resources and copying the buffer into it that works, but it's not optimal cause it requires a copy. Ideally we need some way for essos to receive the buffer directly.

I don't think we support any of that so at this point we would like to stick to current rendering stack, where the WebProcess does all the job. The question is if that's even possible? From my initial analysis that would require custom PlatformDisplay impl that will do similar to what PlatformDisplayLibWPE is doing but with WPE_PLATFORM Apis, new AcceleratedSurface and inputs, etc, but that sounds like against wpe platform ideas...

Doing this defeats completely the goal of moving to WPE_PLATFORM.
What we need to do is find the pieces that we need and implement the missing parts. We know that realtek and amlogic support dmabuf, so that fixes the problem there. Broadcom doesn't support that, but there's a supported extension that allows doing something equivalent with native pixmaps, so we have a substitute there.

Regarding the integration with essos, wayland has the option to create a wayland buffer from a dmabuf, which should be working for realtek and amlogig. I'm not sure whether that's enough or whether any other changes are required on the Essos side. For Broadcom, we would need essos to be able to accept buffers directly using this replacement that we're using for dmabuf there.