~emersion/drmdb

dd9a7cf6e16746b483af866d534ec369f1f101fa — Simon Ser 3 months ago 45c8599
drmdoc: new package
A drmdoc/color-management-properties.go => drmdoc/color-management-properties.go +11 -0
@@ 0,0 1,11 @@
// Code generated by running "go generate". DO NOT EDIT.

package drmdoc

var colorManagementProperties = map[string]string{
	"DEGAMMA_LUT_SIZE": "Unsinged range property to give the size of the lookup table to be set\non the DEGAMMA_LUT property (the size depends on the underlying\nhardware). If drivers support multiple LUT sizes then they should\npublish the largest size, and sub-sample smaller sized LUTs (e.g. for\nsplit-gamma modes) appropriately.",
	"CTM":              "Blob property to set the current transformation matrix (CTM) apply to\npixel data after the lookup through the degamma LUT and before the\nlookup through the gamma LUT. The data is interpreted as a struct\n&drm_color_ctm.\n\nSetting this to NULL (blob property value set to 0) means a\nunit/pass-thru matrix should be used. This is generally the driver\nboot-up state too. Drivers can access the blob for the color conversion\nmatrix through &drm_crtc_state.ctm.",
	"GAMMA_LUT":        "Blob property to set the gamma lookup table (LUT) mapping pixel data\nafter the transformation matrix to data sent to the connector. The\ndata is interpreted as an array of &struct drm_color_lut elements.\nHardware might choose not to use the full precision of the LUT elements\nnor use all the elements of the LUT (for example the hardware might\nchoose to interpolate between LUT[0] and LUT[4]).\n\nSetting this to NULL (blob property value set to 0) means a\nlinear/pass-thru gamma table should be used. This is generally the\ndriver boot-up state too. Drivers can access this blob through\n&drm_crtc_state.gamma_lut.",
	"GAMMA_LUT_SIZE":   "Unsigned range property to give the size of the lookup table to be set\non the GAMMA_LUT property (the size depends on the underlying hardware).\nIf drivers support multiple LUT sizes then they should publish the\nlargest size, and sub-sample smaller sized LUTs (e.g. for split-gamma\nmodes) appropriately.\n\nThere is also support for a legacy gamma table, which is set up by calling\ndrm_mode_crtc_set_gamma_size(). Drivers which support both should use\ndrm_atomic_helper_legacy_gamma_set() to alias the legacy gamma ramp with the\n\"GAMMA_LUT\" property above.\n\nSupport for different non RGB color encodings is controlled through\n&drm_plane specific COLOR_ENCODING and COLOR_RANGE properties. They\nare set up by calling drm_plane_create_color_properties().\n\n\"COLOR_ENCODING\"\nOptional plane enum property to support different non RGB\ncolor encodings. The driver can provide a subset of standard\nenum values supported by the DRM plane.\n\n\"COLOR_RANGE\"\nOptional plane enum property to support different non RGB\ncolor parameter ranges. The driver can provide a subset of\nstandard enum values supported by the DRM plane.",
	"DEGAMMA_LUT":      "Blob property to set the degamma lookup table (LUT) mapping pixel data\nfrom the framebuffer before it is given to the transformation matrix.\nThe data is interpreted as an array of &struct drm_color_lut elements.\nHardware might choose not to use the full precision of the LUT elements\nnor use all the elements of the LUT (for example the hardware might\nchoose to interpolate between LUT[0] and LUT[4]).\n\nSetting this to NULL (blob property value set to 0) means a\nlinear/pass-thru gamma table should be used. This is generally the\ndriver boot-up state too. Drivers can access this blob through\n&drm_crtc_state.degamma_lut.",
}

A drmdoc/drmdoc.go => drmdoc/drmdoc.go +46 -0
@@ 0,0 1,46 @@
package drmdoc

//go:generate go run generate.go drivers/gpu/drm/drm_connector.c "standard connector properties"
//go:generate go run generate.go drivers/gpu/drm/drm_connector.c "HDMI connector properties"
//go:generate go run generate.go drivers/gpu/drm/drm_crtc.c "standard CRTC properties"
//go:generate go run generate.go drivers/gpu/drm/drm_blend.c "overview" "plane blending properties"
//go:generate go run generate.go drivers/gpu/drm/drm_color_mgmt.c "overview" "color management properties"
//go:generate go run generate.go drivers/gpu/drm/drm_atomic_uapi.c "explicit fencing properties"
//go:generate go run generate.go drivers/gpu/drm/drm_connector.c "Variable refresh properties"
//go:generate go fmt

