{RFC weston] 3D window manager using libweston

[Quentin Glidic]

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/1b193d62db53b22cc195bfe694f6b4bde07d0fd3

I have to object strongly on this one. What is the needed feature here?
Not to mention you didn’t properly namespace all the functions.

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.

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/d43f42aa06715b52d37df3d5d0d7fa97638d1dfc

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/db335535a8b4abfee52dc1d6099e7db03e6973d4
> https://github.com/HarshaMM/weston/commit/6a2f071bde56abed69c7ab827135d1cef5ea35bc
> https://github.com/HarshaMM/weston/commit/a51ff22c8fab534e475fa671b1b7ed77ffc8571c
> https://github.com/HarshaMM/weston/commit/d5646de516b635f5d01aa925c0c02275126e132d

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/013e2e4eda6d67d5e32ce4aa74e0d6e18c3770f2
Same as 1.


> 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