[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <TTLQQQ.OCR65URAWJVQ2@crapouillou.net>
Date: Mon, 29 Mar 2021 16:32:17 +0100
From: Paul Cercueil <paul@...pouillou.net>
To: Simon Ser <contact@...rsion.fr>
Cc: Maxime Ripard <maxime@...no.tech>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>, od@...c.me,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH] drm: DON'T require each CRTC to have a unique primary
plane
Hi Simon,
Le lun. 29 mars 2021 à 14:11, Simon Ser <contact@...rsion.fr> a écrit
:
> On Monday, March 29th, 2021 at 4:07 PM, Maxime Ripard
> <maxime@...no.tech> wrote:
>
>> Since it looks like you have two mutually exclusive planes, just
>> expose
>> one and be done with it?
>
> You can expose the other as an overlay. Clever user-space will be able
> to figure out that the more advanced plane can be used if the primary
> plane is disabled.
>
> But yeah, I don't think exposing two primary planes makes sense. The
> "primary" bit is just there for legacy user-space, it's a hint that
> it's the best plane to light up for fullscreen content. It has no
> other
> significance than that, and in particular it doesn't mean that it's
> incompatible with other primary planes.
Yes, from what I understood when writing the driver, there is not much
of a difference with primary vs. overlay planes when dealing with the
atomic DRM API, which I used exclusively.
Making the second plane an overlay would break the ABI, which is never
something I'm happy to do; but I'd prefer to do it now than later.
I still have concerns about the user-space being "clever" enough to
know it can disable the primary plane. Can e.g. wlroots handle that?
Cheers,
-Paul
Powered by blists - more mailing lists