Re: [RFC weston 4/5] drm: Move backend to libweston

Quentin Glidic sardemff7+wayland at
Sat Feb 13 19:56:18 UTC 2016

On 13/02/2016 11:22, Benoit Gschwind wrote:
 > [snip]
> Following a comment from Quentin Glidic on IRC, I read wrong the
> snprintf (I readed printf ... a shame, my apology). Which make the patch
> valid if output-> is not too long.

output-> is managed in the backend and is fixed-sized already.
The size I used is even way too large for the possible values here.

> But I keep the following:
>> This case show that this approach is not very good, In that case the
>> developer must give a list of unbound outputs setup and key/value is not
>> well suited for that case. (there is some workaround, like using key
>> pattern).
>> This case also leave me to add that section/key/value is not a good
>> choice and you should stick to key/value.
>> I still prefer the opaque configuration structure with function to set
>> the structure content.

I am not sure how to understand that part (even with your precision on 
IRC) but I think it is relevant to remind something that I find really 
important (and not only for that specific comment):

We are designing the *backend* configuration API.
We agreed already that backends will be an internal implementation 
detail of libweston. As such, I (as a future libweston-based compositor 
writer) consider them as trusted, which means:
- They would not use getters to grab random parts of my configuration
- They should keep the options set “small” enough for end-users to write 
it in any text-based configuration format the compositor would like to 
use (Weston is currently using a KeyFile, which is a really common 
format and not really fitting for complex structures). I expect backends 
needing a really complex configuration to provide a GUI program, or use 
their own configuration file.
DRM is probably the most complex backend we will have for quite a long 
time (I consider any future “hardware-based” backend will have similar 
needs), and it fits well in the INI/KeyFile format.

In the current form, my patch has one little (IMO) 
non-backward-compatible change: it does not use a duplicated name 
"[output]" for the section with the "name=" key as the selector.
It is entirely doable if it is a requirement for this patch to be 
considered, but in this design, backends should use unique section 
names, since KeyFile parser (like GLib’s) can merge duplicate sections.



Quentin “Sardem FF7” Glidic

More information about the wayland-devel mailing list