From: Daniel Vetter <daniel@ffwll.ch>
To: Yussuf Khalil <dev@pp3345.net>
Cc: Daniel Vetter <daniel@ffwll.ch>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@linux.ie>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] drm/modes: Indicate CEA-861 CE modes to user-space
Date: Fri, 17 Apr 2020 16:57:55 +0200 [thread overview]
Message-ID: <20200417145755.GL3456981@phenom.ffwll.local> (raw)
In-Reply-To: <ac01c47a3b2c2ac73368882fb90eb6ee4e07fd04.camel@pp3345.net>
On Thu, Apr 16, 2020 at 03:51:36PM +0200, Yussuf Khalil wrote:
> On Tue, 2020-04-14 at 14:41 +0200, Daniel Vetter wrote:
> > On Mon, Apr 13, 2020 at 11:40:22PM +0200, Yussuf Khalil wrote:
> > > Add a new flag to mark modes that are considered a CE mode
> > > according to the
> > > CEA-861 specification. Modes without this flag are implicitly
> > > considered to
> > > be IT modes.
> > >
> > > User-space applications may use this flag to determine possible
> > > implications of using a CE mode (e.g., limited RGB range).
> > >
> > > There is no use for this flag inside the kernel, so we set it only
> > > when
> > > communicating a mode to user-space.
> > >
> > > Signed-off-by: Yussuf Khalil <dev@pp3345.net>
> >
> > Do we have userspace for this?
> >
> > If we go with the existing quant range property you don't need new
> > userspace for the property itself. But this flag here is new uapi, so
> > needs userspace per
> >
> > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> >
> > Also since this standardizes kms uapi, we need testcases per
> >
> > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#testing-requirements-for-userspace-api
> >
> > Cheers, Daniel
> >
> > > ---
> > > drivers/gpu/drm/drm_modes.c | 14 ++++++++++++++
> > > include/uapi/drm/drm_mode.h | 2 ++
> > > 2 files changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_modes.c
> > > b/drivers/gpu/drm/drm_modes.c
> > > index d4d64518e11b..0d8a032f437d 100644
> > > --- a/drivers/gpu/drm/drm_modes.c
> > > +++ b/drivers/gpu/drm/drm_modes.c
> > > @@ -1973,6 +1973,14 @@ void drm_mode_convert_to_umode(struct
> > > drm_mode_modeinfo *out,
> > > break;
> > > }
> > >
> > > + if (drm_match_cea_mode(in) > 1) {
> > > + /*
> > > + * All modes in CTA-861-G Table 1 are CE modes, except
> > > 640x480p
> > > + * (VIC 1).
> > > + */
> > > + out->flags |= DRM_MODE_FLAG_CEA_861_CE_MODE;
> > > + }
> > > +
> > > strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> > > out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> > > }
> > > @@ -2045,6 +2053,12 @@ int drm_mode_convert_umode(struct drm_device
> > > *dev,
> > > return -EINVAL;
> > > }
> > >
> > > + /*
> > > + * The CEA-861 CE mode flag is purely informational and
> > > intended for
> > > + * userspace only.
> > > + */
> > > + out->flags &= ~DRM_MODE_FLAG_CEA_861_CE_MODE;
> > > +
> > > out->status = drm_mode_validate_driver(dev, out);
> > > if (out->status != MODE_OK)
> > > return -EINVAL;
> > > diff --git a/include/uapi/drm/drm_mode.h
> > > b/include/uapi/drm/drm_mode.h
> > > index 735c8cfdaaa1..5e78b350b2e2 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -124,6 +124,8 @@ extern "C" {
> > > #define DRM_MODE_FLAG_PIC_AR_256_135 \
> > > (DRM_MODE_PICTURE_ASPECT_256_135<<19)
> > >
> > > +#define DRM_MODE_FLAG_CEA_861_CE_MODE (1<<23)
> > > +
> > > #define DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
> > > DRM_MODE_FLAG_NHSYNC | \
> > > DRM_MODE_FLAG_PVSYNC | \
> > > --
> > > 2.26.0
> > >
>
> Sorry, I wasn't aware DRM had these additional requirements. I do have a user-
> space implementation in mutter and gnome-control-center that makes use of the
> new property and this flag on my local machine. I'll try to propose the branch
> upstream before sending in the next revision of this patchset.
>
> Do I understand it correctly that this will require test cases for both the
> property itself and the new flag? I'll write a patch for IGT then.
Yup. We even have some edid injection stuff so you can (for some value of
"can") test this on systems without such a monitor. That would obviously
be the gold standard for this, so that CI systems can make sure we don't
break any of this in the driver side.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2020-04-17 14:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-13 21:40 [PATCH 0/5] Improving the situation regarding RGB quantization ranges Yussuf Khalil
2020-04-13 21:40 ` [PATCH 1/5] drm/modes: Indicate CEA-861 CE modes to user-space Yussuf Khalil
2020-04-14 12:41 ` Daniel Vetter
2020-04-16 13:51 ` Yussuf Khalil
2020-04-17 14:57 ` Daniel Vetter [this message]
2020-04-13 21:40 ` [PATCH 2/5] drm: Add "RGB quantization range" connector property Yussuf Khalil
2020-04-13 22:32 ` Simon Ser
2020-04-13 21:40 ` [PATCH 3/5] drm: Add drm_connector_state_select_rgb_quantization_range() helper Yussuf Khalil
2020-04-13 21:40 ` [PATCH 4/5] drm/atomic-helper: Consider RGB quantization changes to be mode changes Yussuf Khalil
2020-04-13 21:40 ` [PATCH 5/5] drm/i915: Replace "Broadcast RGB" with "RGB quantization range" property Yussuf Khalil
2020-04-13 22:35 ` Simon Ser
2020-04-14 11:17 ` Jani Nikula
2020-04-14 11:21 ` Jani Nikula
2020-04-14 12:34 ` Daniel Vetter
2020-04-14 21:11 ` Yussuf Khalil
2020-04-15 7:33 ` Jani Nikula
2020-04-15 11:13 ` Daniel Vetter
2020-04-16 13:44 ` Yussuf Khalil
2020-04-17 14:59 ` Daniel Vetter
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=20200417145755.GL3456981@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=dev@pp3345.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).