[PATCH 0/4] drm/i915: Make video sprites survive a modeset

Daniel Vetter daniel at ffwll.ch
Thu May 24 11:49:53 PDT 2012


On Thu, May 24, 2012 at 11:35:35AM -0700, Jesse Barnes wrote:
> On Thu, 24 May 2012 21:29:46 +0300
> ville.syrjala at linux.intel.com wrote:
> 
> > Currently the video sprites appear to get disabled on modeset more by
> > accient than by design.
> > 
> > With the current API that behaviour makes very little sense to me.
> > You first enable some plane, and then it can get disabled due to some
> > unrelated operation.
> > 
> > So these patches change the behaviour so that planes survive a modeset.
> > There's a new hook to make sure they get disabled when swithing
> > back to fbdev to show a panic oops.
> 
> Yeah that's not really a design requirement; the assumption was that
> the display manager would do the right thing in any case (both mode
> sets and plane sets are privileged ops).  When doing a mode set, the
> plane parameters will probably need to be changed anyway...
> 
> But keeping it on with some kind of sensible behavior makes the simple
> cases easier.

tbh I don't see the use-case. If you issue a modeset from userspace, you
better start out with something sensible (like a black screeen) and fade
in nicely whatever you want to show. And if you change the layout, you
have to reorg everything anyway.

We do though do a few modesets from within the kernel (e.g. audio property
on hdmi/dp), and I guess these should forget about any currently visible
planes. Dunno what to do here.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48


More information about the dri-devel mailing list