dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Andy Furniss <adf.lists@gmail.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list
Date: Tue, 18 Jun 2013 11:36:50 +0100	[thread overview]
Message-ID: <51C03842.3060307@gmail.com> (raw)
In-Reply-To: <20130618103033.GE5004@intel.com>

Ville Syrjälä wrote:
> On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote:
>> ville.syrjala@linux.intel.com wrote:
>>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>
>>> Having both modes can be beneficial for video playback cases. If you can
>>> match the video framerate exactly, and the audio and video clocks come
>>> from the same source, you should be able to avoid dropped/repeated
>>> frames without expensive operations such as resampling the audio to
>>> match video output rate.
>>>
>>> Rather than add both variants based on the CEA extension short video
>>> descriptors in do_cea_modes(), add only one variant there. Once all
>>> the EDID has been fully probed, do a loop over the entire probed mode
>>> list, during which we add the other variants for all modes that match
>>> CEA modes. This allows us to match modes that didn't come via the CEA
>>> short video descriptors. For example one Samsung TV here doesn't have
>>> the 640x480-60 mode as a SVD, but instead it's specified via a detailed
>>> timing descriptor.
>>>
>>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>> ---
>>> A few people requested this. Originally I was a bit opposed to it, but
>>> when I thought about it a bit more I figured if the audio and video
>>> clocks come from the same source (or happen to be close enough w/o
>>> significant drift), this could provide a better A/V sync w/o resampling
>>> tricks.
>>
>> I see this has gone in now, one thing I notice is that xorg/apps/xrandr
>> only prints Hz to 1dp so you can't see which mode is which for the 24p
>> and 30i cases.
>>
>> Maybe someone reading has commit access for xorg?
>
> Not sure if you noticed but I posted some relevant xrandr patches to
> xorg-devel. Unfortunately I got no response, and I've been too lazy
> to figure out who I need to pester.
>

Ahh, sorry I didn't see those, I just has a look at the current code to 
check it was still the same.

      reply	other threads:[~2013-06-18 10:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-31 12:23 [PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list ville.syrjala
2013-05-31 15:43 ` Daniel Vetter
2013-05-31 18:56   ` Andy Furniss
2013-05-31 19:46     ` Daniel Vetter
2013-06-01  9:13       ` Andy Furniss
2013-06-23 17:53         ` Alex Deucher
2013-06-23 20:01           ` Andy Furniss
2013-06-18 10:10 ` Andy Furniss
2013-06-18 10:30   ` Ville Syrjälä
2013-06-18 10:36     ` Andy Furniss [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=51C03842.3060307@gmail.com \
    --to=adf.lists@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --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;
as well as URLs for NNTP newsgroup(s).