From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Laurent Pinchart" <laurent.pinchart+renesas@ideasonboard.com>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Neil Armstrong" <narmstrong@baylibre.com>,
"Maxime Ripard" <maxime.ripard@free-electrons.com>,
dri-devel@lists.freedesktop.org,
"Paul Kocialkowski" <paul.kocialkowski@bootlin.com>,
"Thomas Hellstrom" <thellstrom@vmware.com>,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
"Ben Skeggs" <bskeggs@redhat.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
linux-tegra@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes
Date: Fri, 6 Jul 2018 16:40:27 +0100 [thread overview]
Message-ID: <20180706154027.GB17271@n2100.armlinux.org.uk> (raw)
In-Reply-To: <2295190.xHWjP7Ltc3@dimapc>
On Fri, Jul 06, 2018 at 05:58:50PM +0300, Dmitry Osipenko wrote:
> On Friday, 6 July 2018 17:10:10 MSK Ville Syrjälä wrote:
> > IIRC my earlier idea was to have different colorkey modes for the
> > min+max and value+mask modes. That way userspace might actually have
> > some chance of figuring out which bits of state actually do something.
> > Although for Intel hw I think the general rule is that min+max for YUV,
> > value+mask for RGB, so it's still not 100% clear what to pick if the
> > plane supports both.
> >
> > I guess one alternative would be to have min+max only, and the driver
> > would reject 'min != max' if it only uses a single value?
> >
>
> You should pick both and reject unsupported property values based on the
> planes framebuffer format. So it will be possible to set unsupported values
> while plane is disabled because it doesn't have an associated framebuffer and
> then atomic check will fail to enable plane if property values are invalid for
> the given format.
The colorkey which is attached to a plane 'A' is not applied to plane
'A', so the format of plane 'A' is not relevant. The colorkey is
applied to some other plane which will be below this plane in terms
of the plane blending operation.
What if you have several planes below plane 'A' with differing
framebuffer formats - maybe an ARGB8888 plane and a ARGB1555 plane -
do you decide to limit the colorkey to 8bits per channel, or to
ARGB1555 format?
The answer is, of course, hardware dependent - generic code can't
know the details of the colorkey implementation, which could be one
of:
lower plane data -> expand to 8bpc -> match ARGB8888 colorkey
lower plane data -> match ARGB8888 reduced to plane compatible colorkey
which will give different results depending on the format of the
lower plane data.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
next prev parent reply other threads:[~2018-07-06 15:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-03 22:00 [RFC PATCH v3 0/2] drm: Add generic colorkey plane properties Dmitry Osipenko
2018-06-03 22:00 ` [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes Dmitry Osipenko
2018-07-06 12:11 ` Maarten Lankhorst
2018-07-06 12:23 ` Ville Syrjälä
2018-07-06 13:05 ` Dmitry Osipenko
2018-07-06 14:10 ` Ville Syrjälä
2018-07-06 14:58 ` Maarten Lankhorst
2018-07-06 14:58 ` Dmitry Osipenko
2018-07-06 15:40 ` Russell King - ARM Linux [this message]
2018-07-06 16:32 ` Ville Syrjälä
2018-07-06 16:33 ` Dmitry Osipenko
2018-07-06 17:01 ` Russell King - ARM Linux
2018-07-06 19:48 ` Dmitry Osipenko
2018-06-03 22:00 ` [RFC PATCH v3 2/2] drm/tegra: plane: Implement generic colorkey property for older Tegra's Dmitry Osipenko
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=20180706154027.GB17271@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=bskeggs@redhat.com \
--cc=digetx@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=maxime.ripard@free-electrons.com \
--cc=narmstrong@baylibre.com \
--cc=paul.kocialkowski@bootlin.com \
--cc=rodrigo.vivi@intel.com \
--cc=thellstrom@vmware.com \
--cc=thierry.reding@gmail.com \
--cc=ville.syrjala@linux.intel.com \
/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®