libweston ABI plans (Re: Wayfire - a compositor which utilizes libweston)

[Pekka Paalanen]

On Thu, 22 Mar 2018 10:49:23 +0200
Ilia Bozhinov <ammen99 at gmail.com> wrote:

> Hello to all,
> Some of you may know that I've been working on a wayland
> compositor(primarily for the desktop), and I decided it was time to share
> what I've done(although it still needs much more work), here is the link:
> https://github.com/ammen99/wayfire
> The most "novel" thing it does is implement the desktop cube in wayland :D
> 
> It needs a patched libweston, so I'd like to raise another question: Is
> there any interest in implementing custom rendering for libweston, and if
> yes, how should it be implemented?
> 
> A proof-of-concept implementation:
> https://github.com/ammen99/weston/commit/1eefc1301bddf593fc994900996507ffc97ffa75
> 
> Is this even close to the design goals of libweston?

Hi,

I am glad to see your work, and that is a very good question. Below is
my personal take on the matter.

The idea for libweston so far has been to try and limit the API surface
we would need to set in stone to be able to claim that libweston has a
stable ABI. So backends and renderers were so far left as internal
details, while stuff needed by shell plugins and main()s would be
public ABI. The hope was that this would allow us to actually draw a
clear line between public and private APIs during the coming years.

Along that plan, we would aim to make the central huge structs like
weston_compositor, weston_surface, weston_view, and weston_output
opaque. A renderer will dip into most of these in ways that is outside
of the imagined public API. Currently renderers also need specific code
in the backends to initialize, but I suppose that could be abstracted
to basically Pixman and EGL (until someone wants to make a Vulkan
renderer).

On one hand it would be nice to let people do what they want. On the
other hand, upstream needs to maintain libweston, and it would also be
in the external projects' interests if libweston gained a stable ABI.
The more ABI surface, the harder it is to maintain, and most of the
current ABI has not even been designed really, so it's leaking
approximately all implementation details.

Unfortunately, people (me especially) have been busy elsewhere rather
than pushing forward the stable ABI dream.

I think that if you simply proposed to add a few simple hooks to be
able to load your own renderer module without thinking about the ABI
stability issues, I would be inclined to say "no". However, I would
warmly welcome you to join the effort to separate a stable ABI out from
the current mess, and alongside that you could design a renderer ABI as
well. Mind, along the course we would likely have to redesign big
portions of libweston core, particularly around the scenegraph.

Designing ABI without users is almost impossible to do sanely, so your
input would be invaluable.

Having a defined renderer ABI would also have a huge benefit: testing.
If all renderers were behind the same'ish ABI, the renderers themselves
could be unit-tested. Also libweston core could possibly be tested
better with a mock renderer. Right now, we can only test the Pixman
renderer, ironically, in integration tests. The GL renderer still has
no automated tests.

One more requirement is that whatever interfaces you need to have
added, they should also be used in Weston upstream itself. If they're
not used, they will break, and the urge to just remove them as clean-up
will be great, because of the desire to reduce the API surface.

As a summary, yes, I think it would be possible, but it would take a
serious commitment to make it happen. You need to become part of the
upstream rather than send your bits upstream. :-)

A concrete suggestion would be to move the existing upstream renderers
behind the renderer API you need.


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/20180322/684c7f73/attachment.sig>