Re: [RFC PATCH] drm: Add plane event

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 18, 2012 at 09:24:58PM -0400, Kristian Høgsberg wrote:
> One thing that's not clear to me is how we would enable a sprite
> without going through the atomic modeset again.  If the atomic modeset
> is all about calculating bandwidth requirements etc, then enabling a
> sprite will affect that and it may or may not be possible based on the
> current configuration.  However, enabling a sprite from one frame to
> another is something that we would want to do as part of the nuclear
> pageflip.  So I'm not sure how this would work... maybe we could have
> a prepare_sprite_enable type ioctl that verifies that it's possible to
> add the sprite plane to the current configuration.  Then if that
> succeeds, we can use the nuclear pageflip to enable the sprite plane.

Sprites also have an ugly issue wrt finer-grained locking: If we move to
per-crtc locking, the nuclear pageflip would only need to take the crtc
mutex it operates on. But the if we move a sprite from one crtc to another
one, we'd need to lock both crtcs, and the easiest solution for the lock
ordering problem this causes is to require that all code which needs more
than one crtc look needs the big modeset lock. Which would be painful for
pageflip.

Also, most sprites/overlays can't be switched in one step from one crtc to
another, so these pageflips would run synchronous. Which is not the point of
pageflipping. So I think a prepare_sprite ioctl which changes the crtc
association (and checks memory bandwidth and other constrains) but does
not display anything would be good to support the nuclear pageflip without
jumping through too many hoops in the kernel. Nuclear pageflip would need
to support pageflippping from/to NULL framebuffers on planes then to
signal switching a plane on/off. Maybe we could even do that for the main
crtc fb (and add a background color), e.g. for video watch to avoid
scanning out black bars.
-Daniel
-- 
Daniel Vetter
Mail: daniel@xxxxxxxx
Mobile: +41 (0)79 365 57 48
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux