Plan for libweston backend configuration?
ppaalanen at gmail.com
Mon Feb 29 14:43:37 UTC 2016
On Fri, 26 Feb 2016 13:37:59 -0800
Bryce Harrington <bryce at osg.samsung.com> wrote:
> To followup Pekka's recent libweston thread, here's the next actions it
> looks like we should take?
> a. Revert 5ffbfffa
> b. Land https://patchwork.freedesktop.org/patch/67547/, 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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 811 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel