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
