Plan for libweston backend configuration?

[Benoit Gschwind]

Hi pq,

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
> 
> Yes.
> 
>>    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
>>  	   https://patchwork.freedesktop.org/patch/73206/
>>        https://patchwork.freedesktop.org/patch/[73035,73036,73037,73038,73039]
> 
> 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
> again.
> 
>>    d.  Review/update wayland-backend and x11-backend to comply
>>    	   https://patchwork.freedesktop.org/patch/74553/
>> 	   https://patchwork.freedesktop.org/patch/74504/
> 
> Yes.
> 
>> 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.
> 
> 
> Thanks,
> pq
> 
> 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>