[RFC PATCH] drm: Add plane event

[Luc Verhaegen]

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?

Buffering. When you are doing triple buffering and need to update 
addresses, which should be flipped at next vblank, you do not want to go 
through a massive amount of state handling.

I do not agree with SETCRTC though.

The CRTC is the entity that serializes, that has the actual modeline 
set, that might allow rotation and/or scaling all of the planes and 
cursors (to the extent that these are not planes) that are put into it.

Planes are the actual FB and possible overlays. It is the planes that do 
colour conversion and whatnot (pitch), might allow for z-ordering, 
individual scaling and rotation, and which might not need to be full 
screen. It is these elements that take in buffer addresses and should do 
page flipping. You might have to artificially split out the base plane 
and CRTC for your hardware, and have some code duplication or multiple 
uses of the same functions.

Now look at the relative probability of each of the actions:
* The frequency of altering the mode (on the crtc) is very low.
* The frequency of altering the planes is/should already a lot higher 
when you are using the likes of wayland or the android hw compositor.
* The frequency of page flipping is very high.

This means that there should be (at least) three separate actions:
* page flipping: buffers -> planes at next vblank, for a list of 
buffer(s) and plane tuples.
* setplanes: colour format, position, scaling, ordering, rotation, color 
key, crtc adherance, _plus_ the above.
* actual modeset, which handles the CRTC and out to the monitor and 
whatnot, which should also include the above.

With appropriate helper functions combining these events should not be 
hard as you move down the list.

As someone who has spent quite a lot of time with Xvideo in the past 
(and pretty much the only guy still around who wrote up ReputImage 
support for his graphics driver), i am glad that we have buffer 
management today, and we should use that to the max and cut down on 
duplicated and errorprone state tracking.

Luc Verhaegen.