Users of libweston?

[Matt Hoosier]

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. 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.)

Thanks!
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180702/1a3fde10/attachment.html>