Linux: Add support for embedded Ozone/Wayland windows

[magreenblatt]

Original report by Maksim Sisov (Bitbucket: Maksim Sisov).

---

Hi Marshall,

‌

I have already contacted you about Ozone/Wayland/X11 support via e-mail as you remember, but I think it’s better to move the discussion here.

‌

As we discussed, Ozone/Wayland/X11 can only be used with views framework now, but it does not allow to embed host windows into client windows.

‌

Whereas adding support for Ozone/X11 is trivial, the Ozone/Wayland requires some design changes. That is, you proposed to start with cefclient application and here is what I think: the cefclient has two main window classes - RootWindowGtk that uses the GTK toolkit to create windows and BrowserWindowStdGtk (I don’t take osr here as it does not look like there are any changes needed to make it work with Wayland as it is going to be the client hosting the top level window without any need to embed a CEF window into that).

‌

The RootWindowGtk receives callback events from GTK (window state changes, focus changes, bounds changes and etc) and calls the BrowserWindowStdGtk to say it to make changes to a CEF native window. The BrowserWindowStdGtk may either call to the CEF native window through browser_->GetHost()->Blah() or through X11 native APIs like XChangeProperty, XConfigureWindow and etc.

The first approach (browser_->GetHost()->Blah()) results in calling the WindowX11, which then uses X11 native APIs to change own properties and the properties of its child window, which is a Chromium window (either via changing properties of the child window directly or via changing own properties first… and when ConfigureNotify or any other event comes, it does the same change via X11 native APIs for its child (chromium) window. Then, the chromium’s X11 window receives events from X11 and passes all core stuff for processing to PlatformWindowDelegate to aura/views/blink and etc…).

The second approach (through X11 native APIs) does pretty much the same except the fact that it's the client who uses X11 APIs to change properties of the CEF native window, which then receives X11 messages from the X server and does the same changes for it’s child via the same X11 APis.

‌

I haven’t really checked mac or win and might be mistaken, but it seems like they do the same.

‌

However, it is not the case for Wayland… And embedding will look different for that. I analyzed different approaches and it seems like wl_subsurface is the way to go.

‌

In case of Wayland, clients should take a wl_surface that they created (either via gdk, native Wayland or qt toolkit or whatever) and a wl_display they used and pass them to CEF. Depending on whether a parent wl_surface is passed or not, the CEF either will create a toplevel window or a subsurface that it will parent with the passed parent wl_surface. Then, it will also pass own wl_surface that it created along with a wl_subsurface, which Chromium will use to associate own wl_subsurface with.

The mechanism, which X11 uses for property changes (XChangeProperty or XConfigureWindow) to manipulate the state of any X11 windows, won’t work with Wayland. Instead, a client will always manipulate the CEF browser window via browser_->GetHost()->DoSmth(Args…). However, one must realizethat the calls that manipulate the state of the window (such as SetBounds(), Hide(), Show() and etc) may not result in actual Wayland calls as a subsurface should be treated as an overlay above a parent surface that cannot be really hidden, shown or placed to some arbitrary area in respect to parent’s local coordinates. Instead, the state changes must be propagated through calls to views::Widget or whatever mechanism content api provides.

What do you think about that?

‌

‌

‌

[magreenblatt]

Original comment by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).

---

Any plans for improved integration with Wayland? :)

[magreenblatt]

Original comment by Maksim Sisov (Bitbucket: Maksim Sisov).

---

Hi. It’s almost complete. It’s now possible to embed cef Wayland into gtk client, but there are still some problems.

[magreenblatt]

Original comment by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).

---

Can you send a Pull request and name it “WIP” (work in progress), so others can see it and possibly help with the issues?

[magreenblatt]

Original comment by Maksim Sisov (Bitbucket: Maksim Sisov).

---

Sure. Will do that tomorrow when back to work

[magreenblatt]

Original comment by Maksim Sisov (Bitbucket: Maksim Sisov).

---

Hey. My excuses I couldn’t complete that today. I noticed cef was updated and started to rebase them, but didn’t have time to complete that today.

[magreenblatt]

Original comment by Czarek Tomczak (Bitbucket: Czarek, GitHub: Czarek).

---

No problem. Just send when you can.

[magreenblatt]

Original comment by Maksim Sisov (Bitbucket: Maksim Sisov).

---

here it is https://bitbucket.org/chromiumembedded/cef/pull-requests/288/wip-add-better-ozone-wayland-x11-support/

[magreenblatt]

