Skip to content

Better assignment of views into HW planes

Marius Vlad requested to merge mvlad/weston:views-hw-planes into master

So, this is obviously about #275 (closed) in which we should better decide, depending on the HW, how to assign the views to HW planes. More explanation on the use-case will be there if you're interested.

The basic idea starts from the suggestions provided by @pq in #275 (comment 221054). That is, to have a way to hard-code zpos values that match the hard-coded fall-back approach we currently have in the code, in the event that the HW doesn't expose the zpos properties. Based on that I fill-up a list of HW planes (starting with the biggest zpos value at the head) and use that to go over the planes.

What this series does:

  • When using the HW list of planes, the overlay occluded tracking had to go away as it wasn't necessary anymore.

  • An issue that I've found was that we can't reliably do an atomic commit if the scanout (primary plane) does not contain a valid buffer attached, so in one of the patches I cheated a bit (well, I guess it depends on how you see it) when assigning a view to an overlay but latter on, I corrected that by checking also if the primary plane contains a valid buffer. I've decided to keep this as a separate patch and not squash it.

  • Another problem was the totally occluded damage tracking that had to be adapted as this is tracking if new views will occlude previous ones. This only activates now only if the previous view there is a view in the scene-graph that is fully opaque, covers the entire output, and there no free available planes.

  • The shell in some circumstances, will inject additional views into the scene graph. Those view are not backed by a real buffer and in our propose stage we will switch to MIXED mode of compositing to deal with them. Currently, in this series, I ignore completely like we have with totally occluded views bit, to void reaching that mode. There's a small optimization in place currently, which will ignore the view if there's already a view that is fully opaque and that covers the entire output.

PS: There has been some talks about using the plane ID instead of zpos but in current version I kept only using zpos, at least to get some initial feedback on this and see further down the the line, if using plane ID is a better choice.

Edited by Marius Vlad

Merge request reports