Design differences in Google vs. Intel Chromium+Wayland implementations

Harder, Juernjakob (ADITG/ESA) jharder at
Thu Aug 4 03:36:45 EDT 2016

Hi all,

Jacobo wrote some information on Browser which I think is of interest for others in genivi-projects as well.

Best regards,

> -----Original Message-----
> From: eg-nw-request at [mailto:eg-nw-request at]
> On Behalf Of Jacobo Aragunde Pérez
> Sent: Mittwoch, 3. August 2016 17:06
> To: eg-nw at; Michael.Unisaer at
> Cc: Antonio Gomes
> Subject: Design differences in Google vs. Intel Chromium+Wayland
> implementations
> Hi,
> 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 [1], 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 [2]. 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 [3] 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 [4] 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
> others.
> 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.
> [1]
> [2]
> [3]
> CqegNMGano0/edit?pref=2&pli=1
> [4]
> running-on-wayland-desktop-weston-compositor/
> Best,
> --
> Jacobo Aragunde
> Software Engineer at Igalia

More information about the genivi-projects mailing list