[Linaro-mm-sig] [RFC 0/4] Atomic Display Framework

[Daniel Vetter]

On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark <robdclark at gmail.com> wrote:
>> 1.  The API is geared toward updating one object at a time.  Android's graphics stack needs the entire screen updated atomically to avoid tearing, and on some SoCs to avoid wedging the display hardware.  Rob Clark's atomic modeset patchset worked, but copy/update/commit design meant the driver had to keep a lot more internal state.
>>
>
> I'm not entirely sure how to avoid that, because at least some hw we
> need to have the entire new-state in order to validate if it is
> possible.  I'm open to suggestions, of course, but the approach I was
> going for was to at least do most of the boring work for this in
> drm/kms core (ie. w/ the drm_{plane,crtc,etc}_state stuff)

Yeah, I think Rob's design that trickle-feeds the entire state to the
driver is ok (preferrably using a driver-allocated state tracking
object or so). And then we'll let some helper code make this sane for
most drivers.

I guess especially for pageflips a mode where we just pass in new
buffers (and leave all the blending as-is) would be useful, maybe we
could add a flag that says "keep all other properties as-is". A second
flag for "reset properties to defaults" would also be good, where
default = the primary plane can display  unobstructed. So mostly just
for boot splash screens, fbcon, ...

>> 2.  Some SoCs don't map well to KMS's CRTC + planes + encoders + connector model.  At the time I was dealing with hardware where the blending engines didn't have their own framebuffer (they could only scan out constant colors or mix the output of other blocks), and you needed to gang several mixers together to drive high-res displays.
>>
>
> currently you can connect a crtc to multiple encoders (at least for
> some hw)..  I suppose w/ the small addition of having a way to specify
> an encoder's x/y offset, we could cover this sort of case?

Hm, I've thought that if we convert the primary plane to a real plane
we'd already have that. Then you can just place planes at x/y offset
to construct the entire scanout area. Planes also have a crtc mask, as
do connectors (through the encoders) so the n-to-m mapping is also
possible on the output side afaics.

>> 3.  KMS doesn't support custom pixel formats, which a lot of newer SoCs use internally to cut down on bandwidth between hardware blocks.
>
> for custom formats, use a custom fourcc value, this should work.
>
> err, hmm, looks like some of the error checking that was added is a
> bit too aggressive.  What I'd propose is:
>
>   #define DRM_FORMAT_CUSTOM 0x80000000
>
> and then 'if (format & DRM_FORMAT_CUSTOM) ... pass through to driver ..'

Imo we should just convert primary planes to real planes so that we
can do the same table-based checking for them as we do for secondary
planes right now. And then we can just ditch format_check and allow
drivers to use whatever pleases them. Of course reserving a driver
specific range would be good, otoh we could just add more stuff to the
drm_fourcc.h header.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch