nedjelja, 31. srpnja 2016.
Week 10: Journey to the new output configuration API
As mentioned in the last week's post, I've been trying to write an API for libweston that can be used to configure an output outside of libweston. This week I made a lot of progress. By combining code from previously failed attempts and feedback from both of my mentors, I believe I have finally written an acceptable API (at least by my standards).
So, how does it work? Current model works like this (I'll make an example with DRM and X11 backends, as those are ones I've worked with most):
The DRM backend initializes outputs present at runtime and implements output hotplug using udev. To use a DRM output, backend does a lot of magic (which I don't understand fully, to be perfectly honest). Then it calls a function that needs to be written when writing a compositor (not part of libweston), which will then obtain preferred output configuration and does some more magic to make the picture appear on your screen driven by the DRM backend.
For X11 backend, compositor (libweston user) tells how many outputs should be configured and then the backend creates a number of outputs, whose configuration is either read from the configuration file, weston command line or hardcoded defaults.
This seems to work just fine. So, why bother writing a new API for configuring those outputs? It enables compositors to enable/disable/reconfigure outputs at will, implement configuration dialogs for more fancy output configuration, etc. Another reason that's important to me is to move output layout configuration from libweston, so compositors can choose to implement whatever layout placement they want.
The new model consists of these steps:
- When an output gets plugged in (or is "created" in case of backends such as headless, X11 or wayland), a backend creates an object representing that output, but doesn't fully initialize it like it was done before. It only initializes parts that are needed so an output can be cleanly configured or destroyed.
- A compositor is then notified that an output is created, and basic output is passed as the data which can be used to aid in configuration. At the moment, only data that's needed from the output object is its name, as the configuration is mostly done on per-output-name basis.
- Using plugin-registry, compositor calls corresponding function that's tied to the backend and tells it to configure an output using the desired configuration. Output can also be dropped, if it seems unnecessary.
This isn't much different from what DRM backend does presently: Detect an output -> Do a little magic to get the necessary data to ask for configuration -> Get its configuration from the compositor -> Configure the output. Only now, the user (libweston user) has the power to configure the output the way he sees fit. Of course, it's limited at the moment, but it can be extended, and it doesn't need to be generic or backend agonistic since it's exposed through plugin registry.
I hope I made some sense. I'm really tired and it's past midnight here. But it sure was fun working on this. So far, I've done the initial API and ported 4 backends to it: X11, fbdev, headless and DRM. Two backends remain: RDP and Wayland. I was looking at the wayland backend, but I need some more time to figure out how it really works. As for RDP, I might have a hard time there, as I don't know how to test it, given that I don't have the needed tools for it. All the code is in my git repository, which can be found at https://github.com/krezovic/weston/commits/gsoc-v6 so it's not just talk this week. I hope I can get this done in the next week and move to the final task in the remaining week of GSoC - configuring output positions.