[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPj87rM1dbawwtRnMzDRLLCt6FuOU+851hcJhKDsg1ioRM2Pqw@mail.gmail.com>
Date: Thu, 18 Jul 2024 12:15:00 +0100
From: Daniel Stone <daniel@...ishbar.org>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Cc: chunkuang.hu@...nel.org, p.zabel@...gutronix.de, airlied@...il.com,
daniel@...ll.ch, matthias.bgg@...il.com, shawn.sung@...iatek.com,
ck.hu@...iatek.com, dri-devel@...ts.freedesktop.org,
linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, kernel@...labora.com
Subject: Re: [PATCH] drm/mediatek: Declare Z Position for all planes
Hi,
On Thu, 18 Jul 2024 at 09:25, AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com> wrote:
> MediaTek SoCs support multiple planes, one of which is the primary
> and all the others are overlays (and CURSOR is the last overlay).
>
> In all currently supported SoCs, the Z order of the overlays can't
> be changed with any fast muxing action, and can only be changed by
> swapping the contents of the entire register set of one overlay
> with the other to internally reorder the layer properties, which
> is indeed feasible, but probably more expensive than desired.
>
> Declare the Z position for all planes with an immutable property
> at least for now, so that the userspace can take its decisions
> accordingly.
Thanks a lot for this fix!
If I understand your middle paragraph correctly, please don't ever do
that though. I think what you're suggesting by 'swapping the contents
of the entire register set' is:
* plane ID 40 (normally) controls OVL1
* plane ID 41 controls OVL2
* userspace configures planes 40 & 41 with a zpos suggesting that 41
should be below 40
* the DRM driver 'swaps the contents of the entire register set' by
making plane 40 control OVL2 instead and plane 41 control OVL1 instead
If so - please no. Just declare an immutable zpos, because that
actually matches the hardware, and then leave userspace to configure
the planes in a way which makes sense. Looking at the zpos property is
already required in order to handle overlapping overlay planes, and
any userspace which supports overlays (including Weston) already looks
at zpos, handles immutable properties, and will dtrt.
Anyway, this is:
Acked-by: Daniel Stone <daniels@...labora.com>
Cheers,
Daniel
Powered by blists - more mailing lists