Weston default pixel format

[Santiago Otero]

Hi Daniel,

El 03/08/18 a las 10:41, Daniel Stone escribió:
> Hi Santiago,
>
> On Fri, 3 Aug 2018 at 09:28, Santiago Otero <sotero at gsertel.com> wrote:
>> El 03/08/18 a las 09:35, Pekka Paalanen escribió:
>>> 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.
> Control nodes have been removed from upstream kernels a couple of years ago:
> https://cgit.freedesktop.org/drm/drm-tip/commit/?id=8a357d10043c75e980e7fcdb60d2b913491564af
>
>  From the commit message, it sounds like your downstream kernel tree
> has some changes to allow control nodes to be used in this way, since
> they did not work out of the box. It will also not work with modern
> atomic drivers anymore.
Yes, you're right. I didn't know it. I'm using NXP kernel for iMX8M 
(based on version 4.9.88) and it has DRM control nodes back.
>>> 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.
> We've had good success with this in the past: the performance has been
> completely fine, and tearing is just a result of missing
> synchronisation, which at a guess could be improper handling of buffer
> release events. GStreamer's waylandsink is a good example of how to
> correctly use the interface if that helps.
I've already did some tests with Gstreamer's waylandsink and there was 
some tearing in the video. I need to try again.
One problem that I saw was that with Gstreamer's waylandsink there was 
some overload due to a lot of calls to drmModeAddFB2 from Weston. I 
though that drmModeAddFB2 was only needed first time when you register 
the buffer. Doing a strace to Weston process I see a lot of these calls 
during Gstreamer playing video with waylandsink:
ioctl(16, DRM_IOCTL_PRIME_FD_TO_HANDLE, 0xffffee93e910) = 0
ioctl(16, DRM_IOCTL_MODE_ADDFB2, 0xffffee93e828) = 0
ioctl(16, DRM_IOCTL_GEM_CLOSE, 0xffffee93e9b0) = 0
I need to do some more tests with my application and linux-dmabuf extension.
>
> Colour management is not yet supported in Weston, but a topic we are working on.
>
> Cheers,
> Daniel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Thank you very much,

Santiago Otero