Multiple HW plane enable BKM in open source Weston

Fri Jan 3 11:24:56 UTC 2020

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. 
> 
> -James
> 
> -----Original Message-----
> From: Pekka Paalanen [mailto:ppaalanen at gmail.com] 
> Sent: Tuesday, December 31, 2019 8:41 PM
> To: Tang, Jun <jun.tang at intel.com>
> Cc: Marius Vlad <marius.vlad at collabora.com>; wayland-devel at lists.freedesktop.org
> Subject: Re: Multiple HW plane enable BKM in open source Weston
> 
> On Mon, 30 Dec 2019 11:29:02 +0200
> Marius Vlad <marius.vlad at collabora.com> wrote:
> 
>> Hi,
>>
>> Yes, overlays are supported in weston but do note that this mailing 
>> list is also about other compositors and the protocol itself.
>>
>> Clients do not specify where to "place" the surfaces, the compositor 
>> back-end is the only one who can make those decisions based on what HW 
>> is capable of, what is currently in use, and what other surfaces are 
>> currently being displayed. The back-end, in weston, got a new face 
>> lift, and exposes a little bit better the conditions in which a view 
>> can make it to a HW plane: is a
>> (HW) plane available, is the pixel format suitable, etc. If you feel  
>> adventurous that should be place to learn more.
>>
>> Together with this face lift weston can now place an AR24 type of 
>> pixel buffer on the overlay plane, so if HW capable of using that 
>> pixel format should be able to place the view into an overlay plane. 
>> I'm mentioning this because `weston-simple-egl` will default to that 
>> when started, and a fairly recent i915 driver should have an overlay 
>> supporting that.
>>
>> We have in weston debug scopes capable of displaying large amounts of 
>> debug information. Start weston with with `--debug` and use the client 
>> `weston-debug` with `-a` to list all current debug scopes. 
>> `drm-backend' is the one useful in this case. It will display which 
>> views made to it a HW plane, or why was the reasons for not doing so. 
>> Should be able to correlate a bit this information with decision tree 
>> currently done in weston.
>>
>> Hope this helps.
>>
>> On 12/30/19 4:05 AM, Tang, Jun wrote:
>>> Hi Wayland Experts,
>>>
>>> I checked the open source version of Weston code, seems there is 
>>> atomic mode setting API to add new plane properties. I believe 
>>> overlay HW plane should be supported by Weston. But as a newbie for 
>>> Wayland. Still not sure how application can put their surface on 
>>> specified HW plane. Could you please share me some BKM on Wayland 
>>> client side? Any quick ideas would be appreciated!
>>>
> 
> Hi,
> 
> Marius is right. I'd just clarify, that there are no client examples because there is nothing a client needs to do to make use of hardware overlays.
> 
> Well, almost. There is no API for overlays for clients at all, but clients do need to use buffers that are possible to be put on hardware overlays. In practise that means they need to use dmabuf buffers with a compatible format.
> 
> Creating compatible buffers is a game of luck for now, but there is an effort to make it more predictable:
> https://gitlab.freedesktop.org/wayland/wayland-protocols/merge_requests/8
> 
> Once that improvement is done, it will likely be used automatically inside the Mesa EGL implementation, meaning that applications that use the EGL Wayland platform, e.g. weston-simple-egl, will get the benefit without any code changes.
> 
> 
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

-- 
Marius Vlad

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200103/6e4ed561/attachment.sig>