Weston default pixel format

Santiago Otero sotero at gsertel.com
Fri Aug 3 08:27:27 UTC 2018

El 03/08/18 a las 09:35, Pekka Paalanen escribió:
> 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.
I was able to make it work with two changes:
1-Force Weston to use a ARGB format with option "gbm-format=argb8888"
2-Patch gl-renderer.c to render with alpha: glBlendFunc(GL_ONE, GL_ZERO) 
>> 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.
I think there's no need to get DRM Master if you only want to use 
another different  plane for drawing (/dev/dri/controlD64). I've got it 
working this way.

>> 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).
I've tried to make it work with Wayland dmabuf with little success. The 
performance was bad, there was tearing and it didn't work for HDR video 
due to some KMS/DRM properties that I need to set. Using patched Weston 
and my player with KMS, now it's working right.

> Thanks,
> pq
Thank you very much.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180803/590b7956/attachment-0001.html>

More information about the wayland-devel mailing list