Weston default pixel format

[Pekka Paalanen]

On Thu, 12 Jul 2018 13:49:06 +0200
Santiago Otero <sotero at gsertel.com> wrote:

> Hi all,
> 
> I have a display device that supports up to three different display 
> buffers: one graphic layer and two video layers. The graphic layer is at 
> the top (zpos=2).
> 
> I'm using Weston (DRM backend) with a Qt5 application at full screen 
> (graphic layer). Weston is using pixel format XR24 even if Qt5 is using 
> AR24.

Hi,

that is intentional, yes. Weston's renderers have been designed to
produce opaque framebuffers, because it assumes the primary plane is
the bottom-most for now.

Weston so far does not support underlays and it might be a lot of work
to support them, but I also think it would be nice to have if it can be
done with "generic userspace" i.e. not having any driver specific
knowledge coded in Weston or weston.ini.

> In another application I have a video player application that renders by 
> DRM into a video layer (zpos=1). The problem is that the HW alpha 
> composition is not working due to Weston pixel format and because of 
> that I'm unable to see the video layer.

No, you cannot use another KMS application at the same time as Weston
is active. The kernel DRM core will forbid access (denies DRM Master
status) if there is already something using KMS, so at any time you can
only run either Weston or some other DRM KMS app.

The fact that you think it is possible suggests that you are using a
deliberately broken downstream kernel. A normal upstream kernel would
deny this.

> Is there any configuration option to force Weston to use AR24?

Sorry, no, we will not take changes into Weston upstream that depend on
features that the kernel upstream specifically rejects (multiple DRM
masters or the equivalent on the same DRM device).

You could get around the single DRM master limitation by using DRM
leases, but AFAIK, you cannot lease just some planes of a CRTC, you
have to lease the CRTC as a whole, which means you still cannot have
one process driving one plane and another process driving another plane
on the same CRTC (output). Yet.

If it becomes bossible via DRM leases in upstream kernel, then we can
discuss this again. However, bare in mind, that the design is that
Weston will be in full control of all outputs it touches, which means
that leasing out a plane instead of a whole CRTC will need a glitch-free
synchronization protocol between Weston and the app.

My recommendation instead is to rearchitect your software stack so that
Weston will be the only KMS app in the system, and video players push
their content via Wayland through Weston, using e.g. the Wayland dmabuf
extension and Weston's support for overlays (and underlays, if someone
implements them).


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/20180803/304f8cd8/attachment.sig>