Re: [RFC weston 4/5] drm: Move backend to libweston
sardemff7+wayland at sardemff7.net
Sat Feb 13 19:56:18 UTC 2016
On 13/02/2016 11:22, Benoit Gschwind wrote:
> 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->base.name is not too long.
output->base.name 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
>> 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