import (
	"git.sr.ht/~emersion/go-drm"
)

func Prop(obj drm.ObjectType, name string) string {
	switch obj {
	case drm.ObjectConnector:
		if doc, ok := standardConnectorProperties[name]; ok {
			return doc
		}
		if doc, ok := hdmiConnectorProperties[name]; ok {
			return doc
		}
	case drm.ObjectCRTC:
		if doc, ok := standardCRTCProperties[name]; ok {
			return doc
		}
		if doc, ok := colorManagementProperties[name]; ok {
			return doc
		}
	case drm.ObjectPlane:
		if doc, ok := planeBlendingProperties[name]; ok {
			return doc
		}
	}
	// Explicit fencing and VRR docs contain mixed plane, connector and CRTC
	// props
	if doc, ok := explicitFencingProperties[name]; ok {
		return doc
	}
	if doc, ok := variableRefreshProperties[name]; ok {
		return doc
	}
	return ""
}

A drmdoc/explicit-fencing-properties.go => drmdoc/explicit-fencing-properties.go +8 -0
@@ 0,0 1,8 @@
// Code generated by running "go generate". DO NOT EDIT.

package drmdoc

var explicitFencingProperties = map[string]string{
	"IN_FENCE_FD":   "Use this property to pass a fence that DRM should wait on before\nproceeding with the Atomic Commit request and show the framebuffer for\nthe plane on the screen. The fence can be either a normal fence or a\nmerged one, the sync_file framework will handle both cases and use a\nfence_array if a merged fence is received. Passing -1 here means no\nfences to wait on.\n\nIf the Atomic Commit request has the DRM_MODE_ATOMIC_TEST_ONLY flag\nit will only check if the Sync File is a valid one.\n\nOn the driver side the fence is stored on the @fence parameter of\n&struct drm_plane_state. Drivers which also support implicit fencing\nshould set the implicit fence using drm_atomic_set_fence_for_plane(),\nto make sure there's consistent behaviour between drivers in precedence\nof implicit vs. explicit fencing.",
	"OUT_FENCE_PTR": "Use this property to pass a file descriptor pointer to DRM. Once the\nAtomic Commit request call returns OUT_FENCE_PTR will be filled with\nthe file descriptor number of a Sync File. This Sync File contains the\nCRTC fence that will be signaled when all framebuffers present on the\nAtomic Commit * request for that given CRTC are scanned out on the\nscreen.\n\nThe Atomic Commit request fails if a invalid pointer is passed. If the\nAtomic Commit request fails for any other reason the out fence fd\nreturned will be -1. On a Atomic Commit with the\nDRM_MODE_ATOMIC_TEST_ONLY flag the out fence will also be set to -1.\n\nNote that out-fences don't have a special interface to drivers and are\ninternally represented by a &struct drm_pending_vblank_event in struct\n&drm_crtc_state, which is also used by the nonblocking atomic commit\nhelpers and for the DRM event handling for existing userspace.",
}

A drmdoc/generate.go => drmdoc/generate.go +170 -0
@@ 0,0 1,170 @@
//+build ignore

package main

import (
	"bufio"
	"bytes"
	"fmt"
	"log"
	"net/http"
	"os"
	"strings"
	"unicode"
)

const baseURL = "https://cgit.freedesktop.org/drm-tip/plain"

func fetchDoc(filename, header string) (string, error) {
	resp, err := http.Get(baseURL + "/" + filename)
	if err != nil {
		return "", err
	}
	defer resp.Body.Close()

	scanner := bufio.NewScanner(resp.Body)
	inDocComment := false
	isDocHeader := false
	found := false
	var sb strings.Builder
	for scanner.Scan() {
		l := scanner.Text()
		if inDocComment {
			l = strings.TrimPrefix(l, " * ")
			if strings.Contains(l, "*/") {
				inDocComment = false
				if found {
					break
				}
			} else if isDocHeader {
				isDocHeader = false
				if strings.TrimSpace(l) == "DOC: "+header {
					found = true
				}
			} else if found {
				l = strings.TrimPrefix(l, " *")
				sb.WriteString(l + "\n")
			}
		} else if l == "/**" {
			inDocComment = true
			isDocHeader = true
		}
	}
	if err := scanner.Err(); err != nil {
		return "", err
	}
	if !found {
		return "", fmt.Errorf("doc comment %q not found", header)
	}
	return sb.String(), nil
}

