Hi On Wed, Sep 9, 2015 at 5:02 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, Sep 09, 2015 at 04:40:56PM +0200, Maarten Lankhorst wrote: >> Previously RMFB and fd close chose to disable any plane that had >> an active framebuffer from this file. If it was a primary plane the >> crtc was disabled. However the fbdev code or any system compositor >> should restore the planes anyway so there's no need to do it twice. >> >> The old fb_id is zero'd, so there's no danger of being able to >> restore the fb from fb_id. >> >> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > > I think the current behaviour was just a side-effect of the original > implementation and not too intentional - with no refcounting for fbs they > _had_ to be synchronously reaped. And when I've done the conversion to > refcounting I kept this to avoid gettting tangled up in an ABI-change > mess. > > But I don't the current behaviour makes much sense and worth an attemp to > rectify it. And as long as we still clear the fb ids there's no real > information leak either. > > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > But I do want other people's opinion before I pull this in. We _REALLY_ want this! It makes a lot of our life much easier when trying to get rid of flicker during boot-up. It currently sucks that neither the boot-loader screen, nor the boot-splash screen, nor the login-manager screen can be left around after they quit and handover to the next stage. We have to stay around for hand-over, which is nasty and requires a back-channel which is otherwise not needed at all. Reviewed-by: David Herrmann <dh.herrmann@xxxxxxxxx> Thanks David _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
