Re: [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

From: Daniel Vetter <daniel@ffwll.ch>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
Date: Tue, 7 Jul 2015 18:40:36 +0200	[thread overview]
Message-ID: <20150707164036.GY7568@phenom.ffwll.local> (raw)
In-Reply-To: <559BE30C.8060105@linux.intel.com>

On Tue, Jul 07, 2015 at 04:32:44PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
> >>>> This allows the first atomic call during hw init to be a real modeset,
> >>>> which is useful for forcing a recalculation.
> >>> fbcon is optional, you can't rely on anything being done in any specific
> >>> way. What exactly do you need this for, what's the implications?
> >> In the hw readout I noticed some warnings when I wasn't setting any mode property in the readout.
> >> I want the first function to be the modeset, so we have a sane base to commit changes on.
> >> Ideally this whole function would have a atomic counterpart which does it in one go. :)
> > Yeah. Otoh as soon as we have atomic modeset working we can replace all
> > the legacy entry points with atomic helpers, and then even plane_disable
> > will be a full atomic modeset.
> >
> > What did fall apart with just touching properties/planes now?
> Setting rotation on the primary plane caused it to be disabled because
> the src and dst rectangle are not set up yet until the modeset. So the
> check function saw that the plane should be invisible and performs the
> update.

Sounds like a bug - we need to recreate more of the primary plane state.
Or maybe we need to call the atomic_check function for the primary plane
to compute all that derived state. But we really can't rely upon userspace
to do a modeset first, e.g. X at start (if there's no fbcon) loves to read
and then write back all the properties (or at least did).

We really need to handle this in the backend properly.

> It's also an extra vblank wait when the primary plane is visible.

Another bug, no-op changes with the same fb should not result in a vblank
wait. At least not when using the helpers (or if there is a case I need to
copypaste the fix again).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx