Bug 81456 – [META][GTK] Wayland support

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

Quoting http://wayland.freedesktop.org/gtk.html on porting applications to wayland:

* Ensure that your application uses gtk+-3.0 for its pkg-config request.
* Your application must not use any API in the gdk_x11_ namespace or any raw Xlib calls.
* Check the errata below for issues that might affect your application.

I believe lack of a web browser is the main reason I'm not using wayland as my primary display right now.

Info on wraping gdk_x11* and xlib calls in build-time and run-time backend check instead of removing them:  http://developer.gnome.org/gtk3/3.3/ch24s02.html#id1502079

[Mika Boström]

I would suspect the biggest problems come from the need to disable NPAPI. It appears to be unconditionally enabled for GTK bindings. So, you'll need to make ENABLE_NETSCAPE_PLUGIN_API=[0|1] a toggleable build flag .

Then, you need to include the empty NPAPI implementation. There are Plugin*None.cpp files in WebCore/plugins/ which you can use. Just hack the build to use those when NPAPI is not enabled. Remember to check that FrameLoaderClientGtk.cpp copes with the implementation; there might be some opportunistic uses of PluginView instance without checking whether it's valid.

[Martin Robinson]

(In reply to comment #2)
> I would suspect the biggest problems come from the need to disable NPAPI. It appears to be unconditionally enabled for GTK bindings. So, you'll need to make ENABLE_NETSCAPE_PLUGIN_API=[0|1] a toggleable build flag .
> 
> Then, you need to include the empty NPAPI implementation. There are Plugin*None.cpp files in WebCore/plugins/ which you can use. Just hack the build to use those when NPAPI is not enabled. Remember to check that FrameLoaderClientGtk.cpp copes with the implementation; there might be some opportunistic uses of PluginView instance without checking whether it's valid.

I wonder if some windowless plugins could be supported by using the X11 headers and converting events to X11 events. I don't hold out much hope for this option, but it could get some plugins working.

[José Dapena Paz]

I'm working on an implementation for this, and I'll start adding the implementation for this as the work progresses.

The initial issues with this were mostly related to build disabling NSAPI for X11. A solution for this would need to be thought independently (if anyone wills to do it).

But the main issues I'm facing are related to Accelerated Compositing and WebGL. In X11 we use XComposite for this. In Wayland it's a bit different. Though Wayland is a pure compositing protocol, it does not provide a way to share render buffers among clients, and also, it does not have the concept of a Window embedded in otehr Window. I've written some details here:
http://blogs.igalia.com/dape/2012/10/01/webkitgtk-accelerated-composition-on-wayland/

For WK1-GTK+, the main change I made is allowing TextureMapperGL to render to a texture. This texture is then painted to the WebKitWebView cairo context on demand. For WK2, I'll need a different solution, as I need to share a buffer between the UI and Web Process.

Adding also dependency on #77921 (add support for EGL). My Wayland support patch is done on top of the patch for that bug.

[José Dapena Paz]

Created attachment 167328 [details]
Patch

First draft of Wayland support. This patch depends on current egl support fix for #77921

[José Dapena Paz]

Converting this to a META bug. We'll coordinate the effort for implementing the fixes needed for wayland support using this.

[José Dapena Paz]

Comment on attachment 167328 [details]
Patch

Obsoleting the patch. This was designed for static wayland support. As Gtk supports runtime detection of wayland or x11 backend, our implementation should do the same.

[Martin Robinson]

*** Bug 18638 has been marked as a duplicate of this bug. ***

[Carlos Garcia Campos]

All blocking bugs have been fixed now, so we can close this.