On Fri, Jan 23, 2015 at 03:14:41PM +0530, Shobhit Kumar wrote: > On 01/22/2015 06:53 PM, Jani Nikula wrote: > >On Thu, 22 Jan 2015, Shobhit Kumar <shobhit.kumar@xxxxxxxxxxxxxxx> wrote: > >>There had been a instance where we had to drive different resolution > >>(lower) than the native one. Also in VBT there is a field to make this > >>generic at least from driver perspective to give the needed target > >>resolution. In case target resolution is same as native, nothing gets > >>changed, else mode_fixup function adjusts the mode accordingly keeping > >>timing as same and enabling scalar. Might not be useful in general, but > >>did find a use internally. > > > >Can we just have the driver return the desired mode from .get_modes in > >that case? > > Okay, I think I did not explain correctly. Get modes is modified to give the > needed target mode only so that userspace creates buffer of the needed > resolution, but in fixup which is called at modeset, we correct the > adjusted_mode back to have native resolutions so that modeset is correctly > done. if we do not do like this, during modeset resolutions will be wrong as > per the timings. I'm confused. Can you please give an example in real numbers about the different resolution and how it's all fixed up in hw? E.g. 800x600 framebuffer -> pfit -> 1024x756 panel, get_modes gives 800x600, adjusted mode corrects to 1024x756. And please mention what vbt has to do in all this too. I think I need an example since I can't figure out what exactly your describing ... Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