func parseProps(s string) map[string]string {
	lines := strings.Split(s, "\n")
	m := make(map[string]string)
	var header, indent string
	var body strings.Builder
	for _, l := range lines {
		if len(l) > 0 && !unicode.IsSpace(rune(l[0])) && strings.HasSuffix(l, ":") {
			bodyStr := strings.TrimSpace(body.String())
			if bodyStr != "" {
				m[header] = bodyStr
			}
			body.Reset()
			if i := strings.Index(l, "("); i >= 0 {
				l = l[:i] // Strip comments in parentheses
			}
			header = strings.Trim(l, " :\"“”")
			indent = ""
			continue
		}
		if header == "" {
			continue
		}

		if indent == "" {
			for _, ch := range l {
				if !unicode.IsSpace(ch) {
					break
				}
				indent += string(ch)
			}
		}

		body.WriteString(strings.TrimPrefix(l, indent) + "\n")
	}
	bodyStr := strings.TrimSpace(body.String())
	if bodyStr != "" {
		m[header] = bodyStr
	}

	return m
}

func titleToFilename(title string) string {
	fields := strings.Fields(title)
	return strings.ToLower(strings.Join(fields, "-"))
}

func titleToSymbol(title string) string {
	fields := strings.Fields(title)
	var sym string
	for i, s := range fields {
		if i == 0 {
			s = strings.ToLower(s)
		} else {
			s = strings.Title(s)
		}
		sym += s
	}
	return sym
}

func main() {
	if len(os.Args) < 3 {
		fmt.Println("usage: generate <filename> <header> [title]")
		os.Exit(1)
	}
	filename := os.Args[1]
	header := os.Args[2]
	outTitle := header
	if len(os.Args) > 3 {
		outTitle = os.Args[3]
	}

	doc, err := fetchDoc(filename, header)
	if err != nil {
		log.Fatal(err)
	}

	props := parseProps(doc)

	symbol := titleToSymbol(outTitle)

	var out bytes.Buffer
	out.WriteString(`// Code generated by running "go generate". DO NOT EDIT.

package drmdoc

var ` + symbol + ` = map[string]string{
`)

	for name, desc := range props {
		fmt.Fprintf(&out, "\t%q: %q,\n", name, desc)
	}

	out.WriteString("}\n")

	f, err := os.Create(titleToFilename(outTitle) + ".go")
	if err != nil {
		log.Fatal(err)
	}
	defer f.Close()

	if _, err := f.Write(out.Bytes()); err != nil {
		log.Fatal(err)
	}
	if err := f.Close(); err != nil {
		log.Fatal(err)
	}
}

A drmdoc/hdmi-connector-properties.go => drmdoc/hdmi-connector-properties.go +7 -0
@@ 0,0 1,7 @@
// Code generated by running "go generate". DO NOT EDIT.

package drmdoc

var hdmiConnectorProperties = map[string]string{
	"content type": "Indicates content type setting to be used in HDMI infoframes to indicate\ncontent type for the external device, so that it adjusts its display\nsettings accordingly.\n\nThe value of this property can be one of the following:\n\nNo Data:\n\tContent type is unknown\nGraphics:\n\tContent type is graphics\nPhoto:\n\tContent type is photo\nCinema:\n\tContent type is cinema\nGame:\n\tContent type is game\n\nDrivers can set up this property by calling\ndrm_connector_attach_content_type_property(). Decoding to\ninfoframe values is done through drm_hdmi_avi_infoframe_content_type().",
}

A drmdoc/plane-blending-properties.go => drmdoc/plane-blending-properties.go +21 -0
@@ 0,0 1,21 @@
// Code generated by running "go generate". DO NOT EDIT.

package drmdoc

var planeBlendingProperties = map[string]string{
	"IN_FORMATS":       "Blob property which contains the set of buffer format and modifier\npairs supported by this plane. The blob is a drm_format_modifier_blob\nstruct. Without this property the plane doesn't support buffers with\nmodifiers. Userspace cannot change this property.\n\nNote that all the property extensions described here apply either to the\nplane or the CRTC (e.g. for the background color, which currently is not\nexposed and assumed to be black).",
	"SRC_X":            "X coordinate offset for the source rectangle within the\n&drm_framebuffer, in 16.16 fixed point. Must be positive.",
	"alpha":            "Alpha is setup with drm_plane_create_alpha_property(). It controls the\nplane-wide opacity, from transparent (0) to opaque (0xffff). It can be\ncombined with pixel alpha.\nThe pixel values in the framebuffers are expected to not be\npre-multiplied by the global alpha associated to the plane.",
	"rotation":         "Rotation is set up with drm_plane_create_rotation_property(). It adds a\nrotation and reflection step between the source and destination rectangles.\nWithout this property the rectangle is only scaled, but not rotated or\nreflected.\n\nPossbile values:\n\n\"rotate-<degrees>\":\n\tSignals that a drm plane is rotated <degrees> degrees in counter\n\tclockwise direction.\n\n\"reflect-<axis>\":\n\tSignals that the contents of a drm plane is reflected along the\n\t<axis> axis, in the same way as mirroring.\n\nreflect-x::\n\n\t\t|o |    | o|\n\t\t|  | -> |  |\n\t\t| v|    |v |\n\nreflect-y::\n\n\t\t|o |    | ^|\n\t\t|  | -> |  |\n\t\t| v|    |o |",
	"CRTC_X":           "X coordinate offset for the destination rectangle. Can be negative.",
	"pixel blend mode": "Pixel blend mode is set up with drm_plane_create_blend_mode_property().\nIt adds a blend mode for alpha blending equation selection, describing\nhow the pixels from the current plane are composited with the\nbackground.\n\n Three alpha blending equations are defined:\n\n \"None\":\n\t Blend formula that ignores the pixel alpha::\n\n\t\t out.rgb = plane_alpha * fg.rgb +\n\t\t\t (1 - plane_alpha) * bg.rgb\n\n \"Pre-multiplied\":\n\t Blend formula that assumes the pixel color values\n\t have been already pre-multiplied with the alpha\n\t channel values::\n\n\t\t out.rgb = plane_alpha * fg.rgb +\n\t\t\t (1 - (plane_alpha * fg.alpha)) * bg.rgb\n\n \"Coverage\":\n\t Blend formula that assumes the pixel color values have not\n\t been pre-multiplied and will do so when blending them to the\n\t background color values::\n\n\t\t out.rgb = plane_alpha * fg.alpha * fg.rgb +\n\t\t\t (1 - (plane_alpha * fg.alpha)) * bg.rgb\n\n Using the following symbols:\n\n \"fg.rgb\":\n\t Each of the RGB component values from the plane's pixel\n \"fg.alpha\":\n\t Alpha component value from the plane's pixel. If the plane's\n\t pixel format has no alpha component, then this is assumed to be\n\t 1.0. In these cases, this property has no effect, as all three\n\t equations become equivalent.\n \"bg.rgb\":\n\t Each of the RGB component values from the background\n \"plane_alpha\":\n\t Plane alpha value set by the plane \"alpha\" property. If the\n\t plane does not expose the \"alpha\" property, then this is\n\t assumed to be 1.0",
	"SRC_Y":            "Y coordinate offset for the source rectangle within the\n&drm_framebuffer, in 16.16 fixed point. Must be positive.",
	"SRC_W":            "Width for the source rectangle within the &drm_framebuffer, in 16.16\nfixed point. SRC_X plus SRC_W must be within the width of the source\nframebuffer. Must be positive.",
	"SRC_H":            "Height for the source rectangle within the &drm_framebuffer, in 16.16\nfixed point. SRC_Y plus SRC_H must be within the height of the source\nframebuffer. Must be positive.",
	"CRTC_W":           "Width for the destination rectangle. CRTC_X plus CRTC_W can extend past\nthe currently visible horizontal area of the &drm_crtc.",
	"CRTC_ID":          "Mode object ID of the &drm_crtc this plane should be connected to.\n\nNote that the source rectangle must fully lie within the bounds of the\n&drm_framebuffer. The destination rectangle can lie outside of the visible\narea of the current mode of the CRTC. It must be apprpriately clipped by the\ndriver, which can be done by calling drm_plane_helper_check_update(). Drivers\nare also allowed to round the subpixel sampling positions appropriately, but\nonly to the next full pixel. No pixel outside of the source rectangle may\never be sampled, which is important when applying more sophisticated\nfiltering than just a bilinear one when scaling. The filtering mode when\nscaling is unspecified.\n\nOn top of this basic transformation additional properties can be exposed by",
	"zpos":             "Z position is set up with drm_plane_create_zpos_immutable_property() and\ndrm_plane_create_zpos_property(). It controls the visibility of overlapping\nplanes. Without this property the primary plane is always below the cursor\nplane, and ordering between all other planes is undefined. The positive\nZ axis points towards the user, i.e. planes with lower Z position values\nare underneath planes with higher Z position values. Two planes with the\nsame Z position value have undefined ordering. Note that the Z position\nvalue can also be immutable, to inform userspace about the hard-coded\nstacking of planes, see drm_plane_create_zpos_immutable_property(). If\nany plane has a zpos property (either mutable or immutable), then all\nplanes shall have a zpos property.",
	"CRTC_Y":           "Y coordinate offset for the destination rectangle. Can be negative.",
	"CRTC_H":           "Height for the destination rectangle. CRTC_Y plus CRTC_H can extend past\nthe currently visible vertical area of the &drm_crtc.",
	"FB_ID":            "Mode object ID of the &drm_framebuffer this plane should scan out.",
}

A drmdoc/standard-connector-properties.go => drmdoc/standard-connector-properties.go +20 -0
@@ 0,0 1,20 @@
// Code generated by running "go generate". DO NOT EDIT.

package drmdoc

var standardConnectorProperties = map[string]string{
	"CRTC_ID":             "Mode object ID of the &drm_crtc this connector should be connected to.",
	"panel orientation":   "On some devices the LCD panel is mounted in the casing in such a way\nthat the up/top side of the panel does not match with the top side of\nthe device. Userspace can use this property to check for this.\nNote that input coordinates from touchscreens (input devices with\nINPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel\ncoordinates, so if userspace rotates the picture to adjust for\nthe orientation it must also apply the same transformation to the\ntouchscreen input coordinates. This property is initialized by calling\ndrm_connector_set_panel_orientation() or\ndrm_connector_set_panel_orientation_with_quirk()",
	"scaling mode":        "This property defines how a non-native mode is upscaled to the native\nmode of an LCD panel:\n\nNone:\n\tNo upscaling happens, scaling is left to the panel. Not all\n\tdrivers expose this mode.\nFull:\n\tThe output is upscaled to the full resolution of the panel,\n\tignoring the aspect ratio.\nCenter:\n\tNo upscaling happens, the output is centered within the native\n\tresolution the panel.\nFull aspect:\n\tThe output is upscaled to maximize either the width or height\n\twhile retaining the aspect ratio.\n\nThis property should be set up by calling\ndrm_connector_attach_scaling_mode_property(). Note that drivers\ncan also expose this property to external outputs, in which case they\nmust support \"None\", which should be the default (since external screens\nhave a built-in scaler).",
	"TILE":                "Connector tile group property to indicate how a set of DRM connector\ncompose together into one logical screen. This is used by both high-res\nexternal screens (often only using a single cable, but exposing multiple\nDP MST sinks), or high-res integrated panels (like dual-link DSI) which\nare not gen-locked. Note that for tiled panels which are genlocked, like\ndual-link LVDS or dual-link DSI, the driver should try to not expose the\ntiling and virtualise both &drm_crtc and &drm_plane if needed. Drivers\nshould update this value using drm_connector_set_tile_property().\nUserspace cannot change this property.",
	"non_desktop":         "Indicates the output should be ignored for purposes of displaying a\nstandard desktop environment or console. This is most likely because\nthe output device is not rectilinear.",
	"link-status":         "Connector link-status property to indicate the status of link. The\ndefault value of link-status is \"GOOD\". If something fails during or\nafter modeset, the kernel driver may set this to \"BAD\" and issue a\nhotplug uevent. Drivers should update this value using\ndrm_connector_set_link_status_property().\n\nWhen user-space receives the hotplug uevent and detects a \"BAD\"\nlink-status, the sink doesn't receive pixels anymore (e.g. the screen\nbecomes completely black). The list of available modes may have\nchanged. User-space is expected to pick a new mode if the current one\nhas disappeared and perform a new modeset with link-status set to\n\"GOOD\" to re-enable the connector.\n\nIf multiple connectors share the same CRTC and one of them gets a \"BAD\"\nlink-status, the other are unaffected (ie. the sinks still continue to\nreceive pixels).\n\nWhen user-space performs an atomic commit on a connector with a \"BAD\"\nlink-status without resetting the property to \"GOOD\", the sink may\nstill not receive pixels. When user-space performs an atomic commit\nwhich resets the link-status property to \"GOOD\" without the\nALLOW_MODESET flag set, it might fail because a modeset is required.\n\nUser-space can only change link-status to \"GOOD\", changing it to \"BAD\"\nis a no-op.\n\nFor backwards compatibility with non-atomic userspace the kernel\ntries to automatically set the link-status back to \"GOOD\" in the\nSETCRTC IOCTL. This might fail if the mode is no longer valid, similar\nto how it might fail if a different screen has been connected in the\ninterim.",
	"EDID":                "Blob property which contains the current EDID read from the sink. This\nis useful to parse sink identification information like vendor, model\nand serial. Drivers should update this property by calling\ndrm_connector_update_edid_property(), usually after having parsed\nthe EDID using drm_add_edid_modes(). Userspace cannot change this\nproperty.",
	"DPMS":                "Legacy property for setting the power state of the connector. For atomic\ndrivers this is only provided for backwards compatibility with existing\ndrivers, it remaps to controlling the \"ACTIVE\" property on the CRTC the\nconnector is linked to. Drivers should never set this property directly,\nit is handled by the DRM core by calling the &drm_connector_funcs.dpms\ncallback. For atomic drivers the remapping to the \"ACTIVE\" property is\nimplemented in the DRM core.\n\nNote that this property cannot be set through the MODE_ATOMIC ioctl,\nuserspace must use \"ACTIVE\" on the CRTC instead.\n\nWARNING:\n\nFor userspace also running on legacy drivers the \"DPMS\" semantics are a\nlot more complicated. First, userspace cannot rely on the \"DPMS\" value\nreturned by the GETCONNECTOR actually reflecting reality, because many\ndrivers fail to update it. For atomic drivers this is taken care of in\ndrm_atomic_helper_update_legacy_modeset_state().\n\nThe second issue is that the DPMS state is only well-defined when the\nconnector is connected to a CRTC. In atomic the DRM core enforces that\n\"ACTIVE\" is off in such a case, no such checks exists for \"DPMS\".\n\nFinally, when enabling an output using the legacy SETCONFIG ioctl then\n\"DPMS\" is forced to ON. But see above, that might not be reflected in\nthe software value on legacy drivers.\n\nSummarizing: Only set \"DPMS\" when the connector is known to be enabled,\nassume that a successful SETCONFIG call also sets \"DPMS\" to on, and\nnever read back the value of \"DPMS\" because it can be incorrect.",
	"HDR_OUTPUT_METADATA": "Connector property to enable userspace to send HDR Metadata to\ndriver. This metadata is based on the composition and blending\npolicies decided by user, taking into account the hardware and\nsink capabilities. The driver gets this metadata and creates a\nDynamic Range and Mastering Infoframe (DRM) in case of HDMI,\nSDP packet (Non-audio INFOFRAME SDP v1.3) for DP. This is then\nsent to sink. This notifies the sink of the upcoming frame's Color\nEncoding and Luminance parameters.\n\nUserspace first need to detect the HDR capabilities of sink by\nreading and parsing the EDID. Details of HDR metadata for HDMI\nare added in CTA 861.G spec. For DP , its defined in VESA DP\nStandard v1.4. It needs to then get the metadata information\nof the video/game/app content which are encoded in HDR (basically\nusing HDR transfer functions). With this information it needs to\ndecide on a blending policy and compose the relevant\nlayers/overlays into a common format. Once this blending is done,\nuserspace will be aware of the metadata of the composed frame to\nbe send to sink. It then uses this property to communicate this\nmetadata to driver which then make a Infoframe packet and sends\nto sink based on the type of encoder connected.\n\nUserspace will be responsible to do Tone mapping operation in case:\n\t- Some layers are HDR and others are SDR\n\t- HDR layers luminance is not same as sink\n\nIt will even need to do colorspace conversion and get all layers\nto one common colorspace for blending. It can use either GL, Media\nor display engine to get this done based on the capabilities of the\nassociated hardware.\n\nDriver expects metadata to be put in &struct hdr_output_metadata\nstructure from userspace. This is received as blob and stored in\n&drm_connector_state.hdr_output_metadata. It parses EDID and saves the\nsink metadata in &struct hdr_sink_metadata, as\n&drm_connector.hdr_sink_metadata.  Driver uses\ndrm_hdmi_infoframe_set_hdr_metadata() helper to set the HDR metadata,\nhdmi_drm_infoframe_pack() to pack the infoframe as per spec, in case of\nHDMI encoder.",
	"HDCP Content Type":   "This Enum property is used by the userspace to declare the content type\nof the display stream, to kernel. Here display stream stands for any\ndisplay content that userspace intended to display through HDCP\nencryption.\n\nContent Type of a stream is decided by the owner of the stream, as\n\"HDCP Type0\" or \"HDCP Type1\".\n\nThe value of the property can be one of the below:\n  - \"HDCP Type0\": DRM_MODE_HDCP_CONTENT_TYPE0 = 0\n  - \"HDCP Type1\": DRM_MODE_HDCP_CONTENT_TYPE1 = 1\n\nWhen kernel starts the HDCP authentication (see \"Content Protection\"\nfor details), it uses the content type in \"HDCP Content Type\"\nfor performing the HDCP authentication with the display sink.\n\nPlease note in HDCP spec versions, a link can be authenticated with\nHDCP 2.2 for Content Type 0/Content Type 1. Where as a link can be\nauthenticated with HDCP1.4 only for Content Type 0(though it is implicit\nin nature. As there is no reference for Content Type in HDCP1.4).\n\nHDCP2.2 authentication protocol itself takes the \"Content Type\" as a\nparameter, which is a input for the DP HDCP2.2 encryption algo.\n\nIn case of Type 0 content protection request, kernel driver can choose\neither of HDCP spec versions 1.4 and 2.2. When HDCP2.2 is used for\n\"HDCP Type 0\", a HDCP 2.2 capable repeater in the downstream can send\nthat content to a HDCP 1.4 authenticated HDCP sink (Type0 link).\nBut if the content is classified as \"HDCP Type 1\", above mentioned\nHDCP 2.2 repeater wont send the content to the HDCP sink as it can't\nauthenticate the HDCP1.4 capable sink for \"HDCP Type 1\".\n\nPlease note userspace can be ignorant of the HDCP versions used by the\nkernel driver to achieve the \"HDCP Content Type\".\n\nAt current scenario, classifying a content as Type 1 ensures that the\ncontent will be displayed only through the HDCP2.2 encrypted link.\n\nNote that the HDCP Content Type property is introduced at HDCP 2.2, and\ndefaults to type 0. It is only exposed by drivers supporting HDCP 2.2\n(hence supporting Type 0 and Type 1). Based on how next versions of\nHDCP specs are defined content Type could be used for higher versions\ntoo.\n\nIf content type is changed when \"Content Protection\" is not UNDESIRED,\nthen kernel will disable the HDCP and re-enable with new type in the\nsame atomic commit. And when \"Content Protection\" is ENABLED, it means\nthat link is HDCP authenticated and encrypted, for the transmission of\nthe Type of stream mentioned at \"HDCP Content Type\".",
	"max bpc":             "This range property is used by userspace to limit the bit depth. When\nused the driver would limit the bpc in accordance with the valid range\nsupported by the hardware and sink. Drivers to use the function\ndrm_connector_attach_max_bpc_property() to create and attach the\nproperty to the connector during initialization.",
	"subconnector":        "This property is used by DVI-I, TVout and DisplayPort to indicate different\nconnector subtypes. Enum values more or less match with those from main\nconnector types.\nFor DVI-I and TVout there is also a matching property \"select subconnector\"\nallowing to switch between signal types.\nDP subconnector corresponds to a downstream port.",
	"PATH":                "Connector path property to identify how this sink is physically\nconnected. Used by DP MST. This should be set by calling\ndrm_connector_set_path_property(), in the case of DP MST with the\npath property the MST manager created. Userspace cannot change this\nproperty.",
	"Content Protection":  "This property is used by userspace to request the kernel protect future\ncontent communicated over the link. When requested, kernel will apply\nthe appropriate means of protection (most often HDCP), and use the\nproperty to tell userspace the protection is active.\n\nDrivers can set this up by calling\ndrm_connector_attach_content_protection_property() on initialization.\n\nThe value of this property can be one of the following:\n\nDRM_MODE_CONTENT_PROTECTION_UNDESIRED = 0\n\tThe link is not protected, content is transmitted in the clear.\nDRM_MODE_CONTENT_PROTECTION_DESIRED = 1\n\tUserspace has requested content protection, but the link is not\n\tcurrently protected. When in this state, kernel should enable\n\tContent Protection as soon as possible.\nDRM_MODE_CONTENT_PROTECTION_ENABLED = 2\n\tUserspace has requested content protection, and the link is\n\tprotected. Only the driver can set the property to this value.\n\tIf userspace attempts to set to ENABLED, kernel will return\n\t-EINVAL.\n\nA few guidelines:\n\n- DESIRED state should be preserved until userspace de-asserts it by\n  setting the property to UNDESIRED. This means ENABLED should only\n  transition to UNDESIRED when the user explicitly requests it.\n- If the state is DESIRED, kernel should attempt to re-authenticate the\n  link whenever possible. This includes across disable/enable, dpms,\n  hotplug, downstream device changes, link status failures, etc..\n- Kernel sends uevent with the connector id and property id through\n  @drm_hdcp_update_content_protection, upon below kernel triggered\n  scenarios:\n\n\t- DESIRED -> ENABLED (authentication success)\n\t- ENABLED -> DESIRED (termination of authentication)\n- Please note no uevents for userspace triggered property state changes,\n  which can't fail such as\n\n\t- DESIRED/ENABLED -> UNDESIRED\n\t- UNDESIRED -> DESIRED\n- Userspace is responsible for polling the property or listen to uevents\n  to determine when the value transitions from ENABLED to DESIRED.\n  This signifies the link is no longer protected and userspace should\n  take appropriate action (whatever that might be).",
}

