Weston default pixel format

[Santiago Otero]

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.
Hi,
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) 
=> glBlendFunc(GL_SRC_ALPHA, GL_SRC_ALPHA);
>
>> 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>