[RFC weston] 3D window manager using libweston

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?
[HarshaMM]
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.
[/HarshaMM]

> 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.
[/HarshaMM]

> 
> 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.
[HarshaMM] 
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
welcome.
[/HarshaMM]

> 
> 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.
[HarshaMM] 
Agree.
[/HarshaMM]

> 
> 
> > 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.
[HarshaMM] 
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?
[/HarshaMM]
> 
> 
> > 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