Re: [PATCH v7 1/2] drm: content-type property for HDMI connector

["Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>]

On Fri, 2018-04-27 at 22:40 +0300, Ville Syrjälä wrote:
> > +
> > +/**
> > + * DOC: HDMI connector properties
> > + *
> > + * content type (HDMI specific):
> > + *	Indicates content type setting to be used in HDMI
> > infoframes to indicate
> > + *	content type for the external device, so that it adjusts
> > it's display
> > + *	settings accordingly.
> > + *
> > + *	The value of this property can be one of the following:
> > + *
> > + *	- DRM_MODE_CONTENT_TYPE_NO_DATA = 0
> > + *		Content type is unknown, it content(itc) bit is
> > cleared.
> > + *	- DRM_MODE_CONTENT_TYPE_GRAPHICS = 4
> > + *		Content type is graphics, it content(itc) bit is
> > set.
> > + *	- DRM_MODE_CONTENT_TYPE_PHOTO = 5
> > + *		Content type is photo, itc bit is set.
> > + *	- DRM_MODE_CONTENT_TYPE_CINEMA = 6
> > + *		Content type is cinema, itc bit is set.
> > + *	- DRM_MODE_CONTENT_TYPE_GAME = 7
> > + *		Content type is game, itc bit is set.
> 
> I wonder if we're trying to document the uabi or the internals here.
> If we are interested in the uabi, then we should document the enum
> value strings here. If on the other hand we're trying to document the
> internal details then we should keep the DRM_CONTENT_TYPE_* stuff.
> Maybe we want both? The raw numbers I think we should just throw out.
> While they do have some specific meaning in the case (matching the
> bits
> in the infoframe), I'm not sure that's important enough to include in
> the docs. We could add a comment next to the DRM_MODE_CONTENT_TYPE_*
> definitions.
> 
> Looks like the content protection prop is documenting the internals
> only
> as well. Hmm. Actually it looks like those things are defined in the
> uapi
> header. Oh and the scaling mode prop also does that. This is all
> setting
> a rather bad example for userspace. Or maybe we've given up on the
> "the
> string is the uabi" notion entirely?
> 

I can just throw away the numbers from that doc, but add a bit of more
clarification in the definition itself. If this is fine with everybody.


-- 
Best Regards,

Lisovskiy Stanislav
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx