On Fri, May 31, 2013 at 8:56 PM, Andy Furniss <adf.lists@xxxxxxxxx> wrote: > Daniel Vetter wrote: >> >> On Fri, May 31, 2013 at 03:23:41PM +0300, ville.syrjala@xxxxxxxxxxxxxxx >> wrote: >>> >>> From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> >>> >>> 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@xxxxxxxxxxxxxxx> >>> --- >>> 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. >> >> >> Yeah, I think this should be useful for a bunch of people. I've recently >> chatted with a few xbmc folks on #irc and one thing they've requested is >> mode fine-tuning. For DP we should have plenty of precision, but for HDMI >> we'd need to (slightly) frob the vtotal ever so often to compensate. With >> some runtime-tuning a la npt we should have perfect a/v sync without any >> audio resampling. > > > Apologies, for jumping in here, but assuming I haven't missed anything > you've done already: do you have any plans for supporting CEA interlaced > modes? > > That's assuming they actually need any more support - I only know that they > are slightly wrong for me testing with radeon + my TV - are they tested and > known to work / not work on intel hw? > > The symptom I get is not instantly obvious - the second half of the bottom > line gets rendered and repeated as the top line. > > For me the reason that proper support could in theory be useful, is that > were there in future a way to sync up properly, my TV will do a nice "free" > deinterlace. Even on a fast quad core PC doing one as good on cpu is not > possible for HD 50i. Interlaced modes are supported on all intel platforms (except i8xx, hw can't do it there) and we have full support for CEA modes. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
