On Mon, Mar 09, 2015 at 05:20:39PM +0200, Ville Syrjälä wrote: > On Mon, Mar 09, 2015 at 09:46:27AM +0100, Daniel Vetter wrote: > > On Mon, Mar 09, 2015 at 08:33:27AM +0530, sonika wrote: > > > > > > On Thursday 05 March 2015 06:24 PM, Daniel Vetter wrote: > > > >On Thu, Mar 05, 2015 at 02:51:26PM +0530, Sonika Jindal wrote: > > > >>Signed-off-by: Sonika Jindal <sonika.jindal@xxxxxxxxx> > > > >Imo this needs a little more commit message, and more important it needs > > > >igt test coverage. Best approach there is probably to take the plane test > > > >we have already and extend it to the primary plane. > > > >-Daniel > > > This is just to take care of the case when the size of the fb is smaller > > > than the crtc. > > > I have extended the rotation test (yet to be posted), to create a smaller > > > primary plane fb to be used for 90/270 rotation. > > > > > > Since we still set position to 0 for primary plane, I did not add any test > > > case for positioning of primary plane. > > > That can be added as a separate activity when positioning support is added. > > > Right now this is just to allow smaller fb for primary plane which is > > > possible with universal planes gen >=9. > > > > Through universal planes it's already possible to position any plane > > anywhere, and this code is all that makes sure this doesn't happen for the > > primary plane. Since you've just changed that I think this needs a > > testcase in igt. > > > > Or maybe I missed something and it's indeed not yet possible to do this? > > We're not ready to enable this just yet. First we need to change all the > plane code to use the correct derived state (eg. clipped coordinates as > opposed to the user requested ones). And to do that we must make sure > the derived state is up to date at .crtc_enable() time. > > This was one of the things I had on mind when Gustavo was reworking the > primary/cursor plane code, but then Gustavo was pulled away and this > task fell through the cracks. I've now cooked up something that should > make this happen, but I haven't tested it yet. I'll give it a spin today > and post the patch if all goes well... Hm, is there a lot of derived state around (restricting just to skl+) once we have the wm code converted over to always look at plane_state structs instead of the add-hoc wm struct we currently use? -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
