dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Sharma, Shashank" <shashank.sharma@intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org,
	Emil Velikov <emil.l.velikov@gmail.com>,
	dri-devel@lists.freedesktop.org,
	Nautiyal Ankit <ankit.k.nautiyal@intel.com>
Subject: Re: [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes
Date: Fri, 17 Nov 2017 13:38:57 +0200	[thread overview]
Message-ID: <20171117113857.GD10981@intel.com> (raw)
In-Reply-To: <93fa0fa9-34f2-1878-3ff5-310f0d1a35e9@intel.com>

On Fri, Nov 17, 2017 at 08:53:54AM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/16/2017 9:56 PM, Ville Syrjälä wrote:
> > On Thu, Nov 16, 2017 at 08:31:36PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/13/2017 10:34 PM, Ville Syrjala wrote:
> >>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>
> >>> If the user mode would specify an aspect ratio other than 4:3 or 16:9
> >>> we now silently ignore it. Maybe a better apporoach is to return an
> >>> error? Let's try that.
> >>>
> >>> Also we must be careful that we don't try to send illegal picture
> >>> aspect in the infoframe as it's only capable of signalling none,
> >>> 4:3, and 16:9. Currently we're sending these bogus infoframes
> >>> whenever the cea mode specifies some other aspect ratio.
> >>>
> >>> Cc: Shashank Sharma <shashank.sharma@intel.com>
> >>> Cc: Sean Paul <seanpaul@chromium.org>
> >>> Cc: Jose Abreu <Jose.Abreu@synopsys.com>
> >>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>> Cc: Emil Velikov <emil.l.velikov@gmail.com>
> >>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>> ---
> >>>    drivers/gpu/drm/drm_edid.c | 23 +++++++++++++++++------
> >>>    1 file changed, 17 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >>> index 00aa98f3e55d..bafb3ee4ea97 100644
> >>> --- a/drivers/gpu/drm/drm_edid.c
> >>> +++ b/drivers/gpu/drm/drm_edid.c
> >>> @@ -4786,6 +4786,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
> >>>    					 const struct drm_display_mode *mode,
> >>>    					 bool is_hdmi2_sink)
> >>>    {
> >>> +	enum hdmi_picture_aspect picture_aspect;
> >>>    	int err;
> >>>    
> >>>    	if (!frame || !mode)
> >>> @@ -4828,13 +4829,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
> >>>    	 * Populate picture aspect ratio from either
> >>>    	 * user input (if specified) or from the CEA mode list.
> >>>    	 */
> >>> -	if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
> >>> -		mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
> >>> -		frame->picture_aspect = mode->picture_aspect_ratio;
> >>> -	else if (frame->video_code > 0)
> >>> -		frame->picture_aspect = drm_get_cea_aspect_ratio(
> >>> -						frame->video_code);
> >>> +	picture_aspect = mode->picture_aspect_ratio;
> >>> +	if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
> >>> +		picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
> >> This is slightly going in the loop.
> >> - During the modeset the driver cant specify the aspect ratio
> >> information, as DRM layer lacks this support.
> >> - So we fill the VIC field, by comparing the mode with the
> >> DRM_CEA_MODES[] list. This will pick the first mode
> >>     available in the list (regardless of its aspect ratio), and fill the
> >> VIC, as we don't consider aspect ratio while comparing timings.
> >> - Again, now while sending the aspect ratio, we are picking up the VIC,
> >> which may not be correct.
> >>
> >> So if we have 720x480(4:3) and 720x480(16:9) in the list, as 4:3 is
> >> first in list, we will always pick 4:3 aspect ratio.
> > Yes. The user didn't care about the aspect ratio (or rather couldn't
> > specify one) so we just pick one. Which is exactly what we've been
> > doing ever since we started sending the VIC in the infoframe.
> Correct, and we are hoping that this should be better (if not fixed) 
> with the aspect ratio support
> patches + DRM cap. If the userspace doesn't set the cap, then anyways 
> there is no aspect ratio
> field available, and VIC would be always 0, as this becomes a Non CEA mode.
> 
> Or do you think it would be a better idea to send some VIC instead of No 
> VIC, when userspace doesn't
> set the DRM cap for aspect ratio ?

