Design differences in Google vs. Intel Chromium+Wayland implementations

Changhyeok Bae changhyeok.bae at gmail.com
Thu Aug 4 05:53:30 EDT 2016


Thanks for sharing good info. :)

Thanks
Changhyeok

2016년 8월 4일 목요일, Harder, Juernjakob (ADITG/ESA)<jharder at de.adit-jv.com>님이
작성한 메시지:

> Hi all,
>
> Jacobo wrote some information on Browser which I think is of interest for
> others in genivi-projects as well.
>
> Best regards,
> Jakob
>
> > -----Original Message-----
> > From: eg-nw-request at mail.genivi.org <javascript:;> [mailto:
> eg-nw-request at mail.genivi.org <javascript:;>]
> > On Behalf Of Jacobo Aragunde Pérez
> > Sent: Mittwoch, 3. August 2016 17:06
> > To: eg-nw at mail.genivi.org <javascript:;>;
> Michael.Unisaer at continental-corporation.com <javascript:;>
> > 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] https://github.com/01org/ozone-wayland/
> > [2] https://bugs.chromium.org/p/chromium/issues/detail?id=578890
> > [3]
> > https://docs.google.com/document/d/118Cmq_dedHOr4jfyVeE4jBhV7hXzhnaV
> > CqegNMGano0/edit?pref=2&pli=1
> > [4]
> > https://blogs.igalia.com/tonikitoo/2016/05/18/chromium-content_shell-
> > running-on-wayland-desktop-weston-compositor/
> >
> >
> > Best,
> > --
> > Jacobo Aragunde
> > Software Engineer at Igalia
> _______________________________________________
> genivi-projects mailing list
> genivi-projects at lists.genivi.org <javascript:;>
> http://lists.genivi.org/cgi-bin/mailman/listinfo/genivi-projects
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20160804/5aaa0dc5/attachment.html>


More information about the genivi-projects mailing list