On Sat, Jan 28, 2012 at 11:49, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > We have a pretty decent confusion about vertical timings of interlaced > modes. Peter Ross has written a patch that makes interlace modes work > on a lot more platforms/output combinations by doubling the vertical > timings. > > The issue with that patch is that core drm _does_ support specifying > whether we want these vertical timings in fields or frames, we just > haven't managed to consistently use this facility. The relavant > function is drm_mode_set_crtcinfo, which fills in the crtc timing > information. > > The first thing to note is that the drm core keeps interlaced modes in > frames, but displays modelines in fields. So when the crtc modeset > helper copies over the mode into adjusted_mode it will already contain > vertical timings in half-frames. The result is that the fixup code in > intel_crtc_mode_fixup doesn't actually do anything (in most cases at > least). > > Now gen3+ natively supports interlaced modes and wants the vertical > timings in frames. Which is what sdvo already fixes up, at least under > some conditions. > > There are a few other place that demand vertical timings in fields > but never actually deal with interlaced modes, so use frame timings > for consistency, too. These are: > - lvds panel, > - dvo encoders - dvo is the only way gen2 could support interlaced > mode, but currently we don't support any encoders that do. > - tv out - despite that the tv dac sends out an interlaced signal it > expects a progressive mode pipe configuration. > All these encoders enforce progressive modes by resetting > interlace_allowed. > > Hence we always want crtc vertical timings in frames. Enforce this in > our crtc mode_fixup function and rip out any redudant timing > computations from the encoders' mode_fixup function. > > v2-4: Adjust the vertical timings a bit. > > v5: Split out the 'subtract-one for interlaced' fixes. > > v6: Clarify issues around tv-out and gen2. > > Signed-Off-by: Daniel Vetter <daniel.vetter at ffwll.ch> > Reviewed-by: Eugeni Dodonov <eugeni.dodonov at intel.com> -- Eugeni Dodonov <http://eugeni.dodonov.net/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120129/625ff540/attachment.htm>