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
