Design differences in Google vs. Intel Chromium+Wayland implementations
Harder, Juernjakob (ADITG/ESA)
jharder at de.adit-jv.com
Thu Aug 4 03:36:45 EDT 2016
Jacobo wrote some information on Browser which I think is of interest for others in genivi-projects as well.
> -----Original Message-----
> From: eg-nw-request at mail.genivi.org [mailto:eg-nw-request at mail.genivi.org]
> On Behalf Of Jacobo Aragunde Pérez
> Sent: Mittwoch, 3. August 2016 17:06
> To: eg-nw at mail.genivi.org; Michael.Unisaer at continental-corporation.com
> Cc: Antonio Gomes
> Subject: Design differences in Google vs. Intel Chromium+Wayland
> some context: there are currently two implementations of Wayland
> integration in Chromium, we discussed them on a previous NW-EG call and
> we were asked for more details. Some of our engineers at Igalia gathered
> the information to write this report on the status and differences
> between them.
> The two implementations:
> * There is Intel's implementation, Ozone-Wayland , which has been
> developed as an independent project. It has been around for some time
> and it's more complete, although currently not maintained (latest code
> snapshot is based on Chromium from December 2015).
> * There is Google's implementation, which is currently happening in
> upstream Chromium as a 20% project . It's very recent and incomplete,
> and has some fundamental design differences that difficult the full
> merge of Intel's implementation upstream.
> Regarding design differences, these are the possible approaches
> considered in order to support Wayland natively on Chromium, through Ozone:
> 1) GPU-owned wayland connection (ozone-wayland)
> In this implementation, the GPU process will create the wayland
> connection and all wayland objects. The UI process will have proxy
> objects and all requests/events are plumbed between the UI and GPU
> process using IPC messages.
> This is the the way Intel's Ozone/Wayland  works currently.
> 2) UI-owned wayland connection, ignoring GL for now
> The UI process can own the wayland connection and objects and the GPU
> process can render to shared-memory backed SkSurface objects. To present
> the SurfaceOzoneCanvas, the GPU process can pass the shared-memory fd
> over IPC to the UI process, which can create buffers using wl_shm and
> attach them to the surface.
> This basically means that the Wayland support would run without GL
> support, and rendering happen through the SW path.
> The blog entry at  works (as an experiment) based on this approach.
> 3) UI-owned wayland connection with GPU rendering to GBM surface
> Another option would be to use the GBM EGL platform in the GPU process,
> and export the buffers as dma-buf fds. Then, the GPU process could pass
> them over to the UI process using IPC messages, and the UI process could
> turn them into wl_buffers and attach them to the wl_surface. To turn the
> fd into a wl_buffer, it would have to use wl_drm, or linux-dmabuf.
> This seems to be the design Google is most interested in.
> According to the information above and our discussions with Google
> engineers, there are a couple of lines of work we could take in parallel:
> 1) Finish upstreaming code that is not a concern for Google. We can
> work on, for example, keyboard support and multiscreen support among
> 2) Work head to head with Google in redesigning and reimplementing
> the diverging areas (GPU integration and desktop integration areas).
> The work is not trivial, especially the latter area would involve close
> contact with upstream to discuss about architecture design and
> implementation approaches.
> 3) For existing solutions that rely on it, there could be a maintenance
> effort to keep Intel's Ozone-Wayland up to date while the upstream
> implementation grows.
> I hope you find this report interesting.
>  https://github.com/01org/ozone-wayland/
>  https://bugs.chromium.org/p/chromium/issues/detail?id=578890
> Jacobo Aragunde
> Software Engineer at Igalia
More information about the genivi-projects