{RFC weston] 3D window manager using libweston

Harsha Manjula Mallikarjun (RBEI/ECF3) Harsha.ManjulaMallikarjun at in.bosch.com
Thu Nov 16 15:04:57 UTC 2017


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

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

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

4) Changes to Backend to enable swap from an external renderer (window manager).
https://github.com/HarshaMM/weston/commit/013e2e4eda6d67d5e32ce4aa74e0d6e18c3770f2

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.

Best Regards,
Harsha




More information about the wayland-devel mailing list