mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Sean Anderson <sean.anderson@linux.dev>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	dri-devel@lists.freedesktop.org
Cc: Simona Vetter <simona@ffwll.ch>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	linux-kernel@vger.kernel.org, Maxime Ripard <mripard@kernel.org>,
	David Airlie <airlied@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	Michal Simek <michal.simek@amd.com>,
	Anatoliy Klymenko <anatoliy.klymenko@amd.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Mike Looijmans <mike.looijmans@topic.nl>
Subject: Re: [PATCH v2 0/4] drm: zynqmp: Make the video plane primary
Date: Thu, 22 Jan 2026 15:48:39 +0200	[thread overview]
Message-ID: <53e73b84-e2e1-42d7-afc9-f9bc04e5db37@ideasonboard.com> (raw)
In-Reply-To: <20260106164247.472544-1-sean.anderson@linux.dev>

Hi,

On 06/01/2026 18:42, Sean Anderson wrote:
> The graphics plane does not support XRGB8888, which is the default mode
> X uses for 24-bit color. Because of this, X must be set to use 16-bit
> color, which has a measurable performance penalty. Make the video plane
> the primary plane as it natively supports XRGB8888. An alternative
> approach to add XRGB8888 to the graphics plane is discussed in [1], as
> well as in patch 2.
> 
> [1] https://lore.kernel.org/dri-devel/20250627145058.6880-1-mike.looijmans@topic.nl/
> 
> Changes in v2:
> - Allow specifying blend mode default
> - Advertise coverage instead of premulti, since that's what the hardware
>   supports.
> - Set default blend mode to none since that's what the default was
>   before this series.
> 
> Sean Anderson (4):
>   drm/drm_blend: Allow specifying blend mode default
>   drm: zynqmp: Check property creation status
>   drm: zynqmp: Make the video plane primary
>   drm: zynqmp: Add blend mode property to graphics plane
> 
>  drivers/gpu/drm/drm_blend.c       | 22 ++++++-------
>  drivers/gpu/drm/xlnx/zynqmp_kms.c | 53 +++++++++++++++++++++++++------
>  include/drm/drm_blend.h           | 26 +++++++++++++--
>  3 files changed, 78 insertions(+), 23 deletions(-)
> 

I think the series looks fine, but there's still the main question of
whether making video plane primary is the best choice. I'll summarize my
understanding of our two options here:

1) Make video plane primary plane, and thus graphics plane an overlay
plane. The downside here is that, at least to me, the plane types feel
like they are the wrong way around, and any existing code that depends
on the plane type may start to fail. That said, the plane type is
supposed to be a legacy thing, and a modern userspace should just look
at the plane properties to decide how to use them (which raises the
question of why is X/Weston even failing).

2) Add XRGB format to the graphics plane. This should work fine too, as
long as we make sure using XRGB with per-pixel alpha will fail (i.e.
only global alpha supported with XRGB). Afaics that could be done with a
check in atomic_check.

Does anyone have strong arguments for either of these options?

 Tomi

      parent reply	other threads:[~2026-01-22 13:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-06 16:42 Sean Anderson
2026-01-06 16:42 ` [PATCH v2 1/4] drm/drm_blend: Allow specifying blend mode default Sean Anderson
2026-01-06 16:42 ` [PATCH v2 2/4] drm: zynqmp: Check property creation status Sean Anderson
2026-01-06 16:42 ` [PATCH v2 3/4] drm: zynqmp: Make the video plane primary Sean Anderson
2026-01-06 16:42 ` [PATCH v2 4/4] drm: zynqmp: Add blend mode property to graphics plane Sean Anderson
2026-01-22 13:48 ` Tomi Valkeinen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53e73b84-e2e1-42d7-afc9-f9bc04e5db37@ideasonboard.com \
    --to=tomi.valkeinen@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=anatoliy.klymenko@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=michal.simek@amd.com \
    --cc=mike.looijmans@topic.nl \
    --cc=mripard@kernel.org \
    --cc=sean.anderson@linux.dev \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®