Review of Igalia’s Chromium team’s activities (2018/H2).

A first semiyearly report, which overviews our Chromium team’s activities and accomplishments, focusing on the activity of the second semester of year 2018.

Contributions to the Chromium mainline repository:

  • Ozone/Wayland support in Chromium browser.

Igalia has been working on Ozone/Wayland implementation for the Chromium browser sponsored by Renesas support since the end of 2016. In the beginning, the plan was to extend a so called mus service (mojo ui service, which had been intended to be used only by ChromeOS) to support external window mode, when each top level window including menus and popups were backed up by many native accelerated widgets. The result of that work can be found from our previous blog posts: Chromium, ozone, wayland and beyond, Chromium Mus/Ozone update (H1/2017): wayland, x11 and Chromium with Ozone/Wayland: BlinkOn9, dmabuf and more refactorings….

The project was firstly run in the downstream GitHub repository and its design was based on the mus service.

In the end, after lots of discussions with our colleagues from Google, we moved away from mus and made a platform integration directly into the aura layer. The patches in the downstream repository were refactored and merged into the Chromium mainline repository.

Currently, our Igalians Maksim Sisov and Antonio Gomes have ownership of the Ozone/Wayland in the Chromium mainline repository and continue to maintain it. The downstream repository still has been rebased on a weekly basis and contains only few patches being tested.

A meta bug for Ozone/Wayland support exists and it is constantly updated.

  • Maintenance of the upstream meta-browser recipe.

Igalia has also been contributing to the upstream Yocto layer called meta-browser. We constantly update the recipe, which allows Chromium with native Wayland support to be built for embedded devices. Currently, the recipe is based on the latest Chromium Linux stable channel and uses Chromium version 72.0.3626.109. To provide good user experience, we backport Ozone/Wayland patches, which are not included into the source code of the stable channel, and test them on Raspberry Pi 3 and Renesas R-car M3.

  • Web Application Manager for Automotive Grade Linux (AGL).

Automotive Grade Linux is an operating system for embedded devices targeted to automotive. It is even more than an operating system and brings together automakers, suppliers and technology companies to accelerate the development and adoption of a fully open software stack for the connected car.

At some point, the AGL community decided that they need a Web Application Manager capable of running web applications and providing the same as native applications user experience, which can attract web developers to design and create applications for automotive industry.

Igalia has been happy to provide its help and developed a Web Runtime based on recently released Web Application Manager initially targeted for WebOSOSE with some guidance and support from LGe engineers.

The recent work was demoed at CES 2019 in Las Vegas and Chromium M68 with integration to the Web Runtime showcased to run HTML5 applications with the same degree of integration and security as native apps.

By the time of writing, the Web Application Manager was integrated into the Grumpy Guppy branch. and became available for web applications developers.

  • Servicification effort in Chromium browser.

Chromium code base is moving towards a service-oriented model to produce reusable components and reduce code duplication.

