On Tue, Nov 13, 2012 at 01:33:37PM +0000, Chris Wilson wrote: > On Tue, 13 Nov 2012 15:15:55 +0200, Ville Syrj?l? <ville.syrjala at linux.intel.com> wrote: > > On Tue, Nov 13, 2012 at 12:48:11PM +0000, Chris Wilson wrote: > > > On Tue, 13 Nov 2012 14:42:36 +0200, Ville Syrj?l? <ville.syrjala at linux.intel.com> wrote: > > > > On Tue, Nov 13, 2012 at 12:15:10PM +0000, Chris Wilson wrote: > > > > > In the slightly unusual case where the pipe is programmed to the same > > > > > modeline, but the framebuffer is a new size, we need to resetup the > > > > > panel fitter as appropriate and this requires a full modeset. This can > > > > > only occur currently as part of the BIOS takeover where there are > > > > > slightly different semantics governing how the panel fitter and > > > > > framebuffer is programmed relative to the modeline. > > > > > > > > Hmm. I don't get it. Why would the framebuffer size affect the panel > > > > fitter configuration? > > > > > > The BIOS uses fb->(width,height) to program PIPESRC, we use > > > mode->[hv]display. The BIOS's semantics makes more sense > > > > I don't think so. That would make panning impossible. > > True. The issue really appears that we recreate the mode using the crtc > values and assume that the reverse mapping works. Further issues arise > if we want to recover any offsets in a multiple output configuration. I > will just have to double-check that the BIOS configuration matches our > usage. > > And I whole-heartedly agree with separating the display mode from the > plane configuration, I guess you have something planned along those > lines already ;-) Well, I have some ideas in my head, but so far I haven't found the time to do the work. Originally I was thinking that I'd try to combine this work with the atomic mode setting, but I fear that if I keep piling on more changes, it'll never be ready. -- Ville Syrj?l? Intel OTC
