On Thu, May 24, 2012 at 08:49:53PM +0200, Daniel Vetter wrote: > 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. Mainly I just dislike incoherent behaviour. One use case might be flipping to another framebuffer using the setcrtc ioctl, in case the page flip ioctl isn't provided, or can't be used. With the current code the result depends on various implementation specific details like whether the driver implements a set_base type of optimization in a certain way. From the user space POV it's just a setcrtc ioctl, but there's no sensible way to know whether the operation will destroy some unrelated state or not. -- Ville Syrj?l? Intel OTC
