While I expected to work full time on the project as soon as summer holidays started, I didn't take into account some things. Last week, I didn't write a blog post beacuse I wasn't at home from Saturday evening to early Thursday, and also had an exam this Thursday.
Over the past two weeks, I've been trying to write an API for libweston that can be used to configure an output outside of libweston. Currently, when a backend receives an output connected signal (ie, DRM backend), it will first call the compositor defined function to receive a desired configuration for the output (if any), and then configure the output in the backend itself. Backends such as X11/Wayland/Headless have different approach. Since they don't depend on real hardware (I like to call them virtual outputs), outputs are created when the backend is started and there can't be more outputs plugged in at runtime (at the moment), but can disconnect an output in case there's more than one (closing X11 window representing an output will destroy that output).
What I was trying to do over last two weeks is (roughly written) to make the backends notify the compositor when an output gets connected, and let the compositor configure the output by calling backend specific functionality used to configure an output. And that's where it all began.
The first idea, written week before last, was to introduce a weston_pending_output structure, and initialize it with output name, default options and function pointer that can be used to configure it, and notify the compositor process that the output has been created. The compositor then would call the output configure function with choosen parameters or let the backend use defaults passed at runtime. The idea wasn't that good because the defaults were in the backend, and they shouldn't be there. I was then suggested to try using the new plugin-registry API to expose the configuration.
The second idea, similar to first, was to expose all backend functionality in the plugin registry and
let the compositor and libweston use that for manipulating the backends and options. Now, that wasn't really necessary, as that wasn't the original intended use for plugin-registry. The plugin-registry was intended to be used outside libweston for functionality that libweston can't directly provide for different reasons (different backends having different configuration options is just one example).
Even after I was explained what was plugin-registry about, I took a third approach, and still didn't get it right. The idea was still the same as the first one (backend creates the output, notifies the compositor, compositor configures it by calling backend specific function). Only this time, I reused weston_output instead of using weston_pending_output, but still exposed too much unnecessary things through the registry. I once again misunderstood the use of plugin-registry and tried to write generic configure functions for all backends that are exported through the registry. This contradicts what I've written above about plugin-registry (and I just realized that this morning when Pekka once again explained the purpose of registry to me).
This morning, we have come to a conclusion that the original idea is right, but the API still needs to be properly designed. So far, I have no code in the repository to show (I had several patches on pastebin sites shared with both of my mentors; Pekka and Quentin "SardemFF7"), but I belive all three of us finally agreed on how it should be done - so I have a task for this week. But hey, libinput api was modified several times before they got it right, so that gives me hope that I'll do the same for the task I was appointed. Stay tuned.