Our Chromium team at Igalia has been taking part of that effort and has been helping Google engineers to achieve that goal. Our contributions are spread around the Chromium codebase and include patches to

  • network stack (including //services/network and //net) and,
  • the identity service (//services/identity and //component/signin/core/browser).

The total number of patches is about 650 since 08.04.2018 by 21.02.2019.

By the time of writing this blog post, Igalia contributed to the Chromium mainline repository by servicifying network and identity services, which are included in the canary, dev, beta and stable channels for desktop (Windows, MacOS and Linux) and ChromeOS platforms.

  • General contributions to the Chromium browser.

Igalia has also been doing general contributions to the Chromium mainline repository and the Blink engine.

To name a few, we contributed memory pressure support to //cc (Chromium compositor), resume/suspend active tasks of blink in the content layer. We also been contributing fixes and changes according to web platform specs like Implement Origin-Signed HTTP Exchanges (for WebPackage Loading or css grid support – [css-grid] Issue with abspos element which containing block is the grid container and [css-grid] The grid is by itself causing its grid container to overflow.

Also, we implemented new API operations for the webview tag to enable or disable spatial navigation inside the webview contents independently from the global settings, and to check its state. They are available in Chromium since version 71.

More changes and fixes can be found on chromium-review.

Our contributions count about 640 patches for the past year, which makes us 3rd largest contributor after chromium.org and google.com organization (71927 + 13735 patches), opera.com (777 patches) and samsung.com (652 patches).

  • Contributions to downstream forks of Chromium, such as the ones in EndlessOS, WebOS OSE, or the Brave browser:

Igalia has been also helping downstream forks of Chromium to develop their products. For example,
we have been helping Endless Mobile with the maintenance of the Chromium browser for the different versions of Endless OS for Intel and ARM. We have been taking care of doing the periodic rebases of the adaptations made to Chromium following the updates of the stable channel by Google.

Also, we take part in the development of the Brave browser. Our contributions include on/offline installer and update features integrated into the Omaha(Windows) and Sparkle(MacOS) framework. We have also made Brave browser to have multi channel releases, which include stable, beta, dev and nightly channels for Windows/MacOS/Linux. In addition to that, we worked on customized search engine provider feature, native/web UI, theme, branding, Widevine, brave scheme support and etc. What is more, we

Our contributions can also be found in the LGE’s WebOS OSE. For example, we have been participating the periodic
rebases and adaptations made to Chromium and other activities.

  • Committers and ownership of components in the Chromium browser:

We appreciate that contributions of our Chromium team are valued in the Chromium community, During the past half a year, Igalia gained ownership in three components:

  • third_party/blink/renderer/modules/navigatorcontentutils/ owned by Gyuyoung Kim (gkim@igalia.com).
  • ui/ozone/common/linux/ owned by Maksim Sisov (msisov@igalia.com).
  • ui/ozone/platform/wayland/ owned by Maksim Sisov and Antonio Gomes (tonikitoo@igalia.com).

We also target to have all our team members to be committers of the Chromium project.

During the past half a year, our two members, Jose Dapena Paz and Mario Sanchez Prada , gained the committership.

  • Events attended and talks given:

Our Chromium team has always been targeting to have as much visibility in the open-source community as possible.

For the past half a year, we attended the following conferences:

  • the Web Engines Hackfest 2018 and spoke about “The pathway to Chromium on Wayland” (by Antonio Gomes (tonikitoo@igalia.com) and Julie Jeongeun Kim (jkim@igalia.com))
  • the W3C HTML5 Conference 2018 and gave a talk about “The pathway to Chromium on Wayland” (by Julie Jeongeun Kim (jkim@igalia.com)).

Besides the events mentioned above, it is also worth mentioning the following events for the sake of completeness, as there has not been a H1/2018 report about our team’s activities:

also AGL AMM and AGL F2F meetings in Dresden and Yokohama, and other events, where we presented our projects.

  • Other contributions:

We have also been writing various blog posts about icecc and ccache usage with Chromium.

Recently, we have posted a new blog post about enabling cross-compilation for Windows from a Linux/Mac host. The support has already been in the Chromium repository but only worked for Google employees, we have added the remaining bits to make it available for everyone.

Posted in browsers, chrome, chromium, igalia, ozone, wayland, weston | Tagged , , , , , , , , , | Leave a comment

Chromium with Ozone/Wayland: BlinkOn9, dmabuf and more refactorings…

It has been quite a long while since we wrote blogs about our Chromium Ozone/Wayland effort, and there are a lot of news right now. Igalia participated in the BlinkOn9 conference and gave a talk (https://www.youtube.com/watch?v=DREywLVAVeo) about the Ozone/Wayland support, and had many discussions on how to continue with upstreaming desktop integration related patches for the Mus service.

Even though, we had been able to make Chromium running with the Wayland backend natively, and upstreamed a lot of Ozone/Wayland related patches, some disagreements had had to be resolved before proceeding with upstreaming. To be precise, the future of the Mus service was unclear and it was decided to abandon it in favor of a platform desktop integration directly to Aura without Mus. Thanks for a good Ozone design, we had been able to quickly redesign our solution and upstream more patches to make it possible to run Chromium Ozone/Wayland from the ToT. Of course, it still has been missing some functionality patches, but the effort is going on steadily and we expect to have all the patches upstreamed in the following months. A lot of work still has to be done.

Another point I would like to mention is about our UI/GPU split effort. This is the effort to make Chromium Ozone/Wayland to be run with a separate gpu process. For that, a proper communication channel between the browser process, where a wayland connection is established, must be established. We have had tried a nested compositor approach, but decided to abandon it in favor of a dmabuf based approach, which will also allow us to have gpu native memory buffers, rasterization and, perhaps, zero-copy features enabled on some platforms. The idea behind of the dmabuf approach is to reuse some of the Ozone/Drm codebase, and by utilizing drm render nodes, create shared GBM buffers, which file descriptors are then shared with the browser process, where Wayland creates a dmabuf based wl_buffer and attaches it to wayland windows. At this stage, we have already had a working PoC, and Ozone/Drm refactorings are being upstreamed now. It will also support a presentation feedback if such protocol is available on a system with a Wayland compositor.

Last but not least, we would like to clarify about the accelerated media decode in Chromium Ozone/Wayland mentioned in https://www.phoronix.com/scan.php?page=news_item&px=Chromium-Igalia-Wayland-V4L2VDA.
To make it clear, we are not currently working on the V4L2, but rather the patches have been just merged by another external contributor for simplicity of compiling our Chromium solution on ARM based boards, especially Renesas M3 R-car board.

Posted in browsers, chromium, igalia, ozone, wayland | Tagged , , , | 1 Comment

Running Chromium m60 on R-Car M3 board & AGL/Wayland.

It has been some time ago since my fellow igalian Frédéric Wang wrote a blog post about running Chromium with Wayland on Renesas R-Car M3 board. Since that time, we have made a great success with adding support of Wayland to Chromium with Ozone that aligns with Google plans. The blog post about these achievements can by found at my fellow igalian Antonio Gomes blog.

Perfomed by …
[www.igalia.com](http://)

… and sponsored by …
https://www.renesas.com/en-eu/

Since the last build, the Automotive Grade Linux distribution, which is used to power the R-Car M3 board, has had some updates – CC branch was released and the next release had had many changes like update from Weston 1.09 to 1.11 and update binutils from 2.26 to 2.27. The binutils brought up some problems with linking, which was reported to AGL (the issue can be tracked here).

Due to the above mentioned linking problems, we decided to use CC branch to run tests with the latest Chromium/Ozone with Wayland and present our work during Automotive Linux Summit in Japan, Tokyo, where my fellow igalian Antonio Gomes gave a talk and presented the demo. The demo run smoothly and flawlessly. Afterwards, we rerun the tests, which were run previously in December, and compared the results. The outcome was very good as the overall perfomance of the browser increased.

But we still wanted to try the browser with the latest AGL branch and spent some time to resolve the issue, which was relocation overflow in R_AARCH64_LD64_GOTPAGE_LO15 and in R_AARCH64_ABS32 relocations. The specs for those relocations can be found from ELF for the ARM® 64-bit Architecture (AArch64) document.

In order to overcome the problem and fit into the overflow check, which can be found from the above mentioned document, we used -Os and -fPIE flags, which, in overall, optimized the final binary for space and reduced the size of the image, but lead to some perfomance decrease. After the image was ready, we run the R-Car M3 board and successfully started to browser using the following command line command –

/usr/bin/chromium/chrome –mus –user-data-dir=/tmp/user-data-dir –no-sandbox

The recipe for our meta-browser can be found from Igalia’s meta-browser github repository. It is also possible to test Chromium/Ozone with Wayland and X11 support by cloning and building our another chromium repository, but please note that the work is still in progress and some issues may occur.

Posted in browsers, chrome, chromium, igalia, mus, ozone, wayland, weston | Tagged , , | Leave a comment