Re: [PATCH 00/16] Atomic/nuclear modeset/pageflip

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, Mar 19, 2014 at 08:23:31AM -0400, Rob Clark wrote:
> On Wed, Mar 19, 2014 at 7:07 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Tue, Mar 18, 2014 at 05:22:37PM -0400, Rob Clark wrote:
> > On the i915 side I think all the various pieces we need are finally coming
> > together, and I hope a lot of that goes in for 3.16. So I think we can
> > soonish jump on board with providing real proof-of-concepts based on your
> > ioctl.
> >
> > For merging the core stuff I think we should concentrate first on getting
> > Matt's universal planes stuff in asap. I've scanned through his series
> > with a cursory look and atm it has a few change-the-world flag days. I'll
> > try to do an in-depth review later on looking for ways to make the
> > transition smoother. cursor planes seem to be the main culprit in this ...
> 
> it would be nice if there was a way to get things merged sooner than
> 3.18 or so.. but we do need at least the *initial* primary plane work
> first.
> 
> Some of the stuff like cursor planes should really happen
> independently from atomic.  And maybe at the same time we want to
> expose cursor properties, or at least somehow property-ify cursors.
> The part that really needs to be in before atomic is the
> crtc->primary->fb bit.

Hm, just wanted to dump a comment on Matt's series that imo cursor planes
should happen first before we enable universal planes. And the resulting
unification is really kinda neat for atomic imo.

Still pondering the details but I don't think there's too much fuzz
involved in exposing cursor planes. We can't do it without any driver
changes at all since there's no generic way to go from cursor fb to buffer
manager object id. But beyond that there's shouldn't be anything needed.

I'm hashing out a slightly more detailed plan atm.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch