On Mon, Nov 14, 2016 at 01:06:09PM +0000, Chris Wilson wrote: > On Mon, Nov 14, 2016 at 02:44:35PM +0200, Petri Latvala wrote: > > Chris, happy with this revision? > > Me? No. It still uses a thread instead of events, so I don't think it > qualifies as a good example for anyone else wanting to do the same thing. > Lots of hardcoded expectations (specific sleep patterns, rather than > waiting for the kernel to change with a timeout for failure). It doesn't > check all the possible ways that the output maybe changed (and if they > are irrelevent, that too also needs to be tested to establish expected > behaviour and catch future regressions). Important question, how is > userspace expected to know that the vrefresh changed? How do get around > that userspace is expecting a fixed vblank frequency?
for display power testing we already have the kms_frontbuffer_tracking testcase, adding a DRRS variants to that one should resolve all this. And then kms_drrs would be empty, except when we (if ever) do explicit drrs through modeset requests. And that would just be checking that the observed timings match the requested timings. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
