Multiple HW plane enable BKM in open source Weston

[Pekka Paalanen]

On Fri, 3 Jan 2020 13:24:56 +0200
Marius Vlad <marius.vlad at collabora.com> wrote:

> Hi,
> 
> Well, if the overlay (which apparently is underlay in your case)
> plane supports YUYV you don't any kind of color conversion
> between them. Pekka already made this pretty clear: you need to
> match out what pixel format you're using with that of the overlay
> plane. There's drm_info from Scott
> (https://github.com/ascent12/drm_info) or modetest from libdrm to
> check what your HW supports.
> 
> While weston doesn't properly support underlays, (and this is
> on-going issue at the moment) weston if capable to place multiple
> views in multiple HW planes.
> 
> For your particular use case, the only to achieve that, is that
> the main UI has to be alpha blended with the (view) one below
> when you want to display the video in overlay.
> 
> Do note that for a view to reach the primary plane the view has
> to cover the entire output. As we don't properly support
> underlays (which requires additional work to reveal the view
> underneath the view assigned in the primary plane) you'll need to
> have the video in the overlay matching the entire output as well.
> 
> Not only that, but for all of this to work, you'll need to bind to
> wl_subcompositor interface and with it, to use sub-surfaces for
> your application to behave as one, otherwise you ran into the
> problem of the main UI being fullscreen which gets injected an
> additional black surface view below it, and you won't be able to
> display anything underneath it, even if even if you (locally)
> alpha blended it.
> 
> But also do note, this might not be that easily achievable due to
> HW constrains, as adding alpha blending to a plane increases the
> BW necessary by the HW which will be easily saturated when
> combined with another plane (overlay), so weston will then go
> into compositing mode of rendering. You'll need to verify that
> with `drm-debug' scope if that happens.
> 
> PS: I've interchanged overlay with underlay here so adjust
> accordingly when reading.
> 
> On 1/3/20 12:47 PM, Tang, Jun wrote:
> > Thanks Marius/pq for the quick comments. 
> > 
> > My use case is something like video playback. I would like to
> > put video content on lower overlay and UI on upper plane.
> > According to your feedback, seems not easy for me to do that.
> > First of all, my video content should be YUYV format. Secondly
> > even I do some CSC to make it as AR24, since the UI is always
> > AR24 also. Looks like I still can't clearly put UI and video
> > content on separate planes without any code changes to the
> > compositor. 
> > 

Hi,

in other words, the way to attempt your scenario is to do this in
the client:

- create wl_surface A for the video
- create wl_surface B for the UI
- use wl_subcompositor to arrange one as the sub-surface of the
  other and stack B on top of A
- whichever wl_surface is the root surface, make that into a
  fullscreen window via xdg-shell
- size wl_surface A exactly to the fullscreen size (you can use
  wl_viewport if you need to)

This should result in a scenegraph in the compositor where the YUV
video covers the whole output and is opaque, therefore nothing from
below it will be considered, and the UI is layered on top.

If the video buffers are suitable for primary plane in DRM KMS, and
the UI buffers are suitable for an overlay plane in DRM KMS, you
should get what you wanted.

As mentioned, there is no way from a client to ask for, demand, or
force the use of KMS planes because that could potentially break
the compositor, but the client can arrange the scenegraph in a way
that makes KMS plane usage possible.

A problem here is that putting YUV on the primary plane likely
requires a pixel format change on the primary plane, as it is
usually used with an XRGB format. If your hardware or KMS driver
does not support changing the primary plane pixel format without
ALLOW_MODESET, this will not work[2]. In that case, if your hardware
and KMS driver supports an YUV overlay plane below the primary
plane, it would need the so called "underlay support" in Weston
which does not yet exist[1].

Btw. the Wayland presentation-time extension can be used by a
client to see if its wl_surface made it to a hardware plane by
checking for the ZERO_COPY flag.


[1] https://gitlab.freedesktop.org/wayland/weston/issues/9

[2] https://gitlab.freedesktop.org/wayland/weston/merge_requests/16

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200104/bac47e5a/attachment.sig>