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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Aug 29, 2013 at 09:01:01AM +0200, Daniel Vetter wrote:
> On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark <robdclark@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".

That's the normal mode of operation as far as I'm concerned. If the user
doesn't specify a prop, it retains its current value.

Also I don't generally want magic properties that flip their state in
response to a change in other seemingly unrelated property. Either the
user specifies a coherent state, or we return an error.

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

That could be useful, or we could maintain per-master state/context.

But I don't consider the planes themselves the major issue here. It's
very easy for the client to disable all unneeded planes explicitly.
It's all the other stuff like various methods of gamma adjustments,
various other color adjustemnt thingys, possibly some blending modes,
the output quantization range stuff, etc.

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

The all planes approach only works here if your drm_crtc is an abstract
thing composed of multiple hardware mixers/blenders/whatever you call them.

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

My plan for i915 is to convert them to drm_planes but first keep them
hidden via Rob's private plane mechanism.

After that we need to figure out how we can expose them to userspace w/o
risking breaking stuff too much. Maybe a new ioctl to enumerate private
planes only? And the maybe only accept direct use of private planes via
the atomic API, not through the old setplane API. Or if people want to
use setplane we could add a flag there indicating that the user is aware
of private planes and wants to use them.

> And then we can just ditch format_check

I'd like to keep the check because it provides a small barrier against
people just adding formats in driver code w/o even updating drm_fourcc.h.
If we need the extra flexibility, let's add the custom bit, and then
user space will know all bets are off when dealing with such formats.

> 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
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC