On Thu, Mar 05, 2015 at 05:56:23PM +0200, Ville Syrjälä wrote: > 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. Well to be able to fix this we need to restrict the value-set of properties per-attachment. Since I very much want core atomic to decodd standardized properties, and if we create rotation per-plane then that's going to be fairly painful. That's quite a bit of work, and I'm not sure it's all that useful. And yeah that argument does extend somewhat to pixel formats too since without clueful userspace you can't really allocate a suitable buffer with just the list of pixel formats. They are useful though for a bit of shared input validation in the core (since most planes don't change the support pixel formats at runtime). -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
