On Tue, Jan 20, 2015 at 4:26 PM, Matt Roper <matthew.d.roper@xxxxxxxxx> wrote: > On Tue, Jan 20, 2015 at 10:44:06AM +0100, Daniel Vetter wrote: >> On Thu, Jan 15, 2015 at 06:34:19PM -0800, Matt Roper wrote: >> > Runtime state that can be manipulated via properties should now go in >> > intel_plane_state instead so that it can be tracked as part of an atomic >> > transaction. >> > >> > Signed-off-by: Matt Roper <matthew.d.roper@xxxxxxxxx> >> >> Imo we should move this to drm_plane_state so that fb helpers or and the >> drm atomic ioctl could do the decoding in shared code instead of >> duplicating things all over. But we probably want to do that once the i915 >> conversion (at least on the plane side) has settled a bit. >> -Daniel > > I considered this, but I wasn't sure how it would shake out if some > drivers have converted to atomic (and store their rotation in plane > state) and other drivers haven't converted (and still store it in some > driver-specific area). If drivers haven't converted to atomic, the > atomic ioctl wouldn't be a concern, but it seems like the fb helpers > might have more difficulty figuring out whether it could trust rotation > values or not. From a quick cscope, it looks like exynos and omap at > least have some rotation support and I didn't want to deal with them > until I had the Intel work in good shape. Oh, we don't yet have an atomic fb helper. If we ever get around to that then we'd need 2 completely separate fb helper paths anyway, so the slight duplication because of rotation won't hurt all that much. And the benefits for the atomic ioctl are imo worth it on it's own for converted drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
