Users of libweston?

[Pekka Paalanen]

On Mon, 2 Jul 2018 09:34:40 -0500
Matt Hoosier <matt.hoosier at gmail.com> wrote:

> On Mon, Jul 2, 2018 at 4:10 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > On Fri, 29 Jun 2018 10:05:58 -0500
> > Matt Hoosier <matt.hoosier at gmail.com> wrote:
> >  
> > > Hi all,
> > >
> > > Pekka's recent comments about wanting to enable set-top boxes built with
> > > libweston to do DRM content got me to wondering:
> > >
> > > Who all is using libweston directly (as opposed to running  
> > /usr/bin/weston  
> > > possibly with custom shells plugins or similar)? For my own purposes, I
> > > just use the full compositor because it's pretty lean and mean anyway,  
> > and  
> > > I can do what I need by loading plugins.  
> >
> > Hi Matt,
> >
> > I wouldn't be surprised if there weren't many users yet. There is a
> > huge amount of things I'd like to do before I could comfortably propose
> > using libweston. I still think it needs to be a goal in mind all the
> > time though, otherwise we'll never get there. :-)
> >
> > IMO the major point of using libweston instead of weston is to be able
> > to customize the UX any way you want - all the stuff and policy that is
> > currecntly hardcoded in main.c and the desktop-shell plugin. Making all
> > configurable is probably not feasible.
> >
> > My hope with gaining set-top box etc. use cases is to gather more people
> > developing for Weston, people who could be dedicated in the long run.
> > Maybe that could gain us more upstream maintainers.
> >
> >
> > Thanks,
> > pq
> >  
> 
> Hi --
> 
> Yeah, that all makes sense. I certainly didn't mean to imply any criticism
> with the question.

Oh, none taken! I'm happy to explain what vague vision I might have,
since discussion will help to clarify it and seeking acceptance is
important to me.

> I wasn't yet following the conversations on
> wayland-devel when Weston got overhauled to split out its core compositor
> features as libweston, so I wasn't positive exactly who the intended users
> are. I suppose that maybe there's little chance that Mutter or Kwin would
> ever adopt this (although that would be an amazing proof of generality).
> 
> The question mainly came from my observation that the modularity of the
> plugin system in Weston seems _so effective_ that it almost completely
> subsumes the need for using libweston. I run several out-of-tree plugins
> (one of them providing an alternative to desktop-shell, and a few others
> doing random runtime things such as integrating with systemd  -- yes, I
> know there's an official Weston plugin for that ;) ), and the
> /usr/bin/weston entrypoint still seems to hold up very well for all this.
> 
> The bit about being able to work around policy choices made in main.c does
> make sense.
> 
> On the topic of modularity: what was the reason why the libweston overhaul
> nixed the ability for out-of-tree plugins to contribute new backends? (This
> is just a curiosity question -- I'm don't have any particular opposition.)

It was an idea to limit the API surface of libweston. It's the same for
renderers, those are meant to be only built-in so far.

There is a huge amount of API to go through, separate into public and
private (actually to frontend, backend, renderer, shell, other
plugins, ...), sanitize, and possibly redesign, that I wanted to
restrict the scope at first. Once the stuff used by main.c and shell
plugins is in shape, we could look at doing a backend ABI if there's
demand.

But, if libweston has public ABIs in every direction, it might be hard
to eventually stabilize libweston.

I suppose one reason why the plugin model is currently so powerful is
that libweston doesn't really have a private API, everything is more or
less public.

It's the trade-off between power/flexibility and stability. Exposing
everything lets external plugins do anything they want, but it also
means we break the ABI on practically every release. Reducing ABI
surface to avoid breaking it in every turn will limit what plugins can
do.

I've been thinking that a stable libweston ABI is a worthy long-term
goal. Is it? Or is the libweston major version bumping working too
well? ;-)


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