On Thu, Mar 05, 2015 at 04:29:30PM +0100, Daniel Vetter wrote: > 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. By that logic we shouldn't expose pixel formats or any other useful infromation either then. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
