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 iscleared.
- DRM_MODE_CONTENT_TYPE_GRAPHICS = 4
Content type is graphics, it content(itc) bit isset.
- 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.