Thanks Pekka for explaining it. May be I will have a look once Daniel shares the latest branch details.
On Fri, Jun 9, 2017 at 5:10 PM, Pekka Paalanen <[email protected]> wrote: > On Fri, 9 Jun 2017 15:02:03 +0530 > Vikas Patil <[email protected]> wrote: > >> On Fri, Jun 9, 2017 at 1:16 PM, Pekka Paalanen <[email protected]> wrote: >> > >> > On Fri, 9 Jun 2017 12:31:22 +0530 >> > Vikas Patil <[email protected]> wrote: >> > >> > > Dear All, >> > > >> > > I am using wayland/weston 1.11.0 (with ivi-shell and drm-backend) with >> > > DRA7xx (TI's automotive SoC) and Linux 4.4. I am investigating on how >> > > could wayalnd based application can be assigned to use particular >> > > pipeline. >> > > >> > > Use-case details: >> > > As TI's DRA7xx SoC provides 1 graphics and 3 video pipeline (also >> > > refereed >> > > as plane). For example I would like to assign GFX pipeline to GUI >> > > application, VID1 pipeline to video player, VID2 >> > > pipeline to camera application and VID3 for some other application. >> > > >> > > I can see currently weston uses only GFX pipeline. Is there a way to do >> > > this using wayland/weston? What needs to be done to achieve this? >> > >> > Hi, >> > >> > the proper solution is to get the atomic modesetting patch series by >> > Daniel Stone reviewed, finalized, and merged. This is the foundation >> > for how weston could use additional DRM planes at all. >> > >> > Once that is done, the window manager needs to ensure that the >> > scenegraph is always compatible with putting the surfaces you want on >> > the DRM planes you want. With ivi-shell that is very possible as you >> > have unique identification for every application surface. Then, there >> > might be tweaks needed in the libweston DRM-backend to achieve the >> > correct automatic surface/plane associations. >> > >> > The major point here is that one does not explicitly configure a >> > surface for a DRM plane in Weston or via protocol. The DRM planes will >> > be used automatically for any surfaces that might fit. >> >> Thanks a lot for your quick comments. >> >> What are the fitting criteria for mapping surfaces to plane >> automatically? What happens if number of surfaces are more than >> available planes, which surface gets the plane (in case some specific >> application desire to use plane not the other apps)? We have a use >> case where we want multiple applications to use the particular plane >> only? >> >> How the other h/w features for planes (z-order, global alpha, rotation >> ) are handled with this? Is there any way to utilize this also? > > Hi, > > the scenegraph is essentially a stack of views (surfaces). A simple > algorithm is to start from the top and check view by view: > > - is the buffer compatible with any available DRM planes > - does the view fit on a plane > - given what is laid above this view in the scenegraph, is it even > possible to promote the view onto a plane or would it violate > z-ordering, transparency/blending, etc. > - ... > > The difficult part is to find the optimal view/plane assignment, and > the above greedy algorithm is not guaranteed to find that optimal > solution. > > z-order, alpha, rotation, all that comes from the scenegraph and is > taken into account when assigning planes. After all, the visual result > must be according to Weston's scenegraph. Using scenegraph features > that cannot be realized with DRM planes is a sure way to prevent the > view from ever going on a plane. > > Any views that were not assigned to overlay planes will be flattened by > the renderer onto the primary DRM plane. > > That would be the starting point. A more sophisticated example would be > Android's HWC2 (hardware composer). > >> > Weston's architecture currently in master (let alone in something as old >> > as >> > 1.11) does not support interactions between the shell >> > plugin and the backend plugin to explicitly and permanently configure >> > the DRM plane assignments. It's not inconceivable to add the necessary >> > infrastructure, but I would see if the implicit approach works first. >> > >> >> > If you want to give the patch series a go, I believe Daniel can point >> > you to the latest branches. >> > >> I could give a try but not sure if the kernel from TI BSP (4.4.23) >> supports atomic mode setting (generic and TI SoC specific if any). How >> to to check if atomic mode setting is supported or not in kernel? Do I >> also need to update the wayland/weston to latest version or I can >> apply the patches to 1.11.0? I also need to know how to test then if >> able to apply the patches and run the weston? Which version of >> Wayland-ivi-extension I need to use with these patches or first need >> to tested with desktop-shell? >> >> I found the patches at https://phabricator.freedesktop.org/T7595 but >> it would be helpful to get the branch details. I see this patches are >> tested again intel and rockchip hw. Are they generic and supposed to >> work on other SoCs (DRA7XX TI) or some feature required to be >> supported in kernel/bsp to utilize this? > > Daniel could answer those questions much better than I. > > The patches in Phabricator are probably not even near the latest. We've > been doing review on the mailing list, but it has been a long while > since the last post, so I think there are even more recent branches. > > As for wayland-ivi-extension, I don't think any of us has any idea, but > OTOH, you should not need anything new from it. Applications will not > be aware of any of this at all. Also your window manager does not need > any new interfaces, it only needs to make the window ordering and > positioning "fruitful". Fruitful depends on the quality of the plane > assigment in Weston's DRM-backend. > > That's one benefit of automatic plane assignment: you don't need any > new protocols or interfaces anywhere from or above the compositor. At > least if your applications are already providing buffers that are > scanout-capable. > Regards, Vikash _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
