On 01/27/2015 06:43 PM, Chris Wilson wrote:
On Tue, Jan 27, 2015 at 02:09:21PM +0100, Daniel Vetter wrote:
On Tue, Jan 27, 2015 at 02:11:18PM +0530, Shobhit Kumar wrote:
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
Hm, is that a real use-case shipping to customers or just a hack for
development? In the later case I think we can just hardcode the edid for
edp ...
Also how is this different from userspace creating a 800x600 mode and
giving it to the kernel which then uses the pfitter to display it at
native resolution. That is how it works today. This should also be
possible with a video= parameter...
Its different in a way, that user space changes will need a new system
build which is not allowed as per the requirements that we had and hence
no hard coding in code anywhere as well.
As I said earlier also that this case might not be useful in general and
I am okay to remove this callback.
Regards
Shobhit
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