Yes. That's the current behaviour.

IIRC some crappy amplifiers etc. with HDMI passthrough don't even work
correctly unless VIC is specified. Hence we do want to send it whenever
possible.

> 
> - Shashank
> >> - Shashank
> >>>    
> >>> +	/*
> >>> +	 * The infoframe can't convey anything but none, 4:3
> >>> +	 * and 16:9, so if the user has asked for anything else
> >>> +	 * we can only satisfy it by specifying the right VIC.
> >>> +	 */
> >>> +	if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
> >>> +		if (picture_aspect !=
> >>> +		    drm_get_cea_aspect_ratio(frame->video_code))
> >>> +			return -EINVAL;
> >>> +		picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> >>> +	}
> >>> +
> >>> +	frame->picture_aspect = picture_aspect;
> >>>    	frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
> >>>    	frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
> >>>    

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-11-17 11:38 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 17:04 [PATCH 00/10] drm/edid: Infoframe cleanups and fixes Ville Syrjala
2017-11-13 17:04 ` [PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes Ville Syrjala
2017-11-16 14:36   ` Sharma, Shashank
2017-11-16 16:16     ` Ville Syrjälä
2017-11-17  3:05       ` Sharma, Shashank
2017-11-13 17:04 ` [PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D Ville Syrjala
2017-11-16 14:40   ` Sharma, Shashank
2017-11-16 16:21     ` Ville Syrjälä
2017-11-17  3:10       ` Sharma, Shashank
2017-11-22 18:28         ` Ville Syrjälä
2017-11-13 17:04 ` [PATCH 03/10] drm/modes: Introduce drm_mode_match() Ville Syrjala
2017-11-13 17:04 ` [PATCH 04/10] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy Ville Syrjala
2017-11-13 17:04 ` [PATCH 05/10] drm/edid: Fix up edid_cea_modes[] formatting Ville Syrjala
2017-11-13 17:04 ` [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling Ville Syrjala
2017-11-13 18:13   ` Jose Abreu
2017-11-13 18:53     ` Ville Syrjälä
2017-11-16 14:51   ` Sharma, Shashank
2017-11-16 16:23     ` Ville Syrjälä
2017-11-17  3:19       ` Sharma, Shashank
2017-11-17 11:35         ` Ville Syrjälä
2017-11-17 12:20           ` Sharma, Shashank
2017-11-17 12:49             ` Ville Syrjälä
2017-11-24  8:56               ` Sharma, Shashank
2017-11-24 13:22                 ` Ville Syrjälä
2017-11-13 17:04 ` [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes Ville Syrjala
2017-11-13 18:30   ` Jose Abreu
2017-11-13 19:00     ` Ville Syrjälä
2017-11-16 15:01   ` Sharma, Shashank
2017-11-16 16:26     ` Ville Syrjälä
2017-11-17  3:23       ` Sharma, Shashank
2017-11-17 11:38         ` Ville Syrjälä [this message]
2017-11-24  8:55           ` Sharma, Shashank
2017-11-13 17:04 ` [PATCH 08/10] video/hdmi: Reject illegal picture aspect ratios Ville Syrjala
2017-11-13 18:33   ` Jose Abreu
2017-11-13 17:04 ` [PATCH 09/10] video/hdmi: Constify 'buffer' to the unpack functions Ville Syrjala
2017-11-13 17:04 ` [PATCH 10/10] video/hdmi: Pass buffer size to infoframe " Ville Syrjala
2017-11-20 13:36   ` Hans Verkuil
2017-11-20 14:55     ` Ville Syrjälä

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=20171117113857.GD10981@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=Jose.Abreu@synopsys.com \
    --cc=ankit.k.nautiyal@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=shashank.sharma@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;
as well as URLs for NNTP newsgroup(s).