[igt-dev] [PATCH i-g-t 3/3] tests/kms_fbcon_fbt: Drop master before restoring fbcon

Daniel Vetter daniel at ffwll.ch
Mon Feb 10 08:04:04 UTC 2020


On Fri, Feb 07, 2020 at 05:36:08PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 07, 2020 at 04:29:45PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 07, 2020 at 04:19:19PM +0200, Ville Syrjälä wrote:
> > > On Tue, Jan 28, 2020 at 12:25:49PM +0100, Daniel Vetter wrote:
> > > > fbdev helpers refuse to restore the fbdev screen if there's still a
> > > > master present. This is to avoid fbcon popping up when a compositor
> > > > has intentionally disabled all outputs.
> > > > 
> > > > Unfortunately the kernel had some bugs in this area, and kms_fbcon_fbt
> > > > relied on those. Result was that fbdev restore was skipped, which
> > > > skipped the frontbuffer flushing, which broke the PSR subtest's
> > > > expectation that PSR is always disable when fbdev is enabled. FBC did
> > > > not get broken because FBC was never enabled on linear framebuffers as
> > > > used by fbdev.
> > > > 
> > > > Fix things up to make sure fbcon gets restored correctly in all cases.
> > > > 
> > > > Cc: Noralf Trønnes <noralf at tronnes.org>
> > > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > > > ---
> > > >  tests/kms_fbcon_fbt.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/tests/kms_fbcon_fbt.c b/tests/kms_fbcon_fbt.c
> > > > index 236e09ea1ebd..ed4cccbe743e 100644
> > > > --- a/tests/kms_fbcon_fbt.c
> > > > +++ b/tests/kms_fbcon_fbt.c
> > > > @@ -74,6 +74,8 @@ static void teardown_drm(struct drm_info *drm)
> > > >  {
> > > >  	int i;
> > > >  
> > > > +	igt_assert_eq(drmDropMaster(drm->fd), 0);
> > > > +
> > > 
> > > Aren't we closing the whole fd soonish?
> > 
> > Yeah, but after the vt switch, which I think is too late (proof still
> > waiting for CI). I guess I could have moved the close up too, but I
> > figured trying to implement proper vt switching a bit more closely yields
> > the better test.
> > 
> > Could also be that I'm totally misinterpreting what's going on here with
> > my kernel patch series.
> 
> I can buy that the close after vt switch somehow doesn't do the
> same thing as swapping them around. At least can't see any possible
> harm from this (other than not testing close-after-vt-switch), so

CI results came back, this indeed fixes the regression that held up
Noralf's original idea, so whatever the theory, the practice works out :-)

> Reviewed-by: Ville Syrjälä <ville.syrjala at linux.intel.com>

Thanks for taking a look at these, all pushed.
-Daniel

> 
> > -Daniel
> > 
> > > 
> > > >  	kmstest_restore_vt_mode();
> > > >  
> > > >  	for (i = 0; i < drm->res->count_connectors; i++)
> > > > -- 
> > > > 2.24.1
> > > > 
> > > > _______________________________________________
> > > > igt-dev mailing list
> > > > igt-dev at lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/igt-dev
> > > 
> > > -- 
> > > Ville Syrjälä
> > > Intel
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> 
> -- 
> Ville Syrjälä
> Intel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the igt-dev mailing list