On Sat, 12 Mar 2016 11:33:40 -0800 "Jasper St. Pierre" <jstpie...@mecheye.net> wrote:
> I have to bring this up, because it's not necessarily true. There's > something you're missing. After working on embedded SoCs, I realize > that a lot of them put the YUV video plane *behind* the main RGB > plane. This allows them to do subtitles and OSD controls over the > video without stacking it RGB -> YUV -> RGB, as you might imagine. Oh my. > Thankfully, some of these systems allow you to put the video on top of > RGB, but not all. Some even just have two YUV planes (for > picture-in-picture) and one RGB plane on top, not even a cursor plane. > > On embedded systems where they have fullscreen control, they simply > render alpha-graphics into the RGB window, and then stack a YUV plane > behind it to blend against. > > Wayland, in its current subsurface architecture, can't support this > system, unfortunately. The best thing I could think of here was to > have Wayland consider a punch-through when it sees a YUV plane stacked > under an RGB one from the same client, and it knows the scanout is > ARGB. But maybe that's too auto-magical. > > I think that could work, but the implementation would need to be > tricky about all the special cases, if we cared enough to make those > work, e.g. surfaces under the punch-through need to be knocked out, > but surfaces above can't be, since they're stacked on top. And that > implies surfaces under the punch-through can't themselves use > overlays, etc. I don't think it should be *that* hard, but of course I'm only talking from Weston implementation point of view. Let's say the scenegraph has a bunch of arbitrary surfaces below and above a particular YUV surface that would be nice to put in a separate hw plane. This YUV-surface is also opaque, which is a requirement to even consider underlay. Weston goes through the surface stack from top to bottom, looking for surfaces that could be put on overlays. It comes to the YUV-surface, but there are already things on top of it, so it cannot be promoted to an overlay. Seeing that using underlay is possible from DRM perspective, it decides to put it on an underlay. Putting a surface in an underlay requires adding an extra surface filled with RGBA (0,0,0,0) color for the renderer to create a punch-through (or just set a flag in the weston_view that this is a punch-through surface). Weston continues going through the surface stack. If it finds another YUV surface, the accumulated occlusions prevent it from going to another underlay, perhaps. So the surface to plane assignment should work. Then the renderer flattens everything on the primary plane. Since the punch-through placeholder surface is both opaque and filled with (0,0,0,0), the renderer automatically creates the punch-through hole as intended, not rendering anything from beneath it, and rendering everything that may be on top of it. It's obviously not trivial, but I think Weston already computes most of the things needed to do this, like opaque and non-opaque occlusions. What we are mainly missing is how to choose between overlay and underlay. And of course implementing the underlay bits in practice. We already have region checks to see if overlays can be used not just for the topmost surfaces, and underlays would need their own similar checks/accumulation. I also don't see how which client gives which surface would affect this. There is no reason that the thing on top of an YUV surface must be from any particular client. So I think Wayland does support this. It would be possible to implement in Weston IMO. OTOH, I cannot imagine what we should add, remove or change in the Wayland protocol to help underlay support in addition to overlay support, even if we were not bound by stability requirements. The biggest problem I see is that there may be (and are) several different solutions for a scenegraph to be laid onto hw planes, and choosing the optimal configuration is not easy. That, and creating a test suite to make sure things actually work. Thanks, pq
pgpKmsJeJgdeX.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
