Re: [PATCH 3/3] drm/i915/skl: Support for 90/270 rotation

[Daniel Vetter <daniel@ffwll.ch>]

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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx