Plan for libweston backend configuration?
gschwind at gnu-log.net
Fri Mar 4 09:44:40 UTC 2016
Le 29/02/2016 15:43, Pekka Paalanen a écrit :
> Hi Bryce,
> 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
> must fail
ok I will update my patches set accordingly.
> 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.
The current approach is broken, imo. Your proposal look good.
> 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.
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel