From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Eric Anholt <eric@anholt.net>
Cc: Jani Nikula <jani.nikula@intel.com>,
intel-gfx@lists.freedesktop.org, Neil Kownacki <njkkow@gmail.com>,
stable@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
Date: Wed, 8 Nov 2017 22:45:23 +0200 [thread overview]
Message-ID: <20171108204523.GJ10981@intel.com> (raw)
In-Reply-To: <87k1z0bk4n.fsf@anholt.net>
On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
> Ville Syrjala <ville.syrjala@linux.intel.com> writes:
>
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Apparently some sinks look at the YQ bits even when receiving RGB,
> > and they get somehow confused when they see a non-zero YQ value.
> > So we can't just blindly follow CEA-861-F and set YQ to match the
> > RGB range.
> >
> > Unfortunately there is no good way to tell whether the sink
> > designer claims to have read CEA-861-F. The CEA extension block
> > revision number has generally been stuck at 3 since forever,
> > and even a very recently manufactured sink might be based on
> > an old design so the manufacturing date doesn't seem like
> > something we can use. In lieu of better information let's
> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
> >
> > The alternative would of course be to always set YQ=0. And if
> > we ever encounter a HDMI 2.0+ sink with this bug that's what
> > we'll probably have to do.
>
> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4
> source?
As long as you stick to < 340 MHz modes you shouldn't have to do
anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.
Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up
to bridges/encoders to filter out most things that aren't supported?
>
> That said, as far as vc4, this patch is
>
> Acked-by: Eric Anholt <eric@anholt.net>
Ta.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Eric Anholt <eric@anholt.net>
Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
stable@vger.kernel.org, Jani Nikula <jani.nikula@intel.com>,
Neil Kownacki <njkkow@gmail.com>
Subject: Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
Date: Wed, 8 Nov 2017 22:45:23 +0200 [thread overview]
Message-ID: <20171108204523.GJ10981@intel.com> (raw)
In-Reply-To: <87k1z0bk4n.fsf@anholt.net>
On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
> Ville Syrjala <ville.syrjala@linux.intel.com> writes:
>
> > From: Ville Syrj�l� <ville.syrjala@linux.intel.com>
> >
> > Apparently some sinks look at the YQ bits even when receiving RGB,
> > and they get somehow confused when they see a non-zero YQ value.
> > So we can't just blindly follow CEA-861-F and set YQ to match the
> > RGB range.
> >
> > Unfortunately there is no good way to tell whether the sink
> > designer claims to have read CEA-861-F. The CEA extension block
> > revision number has generally been stuck at 3 since forever,
> > and even a very recently manufactured sink might be based on
> > an old design so the manufacturing date doesn't seem like
> > something we can use. In lieu of better information let's
> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
> >
> > The alternative would of course be to always set YQ=0. And if
> > we ever encounter a HDMI 2.0+ sink with this bug that's what
> > we'll probably have to do.
>
> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4
> source?
As long as you stick to < 340 MHz modes you shouldn't have to do
anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.
Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up
to bridges/encoders to filter out most things that aren't supported?
>
> That said, as far as vc4, this patch is
>
> Acked-by: Eric Anholt <eric@anholt.net>
Ta.
--
Ville Syrj�l�
Intel OTC
next prev parent reply other threads:[~2017-11-08 20:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-08 15:25 [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks Ville Syrjala
2017-11-08 15:49 ` ✗ Fi.CI.BAT: failure for " Patchwork
2017-11-08 19:42 ` ✓ Fi.CI.BAT: success " Patchwork
2017-11-08 20:17 ` [PATCH] " Eric Anholt
2017-11-08 20:45 ` Ville Syrjälä [this message]
2017-11-08 20:45 ` Ville Syrjälä
2017-11-08 22:21 ` Eric Anholt
2017-11-09 8:26 ` Daniel Vetter
2017-11-09 8:26 ` Daniel Vetter
2017-11-09 18:16 ` Eric Anholt
2017-11-09 18:16 ` Eric Anholt
2017-11-14 23:38 ` neil k
2017-11-15 15:30 ` Ville Syrjälä
2017-11-15 15:30 ` Ville Syrjälä
2017-11-08 21:19 ` ✓ Fi.CI.IGT: success for " Patchwork
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=20171108204523.GJ10981@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=eric@anholt.net \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=njkkow@gmail.com \
--cc=stable@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.