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. > and is > ultimately more flexible - especially if we do end up exposing more > information to userspace to solve the under/overscan issue using the > panel fitter. I've been known to bitch about this issue also. I'd like to have the mode be strictly the display mode. Then we'd need another way to configure PIPESRC (some kind of CRTC dimensions properties would do it). And then we also need to expose the primary plane as a drm_plane. Those measures would allow full control over the pipe, rather than relying on some magic connector properties that may or may not do what you want. Doing all that seems straightforward enough, but I suspect trying to maintain some kind of compatibility with the current mess is going to be the hard part. -- Ville Syrj?l? Intel OTC
