[RFC weston] 3D window manager using libweston

Harsha Manjula Mallikarjun (RBEI/ECF3) Harsha.ManjulaMallikarjun at in.bosch.com
Fri Nov 17 07:00:17 UTC 2017

> On 11/16/17 4:04 PM, Harsha Manjula Mallikarjun (RBEI/ECF3) wrote:
> > Hi All,
> >
> > we are developing a middleware frame work for a 3D window manager.
> > The window manager should be able to map the client buffers to 3D
> > shapes (cube, cylinder and so on).
> >
> > Our idea is that "3D window manager" uses libweston to get client
> > buffers and composites them on 3D shapes. Essentially, "3D window
> manager"
> >   acts as a compositor for the system by making use of libweston (i.e.
> > 3D window manager is a process with libweston loaded under it and it
> > is the ultimate compositor of the system).
> >
> > Short summary of concept implementation:
> > To achieve this using libweston we exported eglImages from gl-renderer
> >   and give control of swapping display buffer to window manager.
> > Backend and renderer are changed to support different modes of
> operation so that control to
> >   swap display buffer can be with window manager whenever needed.
> >
> > Window manager listens to surface_commit, surface_finalize_signal,
> >   subsurface_add/remove Signals. Using these signals window manager will
> get to
> >   know if  there is an update to the surface OR sub-surfaces under it, and
> queries
> >   the respective eglImages from gl-renderer. Gl-renderer will be put
> > into a mode where it will not do composition. Window manager takes total
> control of
> >   composition and swapping buffer to display.
> >
> > Development was started on Weston 2.0. Following patches give the
> >   idea of changes:
> >
> > 1) Make additional library to reuse code for loading backend from
> > main.c
> >
> https://github.com/HarshaMM/weston/commit/1b193d62db53b22cc195bfe
> 694f6
> > b4bde07d0fd3
> I have to object strongly on this one. What is the needed feature here?
Thank you for the comments. We need the Weston config (option parser)
 and relevant handling for backends present in main.c. The idea was just 
to reuse rather than copying/re-implementing the source and maintaining it.

> Not to mention you didn’t properly namespace all the functions.
[HarshaMM]  Agree, the patch needs improvement. Depending on further
discussion on this topic we are flexible to redo the design/implementation.

> Of course, it doesn’t force people to use it, but it is just yet another
> command line options and INI parsing library with a few wrappers around
> libweston. That does not sound like a good idea to me. Also, it’s more public
> API/ABI to support.
These APIs just make it easy for anyone to use Weston compositor as a thread
under their own process.  Why do you think it’s a bad idea? 
Can't it be viewed like a helper library? Any other ideas for this use case are

> Please note that I want to add the concept of libweston plugins, but these
> should not need argc/argv. This is just in case you used mainly this part.
> > 2) To export EGLImages of each of the client buffers to window manager
> >    (same process space). Implementation primarily involves gl-renderer.
> >
> https://github.com/HarshaMM/weston/commit/d43f42aa06715b52d37df3d5
> d0d7
> > fa97638d1dfc
> I don’t have enough knowledge to comment on this one about
> implementation.
> I have no strong objection to put gl-renderer in a public plugin, but it should
> be done with extra care, regarding making sure it’s loaded.

> > 3) Changes to compositor.c for additional signals of surface and sub-
> surfaces.
> >
> https://github.com/HarshaMM/weston/commit/db335535a8b4abfee52dc1d
> 6099e7db03e6973d4
> >
> https://github.com/HarshaMM/weston/commit/6a2f071bde56abed69c7ab8
> 27135d1cef5ea35bc
> >
> https://github.com/HarshaMM/weston/commit/a51ff22c8fab534e475fa671b
> 1b7ed77ffc8571c
> >
> https://github.com/HarshaMM/weston/commit/d5646de516b635f5d01aa92
> 5c0c02275126e132d
> These don’t seem bad, but at one point, we’d want to make struct
> opaques, so we probably want wrappers for listeners here.
> > 4) Changes to Backend to enable swap from an external renderer (window
> manager).
> >
> https://github.com/HarshaMM/weston/commit/013e2e4eda6d67d5e32ce4a
> a74e0d6e18c3770f2
> Same as 1.
Yes. I also think it’s not a good way. I feel it’s a  bit hacky implementation. 
Window Manager needs to have control of swapping buffers to display. 
One clean way may be to make backend as a loadable plugin and expose
public API for swap control, may be NOT as part of "weston_windowed_output_api".

Do you see any other better approach here?
> > It would be great if you can provide your thoughts about the
> implementation concept. It would
> > be helpful to know if there are any hard constraints/different design, due
> to which this concept
> >   should be entirely changed OR it is not a way to realize this using libweston.
> >
> > Based on your feedback we will decide whether to continue the
> development, rebase and improve
> > the above patches and submit it to community.
> Thanks,
> --
> Quentin “Sardem FF7” Glidic
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

More information about the wayland-devel mailing list