[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same
Daniel Vetter
daniel at ffwll.ch
Tue Jul 7 09:40:36 PDT 2015
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
More information about the Intel-gfx
mailing list