{"id":67,"date":"2016-11-14T12:42:32","date_gmt":"2016-11-14T16:42:32","guid":{"rendered":"http:\/\/blogs.igalia.com\/tonikitoo\/?p=67"},"modified":"2016-11-14T16:04:59","modified_gmt":"2016-11-14T20:04:59","slug":"chromium-ozone-wayland-and-beyond","status":"publish","type":"post","link":"https:\/\/blogs.igalia.com\/tonikitoo\/2016\/11\/14\/chromium-ozone-wayland-and-beyond\/","title":{"rendered":"Chromium, ozone, wayland and beyond"},"content":{"rendered":"

Over the past 2 months my fellow Igalian Fr\u00e9d\u00e9ric Wang and I have been working on improving the Wayland support in Chromium. I will be detailing on this post some of the progresses we’ve made and what our next steps are.<\/p>\n

Background<\/h4>\n

The more Wayland<\/a>\u00a0evolved as a mature alternative to the traditional X11-based environments, the more the Chromium community realized efforts were needed to run Chrome natively and flawlessly on such environments. On that context, the Ozone project<\/a> began back in 2013 with the main goal of making\u00a0porting Chrome to different graphics systems easier.<\/p>\n

\n
Ozone consists in a set of C++ classes for abstracting different window systems on Linux.\r\nIt provides abstraction for the construction of accelerated surfaces underlying Aura UI framework,\u00a0input devices assignment and event handling.<\/pre>\n<\/blockquote>\n
Yet\u00a0in 2013, Intel presented an Ozone\/Wayland backend<\/a>\u00a0to the Chromium community. Although project\u00a0progressed really well, after some time of active development,\u00a0it\u00a0got stalled:\u00a0its most\u00a0recent update is compatible with Chromium m49, from December\/2015<\/a>.<\/p>\n
Leaping forward to 2016, a Wayland backend was added to Chromium upstream<\/a>\u00a0by Michael Forney. The\u00a0implementation is\u00a0not as feature complete as Intel’s (for example, drag n’ drop support is not implemented, and it only works with specific build\u00a0configurations\u00a0of Chrome), but it\u00a0is\u00a0definitively a good starting point.<\/p>\n
In July, I experimented a bit this existing Wayland backend in Chromium<\/a>.\u00a0In summary, I took the existing wayland<\/a> support upstream, and “ported” the minimal patches from Intel’s 01.org repository, being able\u00a0to get\u00a0ContentShell running with\u00a0Wayland. However, given how\u00a0the\u00a0Wayland\u00a0backend in Chromium upstream is\u00a0designed and implemented, the GPU process failed to start, and\u00a0HW rendering path was not functional.<\/p>\n
\"weston_wayland_chromium\"<\/p>\n
Communication with Google<\/h4>\n
Our main goal was to make Chrome capable of running natively on a Wayland-based environment, with hardware accelerated rendering enabled through the GPU process. After the investigation phase, the natural follow up step for us at Igalia was to contact Chrome hackers at Google, share\u00a0our plans\u00a0to Chromium\/Wayland, and gather\u00a0feedback. We reached out to @forney and @rjkroege, and once we heard back, we could understand why “porting” the missing bits from Intel’s original Ozone\/Wayland implementation could not be the best choice on the long run.<\/p>\n
Basically, the Ozone\/Wayland backend present in Chromium upstream is\u00a0designed in accordance to the original\u00a0Mus+Ash Project’s<\/a>\u00a0architecture:\u00a0the UI and GPU components would live in the same process<\/strong>. This way, the\u00a0Wayland connection and other objects, that belong to the UI component<\/em>, would be accessible to the GPU component and accelerated HW rendering could be implemented without any IPC.<\/p>\n
This differs from Intel’s original implementation, where the GPU process owns the Wayland connections and objects, and the legacy Chromium IPC system is\u00a0used to\u00a0pass Wayland data from\u00a0the GPU process to the Browser process.<\/p>\n
\n
The latest big Chromium refactor, since the Content API modularization, is the so called Mus+Ash (read \"mustash\") effort. In an over-summarized definition, it consists of factoring out specific parts of Chromium out of Chrome into \"services\", each featuring well defined interfaces for communication via Mojo IPC subsystem.<\/span><\/pre>\n<\/blockquote>\n
It was also pointed\u00a0to us that eventually the UI and GPU components will be split<\/a> into different processes. At that\u00a0point,\u00a0the same<\/a>\u00a0approach<\/a> as\u00a0the one<\/a>\u00a0done\u00a0for<\/a> the\u00a0DRM\/GBM\u00a0Ozone backend<\/a> was\u00a0advised in order to implement communication between UI and GPU\u00a0components.<\/p>\n
Igalia improvements<\/h4>\n
Given that “ash” is a ChromeOS-oriented UI component, it seems logical to say that\u00a0“mus+ash” project’s primarily focus is on the ChromeOS platform.\u00a0Well, with that in mind,\u00a0we thought we just needed to: (1) make a ChromeOS\/Ozone\/Wayland build of Chrome; (2)\u00a0run ‘chrome –mash –ozone-platform=wayland’; (c)\u00a0voil\u00e0<\/em>, all should work.<\/p>\n
WRONG!<\/strong><\/p>\n
When Fred and I\u00a0started on this project two months ago, the situation was:<\/p>\n