Original comment by santosh mahto (Bitbucket: Santosh_Collabora).

---

Great job, I have been also looking in this feature and had done some exploration and agreed on same approach implemented by you. Thanks for doing this.

[magreenblatt]

Original comment by Laurenz Bihlmayer (Bitbucket: Laurenz Bihlmayer).

---

Hi @{5d89fce57324700c9f5fe590}

Whats the status of this issue? To me it seems pretty stale, which is a shame, because distros start using Wayland as their default window manager (protocol), most notably Ubuntu 21.04.

I would love to see continued development and hope that your pull request can get merged soon.

[magreenblatt]

Original comment by Maksim Sisov (Bitbucket: Maksim Sisov).

---

You can already use CEF with Wayland. The only case that is missing is the embedding one and I need to revisit the implementation at some point.

[magreenblatt]

Original comment by Laurenz Bihlmayer (Bitbucket: Laurenz Bihlmayer).

---

Okay I understand, but i guess the embedding one is the one that Steam, Spotify etc. are using for their apps.

It would be very nice if this implementation could be merged at some point, so we can finally get rid of the drawbacks that XWayland has.

[magreenblatt]

Original comment by Störm Poorun (Bitbucket: Störm Poorun).

---

Indeed, Ubuntu, Debian, Fedora, Manjaro, Red Hat, OpenSuse… all ship Wayland as default

So it appears many users (myself included) are now are getting blurry windows when using CEF-embedded apps, particulary on HiDPI applications (OnlyOffice, Spotify, Steam)

One appreciates there are many priorities and limited resources, but hopes this will be considered carefully by those able.

[magreenblatt]

The X11 implementation is now based on Ozone, see https://crrev.com/cecaf7e62f (M95+).

[magreenblatt]

Original comment by tytan652 (Bitbucket: tytan652, GitHub: tytan652).

---

Any update about the Wayland implementation for the CEF and the “WIP” Pull request ?

[magreenblatt]

Ozone builds can currently run with different platform backends (Wayland, X11, etc). Usage of the Views framework is required, and the cefclient sample application is not supported. See issue #2296.

What’s currently missing (and covered by this issue) is the ability to embed CEF windows in third-party Wayland applications. That requires providing a Wayland alternative to the X11 code that is currently #ifdef-d out of the CEF Ozone build.

[magreenblatt]

• changed title from "Ozone/Wayland/X11 support." to "Linux: Add support for embedded Ozone/Wayland windows"

[iMonZ]

Any news here?

[polluxau]

i would also like this to be merged, wayland is the future, steam, discord are one of the last apps that i use that havent updated to wayland yet.

[famiu]

This issue also blocks OBS Studio's custom browser docks from working on Wayland. An update on this would be really appreciated

[magreenblatt]

An update on this would be really appreciated

I'm not aware of anyone working on this currently. Perhaps someone else would like to pick up where Maksim left off?

[konradmoesch]

Whats still left to do, what can I do to help bring wayland support for CEF? The linked PR on bitbucket seems to be done:

What works:

• Everything seem to work. However, more testing is required.

What is broken:

• I’m not aware about any problems yet.

[madmalkav]

What works:

• Everything seem to work. However, more testing is required.

You got any additional info? I can´t help with code, but I can help with the "more testing" part :)

[famiu]

Whats still left to do, what can I do to help bring wayland support for CEF? The linked PR on bitbucket seems to be done:

What works:

• Everything seem to work. However, more testing is required.

What is broken:

• I’m not aware about any problems yet.

@magreenblatt any updates on this yet? With Plasma 6 seemingly planning to drop Xorg, this is more necessary than ever.

[ruineka]

I am running into this issue now and with most distros moving to Wayland as the default and hardware configurations not being compatible with X11 (Ultrawide high refresh rate multi monitor setups) this is a big issue moving forward that needs to be resolved.

[magreenblatt]

Contributions are welcome. Someone (maybe you?) will need to implement this functionality and commit to maintaining it going forward.

[ruineka]

Contributions are welcome. Someone (maybe you?) will need to implement this functionality and commit to maintaining it going forward.

I am not going to make any promises, but I will see if there is anything I can help with. I have a little experience with Wayland thanks to working with gamescope and wayland protocols, so maybe there is something I can figure out.

[QushyQushy]

Are there any news on this? I'm unable to use even XWayland for Docks and Screen Capture anymore.

Specs: 7945HX 4090M 32 GBs DDR5 BazziteOS OBS Flatpak