<div dir="ltr">On Mon, Jul 2, 2018 at 4:10 AM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 29 Jun 2018 10:05:58 -0500<br>
Matt Hoosier <<a href="mailto:matt.hoosier@gmail.com" target="_blank">matt.hoosier@gmail.com</a>> wrote:<br>
<br>
> Hi all,<br>
> <br>
> Pekka's recent comments about wanting to enable set-top boxes built with<br>
> libweston to do DRM content got me to wondering:<br>
> <br>
> Who all is using libweston directly (as opposed to running /usr/bin/weston<br>
> possibly with custom shells plugins or similar)? For my own purposes, I<br>
> just use the full compositor because it's pretty lean and mean anyway, and<br>
> I can do what I need by loading plugins.<br>
<br>
Hi Matt,<br>
<br>
I wouldn't be surprised if there weren't many users yet. There is a<br>
huge amount of things I'd like to do before I could comfortably propose<br>
using libweston. I still think it needs to be a goal in mind all the<br>
time though, otherwise we'll never get there. :-)<br>
<br>
IMO the major point of using libweston instead of weston is to be able<br>
to customize the UX any way you want - all the stuff and policy that is<br>
currecntly hardcoded in main.c and the desktop-shell plugin. Making all<br>
configurable is probably not feasible.<br>
<br>
My hope with gaining set-top box etc. use cases is to gather more people<br>
developing for Weston, people who could be dedicated in the long run.<br>
Maybe that could gain us more upstream maintainers.<br>
<br>
<br>
Thanks,<br>
pq<br></blockquote><div><br></div><div>Hi --</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>The bit about being able to work around policy choices made in main.c does make sense.</div><div><br></div><div>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.)</div><div><br></div><div>Thanks!</div><div>Matt<br></div></div></div>