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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
