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

[Rob Clark]

On Thu, Aug 29, 2013 at 3:01 AM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> 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.

yeah, that is probably better

>>> 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.

agreed.  But we also have to fix the format_check() when you try to
create an fb ;-)

BR,
-R

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