Allow specifying which shared object to load as WPE backend

[aperezdc]

This would allow a launcher/embedder to specify which WPE backend to use. This would remove the need to have a libWPEBackend-default.so file, and allows launchers which are implemented to work with some specific WPE backend to set the one to use instead of inadvertently loading the wrong one and failing in mysterious ways.

See Igalia/cog#11 for more of the the motivation for requesting this.

[clopez]

Perhaps an idea is installing all backend libraries on a specific custom directory (like GStreamer does with plugins).. say something like /usr/lib/wpe-backend-0.1/

Then the wpebackend library can have two new API calls:

1. wpe_backend_list(directory) Lists the backends available: that will simply return the .so files available on the backend plugin directory. If directory is null it uses the default value configured at build time (something like ${libdir}/wpe-backend-${apiver}/ )
2. wpe_backend_load(backend, directory) Loads a specific backend returned previously from 1. directory can be null to use the default value at configure time. This can only be called once in the whole lifetime of the program and has to be done before the wpeview initialization.

If no backend is specified (via the api call of 2.) it simply loads the first backend available on the default directory or returns a fatal error if not backend is available.

WDYT?

[clopez]

As a bonus point this would allow backend implementations to install multiple libraries with different sub-backends. For example -rdk could install all this:

/usr/lib/wpe-backend-0.1/rdk-wayland.so
/usr/lib/wpe-backend-0.1/rdk-rpi.so
/usr/lib/wpe-backend-0.1/rdk-imx6.so
[....  etc ... ]

Which would be quite nice (IMHO).

[kraj]

I would think that each one of them is not required on a given platform, so based upon the image/platform selection these plugins should be installed, but that can also be done at distro level

[clopez]

I would think that each one of them is not required on a given platform, so based upon the image/platform selection these plugins should be installed, but that can also be done at distro level

Indeed. Not all the backends can work on all hardware.
For example it makes little sense to build the rdk-imx6 on a system that doesn't have imx6/vivante (actually it won't be possible as building it depends on the vivante egl libraries).

The recipes for the backends ideally would know which backends can be built for the target hardware.

Currenty on meta-webkit I implemented this by making all the backends providers of a virtual/wpebackend dependency and making cog depend on virtual/wpebackend ..
so there is a PREFERRED_PROVIDER_virtual/wpebackend key that has to be set to one of them.
In other words, currently installing more than one backend its not possible

[aperezdc]

@clopez: Likely the wpe_backend_list() function is uneeded. What would be the use-case for it? I would just have a wpe_backend_set_library(path) (or similar) which accepts an absolute path to a .so or uses a preset directory in case of a relative path.

@kraj: There are cases in which, for the same platform, more than a single backend may be available. Take the example of the Raspberry Pi, where both a dispmanx and a Wayland backend (to run under Weston, for example) may be available, and the launcher may want to decide whether to load one or the other depending on whether e.g. $WAYLAND_DISPLAY is set, allowing the same build of WPE to be used in both ways without needing a rebuild.

Now, on a more general note, what I think the difficult part here is that both the WebKit UIProcess and the WebProcess need to load the WPE backend library, which means that the UIProcess has to pass down the path somehow to the WebProcess.

[clopez]

@clopez: Likely the wpe_backend_list() function is uneeded. What would be the use-case for it? I would just have a wpe_backend_set_library(path) (or similar) which accepts an absolute path to a .so or uses a preset directory in case of a relative path.

That would allow the launcher (cog) to know which backends are available so it can present that on the screen if the user asks for that.... perhaps with something like cog --list-backends. It will also allow it to know that the backend it requests actually exists.

You can argue that the launcher itself (cog) can list the files on the directory. But doing via an API call allows it to work without having the knowledge of where are the backends actually installed (that should be only know by wpebackend library itself IMHO)

[clopez]

@kraj: There are cases in which, for the same platform, more than a single backend may be available. Take the example of the Raspberry Pi, where both a dispmanx and a Wayland backend (to run under Weston, for example) may be available, and the launcher may want to decide whether to load one or the other depending on whether e.g. $WAYLAND_DISPLAY is set, allowing the same build of WPE to be used in both ways without needing a rebuild.

The RPi is not the best example, because the dispmanx depends on the propietary broadcom libraries.
And weston desn't actually work well with that libraries. It works much better with the open source stack (vc4), but then the dispmanx won't work.

Perhaps a better example is i.MX6 with vivante where you can use:

• rdk/wayland
• rdk/imx6
• fdo

[carlosgcampos]

I think wpe_loader_init() fixed this, right?

[aperezdc]

@carlosgcampos Indeed, your changes from PR #18 take care of this. Let's close this issue, then.