A drmdoc/standard-crtc-properties.go => drmdoc/standard-crtc-properties.go +8 -0
@@ 0,0 1,8 @@
// Code generated by running "go generate". DO NOT EDIT.

package drmdoc

var standardCRTCProperties = map[string]string{
	"ACTIVE":  "Atomic property for setting the power state of the CRTC. When set to 1\nthe CRTC will actively display content. When set to 0 the CRTC will be\npowered off. There is no expectation that user-space will reset CRTC\nresources like the mode and planes when setting ACTIVE to 0.\n\nUser-space can rely on an ACTIVE change to 1 to never fail an atomic\ntest as long as no other property has changed. If a change to ACTIVE\nfails an atomic test, this is a driver bug. For this reason setting\nACTIVE to 0 must not release internal resources (like reserved memory\nbandwidth or clock generators).\n\nNote that the legacy DPMS property on connectors is internally routed\nto control this property for atomic drivers.",
	"MODE_ID": "Atomic property for setting the CRTC display timings. The value is the\nID of a blob containing the DRM mode info. To disable the CRTC,\nuser-space must set this property to 0.\n\nSetting MODE_ID to 0 will release reserved resources for the CRTC.",
}

A drmdoc/variable-refresh-properties.go => drmdoc/variable-refresh-properties.go +8 -0
@@ 0,0 1,8 @@
// Code generated by running "go generate". DO NOT EDIT.

package drmdoc

var variableRefreshProperties = map[string]string{
	"vrr_capable": "Optional &drm_connector boolean property that drivers should attach\nwith drm_connector_attach_vrr_capable_property() on connectors that\ncould support variable refresh rates. Drivers should update the\nproperty value by calling drm_connector_set_vrr_capable_property().\n\nAbsence of the property should indicate absence of support.",
	"VRR_ENABLED": "Default &drm_crtc boolean property that notifies the driver that the\ncontent on the CRTC is suitable for variable refresh rate presentation.\nThe driver will take this property as a hint to enable variable\nrefresh rate support if the receiver supports it, ie. if the\n\"vrr_capable\" property is true on the &drm_connector object. The\nvertical front porch duration will be extended until page-flip or\ntimeout when enabled.\n\nThe minimum vertical front porch duration is defined as the vertical\nfront porch duration for the current mode.\n\nThe maximum vertical front porch duration is greater than or equal to\nthe minimum vertical front porch duration. The duration is derived\nfrom the minimum supported variable refresh rate for the connector.\n\nThe driver may place further restrictions within these minimum\nand maximum bounds.",
}