ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? <ville.syrjala at 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 at 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?