On 01/23/2015 08:52 PM, Daniel Vetter wrote:
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
We had a 19x12 DSI panel which we needed to drive at 12x8 due to lack of
12x8 panels for testing purposes. So get_modes returned 12x8 so that
user space gave 12x8 FBs, and internally in mode_fixup we adjusted
correctly for the 19x12 panel timings and enabled pfit
mention what vbt has to do in all this too.
VBT allows to avoid panel specific and build specific hard coding in the
code, which should work as is for normal 19x12 usage as well. Block #42
panel xres and yres are used to indicate this lower needed resolution
when different from panel_fixed_mode.
Regards
Shobhit
I think I need an example since I can't figure out what exactly your
describing ...
Thanks, Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
