[PATCH 0/4] drm/i915: Make video sprites survive a modeset
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
[PATCH 0/4] drm/i915: Make video sprites survive a modeset
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
[PATCH 0/4] drm/i915: Make video sprites survive a modeset
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. -- Jesse Barnes, Intel Open Source Technology Center
[PATCH 0/4] drm/i915: Make video sprites survive a modeset
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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/i915: Make video sprites survive a modeset
On Thu, 24 May 2012 21:29:46 +0300 ville.syrj...@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. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/i915: Make video sprites survive a modeset
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.syrj...@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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
