drm-next update

[Ville Syrjälä]

On Tue, Nov 20, 2012 at 11:27:20AM -0600, Rob Clark wrote:
> On Tue, Nov 20, 2012 at 7:40 AM, Ville Syrjälä
> <ville.syrjala at linux.intel.com> wrote:
> > On Tue, Nov 20, 2012 at 04:39:39PM +1000, Dave Airlie wrote:
> >> Okay just pushed out a bunch of -next queued stuff,
> >>
> >> I've been stuck on another project for a couple of weeks and haven't
> >> really being paying enough attention to -next, so this is a heads up,
> >> if someone has something big they want merged this window and I
> >> haven't seen it yet or merged it yet, you should probably mention it
> >> in a reply to this mail with a summary of where you think its at.
> >> (e.g. atomic nuclear modesetting flipping).
> >
> > I don't the atomic stuff is quite ready for merging yet. However my
> > code is more or less feature complete now. I have implemented everything
> > I planned to originally, apart from adding more properties for various
> > things. And as I mentioned before, Weston is now running quite nicely
> > on top of my kernel branch.
> >
> > What's still missing is some refactoring, and possibly some fixes. And
> > hardly anyone has commented on it, so please everyone have a look and
> > let me know what you think. Maybe I need to start a blog to get people
> > interested...
> 
> it would be nice to at least pull in the object and signed property
> type stuff from my branch, since that is effecting userspace facing
> API..

Yeah, I still need to go over your code properly. What I remember from
the last time I looked at it was that the signed property type is fine
by me, the dynamic flag I don't really agree with, since you probably
can't set it for most things anyway, and the state stuff is touching a
lot of places at the same time, which is somehting I've been trying to
avoid at this stage.

> All the plane/crtc/etc state object stuff doesn't effect abi so could
> come later, I suppose.  It does touch a lot of drivers even if they
> aren't converted to 'atomic', but OTOH I think it makes things much
> cleaner and easier to 'atomicify' a driver without duplicating so much
> stuff in each driver.  So long term I still think it is the right
> thing.  But not sure how much more time I'll spend on it in the near
> term.

I don't really want to push a huge change to all code paths at the same
time. The current setcrtc/pageflip code is known to work (sort of at
least), so if something were to regress we'd possibly have to back out
the whole thing. So I'd like to get the atomic stuff in as a separate
thing first.

Once it's in we can start to fix the state handling, and also start
calling into the atomic code from the legacy code paths.

Another detail we nee to figure out is the actual properties that
we're using. I personally don't like the crtc.SRC_X and crtc.SRC_Y
properties that my code has for example. They don't behave like the
plane properties with the same names, so maybe we should use different
names for them. Well, idelly we wouldn't even have them, but moving all
scanout duties over to planes is another thing I really don't want to
tie into the atomic stuff at this point in time. I suppose we can't
deprecate any properties easily, so we need to make sure we can all
live with the ones we add initially.

-- 
Ville Syrjälä
Intel OTC