On Thu, Mar 05, 2015 at 03:08:17PM +0200, Ville Syrjälä wrote: > On Thu, Mar 05, 2015 at 01:56:53PM +0100, Daniel Vetter wrote: > > On Thu, Mar 05, 2015 at 02:51:28PM +0530, Sonika Jindal wrote: > > > @@ -1519,16 +1550,7 @@ intel_plane_init(struct drm_device *dev, enum pipe > > > pipe, int plane) > > > goto out; > > > } > > > > > > - if (!dev->mode_config.rotation_property) > > > - dev->mode_config.rotation_property = > > > - drm_mode_create_rotation_property(dev, > > > - BIT(DRM_ROTATE_0) | > > > - BIT(DRM_ROTATE_180)); > > > - > > > - if (dev->mode_config.rotation_property) > > > - drm_object_attach_property(&intel_plane->base.base, > > > - dev->mode_config.rotation_property, > > > - state->base.rotation); > > > + intel_create_rotation_property(dev, intel_plane); > > > > I think back from the original rotation work we've had the leftover task > > to move this into common code so that we do create the property just once > > without this check. > > > > I think this should be done now. > > Someone should also make it so we can again have different supported > rotation bits on different planes. I'll have need for it on CHV I think.
plane->atomic_check just needs to reject them. Tbh I'm not sold on the value of trying to tell userspace which rotation works and which doesnt - generic userspace won't learn about y-tiling requirements either so this feels a bit pointless tbh. And rejecting stuff in atomic_check is what it's for. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
