When to use libweston plugin registry

[Pekka Paalanen]

On Wed, 20 Jul 2016 13:49:05 +0200
Armin Krezović <krezovic.armin at gmail.com> wrote:

> On 20.07.2016 09:45, Pekka Paalanen wrote:
> > Hi Armin,
> > 
> > I didn't manage to catch you online, so here is re:
> > https://paste.debian.net/hidden/ac601ed5/
> >   
> 
> Hi Pekka,
> 
> Sorry for not being available in the past few days. I will be
> once again available full time starting tomorrow afternoon.
> 
> > Yes, that's the mechanics of using the plugin registry, but I
> > didn't think of using it for those particular entries.
> > 
> > For libweston-core <-> backend APIs using the plugin registry seems
> > like an unnecessary detour. I don't see it benefiting anything.
> > Libweston-core loads the backend directly and communicates with it
> > directly. We also wouldn't want to expose interfaces meant only for
> > the use of libweston-core. libweston-core is non-optional, so the
> > flexibility is not useful.
> > 
> > Originally plugin registry was written for plugins to interface
> > with other plugins, so that we don't need to keep adding new
> > plugin-specific APIs or relays to (lib)weston-core or the
> > compositor.
> > 
> > Another use case in my mind is offering optional interfaces from
> > libweston and anything below it to the compositor. It might be seen
> > as a layering violation since we skip over libweston-core rather
> > than plumbing things through it, but in this case I think it's for
> > the better.
> > 
> > E.g. DRM-backend specific APIs might want to use libdrm, libudev or
> > libinput types. If these were exposed from libweston proper, we
> > would have libweston depend on all of them, regardless whether the
> > compositor actually wanted the DRM-backend. It would be even more
> > glaring if x11-backend had some API using XCB or X11 types,
> > causing libweston to depend on libxcb. When we use the plugin
> > registry for these, we don't need the extra dependencies on the
> > libweston-core. The extra dependencies can be pulled in by the
> > backends and the interface headers used with the plugin registry as
> > needed instead of always.
> > 
> > In summary, I'd like to see the plugin registry used for optional
> > interfaces that might also come with a cost (e.g. extra
> > dependencies) if offered straight from libweston proper.
> > 
> > I still consider it optional even if it is mandatory for using a
> > specific backend or feature, because compositors are free to choose
> > the backend(s) and features they use.
> >   
> 
> When we discussed API for configuring outputs, you mentioned that
> I should consider using plugin-registry to call backend specific
> functions to configure an output.
> 
> We already have API's calling into backend specific code via
> function pointers (mode switching comes to mind), so I think
> it's safe to use same approach for output configuration (backend
> specific parts only).
> 
> So, to be sure, I don't need plugin-registry for such features?

Hi Armin,

there are two different kinds of things you should process
differently. The same solution won't fit everything.

The first category is functions like "destroy" and "restore" which
are meant to be called by libweston (core) alone. These should not
be exposed via plugin registry.

Libweston loads the backend, so it can just call its functions
"directly" anyway. There is nothing optional in that, whether
libweston would like to use that API or not - it will always use
it. Libweston is also the only user of these functions.

The second category are functions offered by the backend, but meant
to be called by the compositor (or plugins) and likely not by
libweston. These should be exported via the plugin registry,
because their availability and whatever requirements they bring e.g.
dependency-wise depends on the compositor choosing to use the
backend.

The functions in the second category also cannot be called directly
anyway, because libweston loads the backend but the caller is not
libweston. Either libweston would have to wrap those functions and
export them again, or we need to use the plugin registry to get to
them.

Output configuration functions would seem to fall into the second
category, each backend offering its own, slightly different API, to
be called not by libweston, but the compositor. IOW, both
backend-specific, and called from outside of libweston.

An example of such backend-specific configuration would be setting
the video mode, resolution, or (for nested windows) size:
- DRM has the whole modeline stuff you have to choose from
- fbdev cannot change modes, but you might still be able to pick
  which /dev/fb* you want to light up
- x11 can have an output of arbitrary size and create new outputs
  on demand
- wayland backend would behave either like DRM or x11, depending on
  the shell interface offered by the host compositor
- rdp I'm not even sure how it should behave
- headless would be like x11 mostly

OTOH, there could be some totally generic output configuration
functions too, like setting the output position in the global
coordinate system. These could be simply functions exported from
libweston core as usual to avoid repeating the API for each
backend, or repeated in each backend-specific API to make each API
"complete" on its own. Which approach is better, I cannot say yet,
but I'd start with seeing what the existing weston_output_*()
functions we could keep and use from the compositor rather than the
backend side of libweston.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160721/ad60713f/attachment.sig>