[RFC PATCH] drm: Add plane event

[Daniel Vetter]

On Wed, Apr 18, 2012 at 05:55:15PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 05:27 PM, Daniel Vetter wrote:
> >On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> >>On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> >>>Last time around I've discussed with people we've ended up with 2 new
> >>>ioctls:
> >>>
> >>>- atomic modeset, to configure the output state on more than one crtc at
> >>>   the same time. This is useful to get pll assignement, memory bandwidth
> >>>   constrains and similar stuff right. This ioctl is synchronous. A
> >>>   testmode can be used to inquire the driver whether the proposed mode
> >>>   actually works. This could be used for gui interfaces to automatically
> >>>   grey out unsupportable configurations, e.g. if you have 3 crtc but on 2
> >>>   pll and 2 modes need to have the same pixelclocks to drive all 3 crtcs.
> >>>
> >>>- an atomic pageflip. This one would be like the current pageflip ioclt,
> >>>   i.e. run asynchronously and deliver a drm event upont completion. The
> >>>   idea is that compositors can use this to make flicker-free compositition
> >>>   with drm planes possible. I think we want drivers to be able to indicate
> >>>   which crtc properties they can switch with this ioctl, e.g. I expect
> >>>   some yuv->rbg color space properties might not work. All the changes
> >>>   should be applied on the same vblank, obviously.
> >>Why an atomic pagefilp? How is this different from an atomic modeset
> >>where only fbs change? Can't drm frmwrk "optimize" this like SETCRTC
> >>does today with base/full modeset helpers?
> >The important difference is that the pageflip should happen vsynced on one
> >single crtc. So it can't do anything which takes longer than a vsync
> >(usually you need to wait a frame for the clocks to stabilize before
> >switching on the next stage in the output pipeline), so any output
> >configuration changes are pretty much out of the window. We also want
> >pageflip to run asynchronously and return immediately after emitting all
> >relevant commands. That's not really important for modeset.
> >
> >So yeah, you could smash all this into one giant ioctl, but I think the
> >split is useful and would simplify things quite a bit on the
> >implementation side. Otherwise you need to add funny queries so that
> >userspace can figure out which modeset ops run asynchronous, which can be
> >vblank synced. And it needs to tell the kernel for which it wants an
> >event. Especially when you have multiple crtc and want to drive all of
> >them with a compositor, this can get funny.
> >
> >Also, I'm toying around with ideas to split up the big modeset lock such
> >that operations that only touch the crtc (like pageflip, plane changes and
> >cursor changes) do not take the big modeset lock but only a per-crtc
> >mutex. This way a compositor running on crtc A could run without hiccups
> >while we do a modeset operation on crtc B, or while a hotplug detection is
> >reading back the edid from a unused connector (which can easily take
> >longer than a few frames). We have tons of bug reports from users that
> >complain that every 10s their cursor stalls (due to hotplug detect).
> >
> >If you smash everything into one ioctl, I imagine you have plenty of fun
> >implementing all this. Which is why I prefer to split this up.
> >-Daniel
> 
> The async vs sync makes sense as reason for splitting them. My
> problem lies somewhere in between sync modeset and async flip -
> async crtc/plane/fbs modeset.
> In Wayland and Android HW composer I need to asynchronously flip and
> do crtc/plane modeset, but no connector/crtc modeset (so it is a
> fast operation). Because I don't consider enable/disable/move a
> plane to be a full synchronous modeset (same mode different
> fbs/planes). But I still want the same async events to tell me the
> new plane setup is activated at vsync. But as you say, maybe the
> biggest issue here is the "big drm lock". So maybe user space would
> be ok to do this crtc-modeset in sync mode, if it doesn't block
> other operations on other crtcs. But I would prefer to be able to do
> the crtc modeset async so I don't have to have a thread per crtc. Or
> am I missing the obvious solution to this?

Changing moving planes would be part of the big new async monster
pageflip. Generally everything that the hw can change vblank-synced and
asynchronously up to the logical point where the pixeldata is generated.
Ans yes, Wayland/SF is exactly the use-case for this, so that you can
dynamically switch surfaces to be rendered with planes, all async and
properly vblank-synced.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48