On Fri, Apr 11, 2014 at 11:22:39AM +0200, Daniel Vetter wrote: > On Thu, Apr 10, 2014 at 05:26:25PM -0700, Matt Roper wrote: > > Add a simple test to exercise universal plane support. > > > > Signed-off-by: Matt Roper <matthew.d.roper@xxxxxxxxx> > > Looks like a good functional test, but I think we need to add a bit more > api nastiness still. So no functional tests with CRCs, but just tests to > make sure the kernel doesn't fall over. > > - primary plane set_plane calls vs. legacy setcrtc primary plane updates. > We'll very likely have mixed userspace (e.g. boot splash vs. display > manager). E.g. disable primary plane (but keep everything working), then > setCrtc a new plane framebuffer. > > - primary plane vs. other ioctls. Might be easier to extend existing tests > for this. E.g. doing a pageflip ioctl if the primary plane is off > (might need to decide what we really want to do and if we decide that it > should enable the primary plane then we need a CRC based test to make > sure that the transition is perfect). > > Or primary plane changes vs. dpms and suspend/resume. For those > functional checks based on CRC would be good to make sure we properly > restore everything. > > - Maybe exercise some of the checks in the primary plane helper to make > sure they work. In the future we'll probably lift those limitations (not > on current hw afaik though), but then we can adjust those tests to skip > on these platforms. > > - Anything else that was pointed out in review or was tricky while > developing this stuff. More ideas! My main concern is interactions with existing features when the primary plane is disabled and no other plane/cursor enabled, i.e. when we scan out a solid black. - solid black vs. dpms for all connector/pipe pairings. The modeset sequence is different for different connectors and my gut says not enabling the primary plane might cause trouble. - solid black vs. vblank events. When transition through a "no planes" situation we need to make sure that vblank events keep on working. A testcase (maybe in combination of some of the dpms and susped/resume case above too) would be good. I'll leave it to you to somewhat sensibly group all these ideas into real testcases ;-) For further inspiration maybe look at the corner cases existing kms_* tests exercise a bit. -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
