Plan for libweston backend configuration?

Pekka Paalanen ppaalanen at
Mon Feb 29 14:43:37 UTC 2016

Hi Bryce,

On Fri, 26 Feb 2016 13:37:59 -0800
Bryce Harrington <bryce at> wrote:

> To followup Pekka's recent libweston thread, here's the next actions it
> looks like we should take?
>    a.  Revert 5ffbfffa


>    b.  Land, which covers
>        the drm-backend.  (Is this patch proposal good as is, or would it
>        benefit from any additional review?)

Yes, though struct weston_backend_config still needs a 'size_t
struct_size' added as the first member with the following semantics:
- the caller must set struct_size to sizeof(struct weston_whatever_backend_config)
- if a backend receives a struct_size smaller or equal to what it uses,
  it uses the given portion
- if a backend receives a struct_size greater than what it uses, it
  must fail

What happens with struct weston_drm_backend_output_config is still open
a bit. I think we should just land something that gets us forward for
now, and rethink the whole output hotplugging.

I feel the current approach of "backend found a new output, it demands
some parameters and will extend the desktop there" is a bit rigid. A
more flexible design would be to maintain a dynamic list of possible
outputs with hotplug notifications, and the compositor can then itself
enable, disable and configure outputs as it wants. So rather than a
backend always unconditionally enabling a connected output, it gives the
decision to the compositor which can also pick the layout etc.

This might even allow to better integrate nested and bare compositors:
a windowed nested compositor could just create any new output, while a
bare compositor checks if the output is actually connected and succeeds
or fails output enabling accordingly.

But I assume this will be a major work, so it must not hold up the
libweston effort on other fronts.

>    c.  Defer the two alternative options for now

Yes, and we may want to have a comment in the code pointing to e.g. the
email thread where these were discussed, in case the matter comes up

>    d.  Review/update wayland-backend and x11-backend to comply


> This establishes Giulio's "Well Defined Structs" approach for
> configuring libweston backends.  This uses versioned structs for
> communicating parameters with the backends.
> If no one raises an objection to this plan, I can tackle (a), (b) and
> (c) myself directly.  For (d), offhand it appears they at least need to
> add the structure versioning support, but might be suitable to consider
> landing after that?

Very good.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the wayland-devel mailing list