Kernel Mode Setting (KMS)¶
Drivers must initialize the mode setting core by calling
drm_mode_config_init()
on the DRM device. The function
initializes the struct drm_device
mode_config field and never fails. Once done, mode configuration must
be setup by initializing the following fields.
- int min_width, min_height; int max_width, max_height; Minimum and maximum width and height of the frame buffers in pixel units.
- struct drm_mode_config_funcs *funcs; Mode setting functions.
Overview¶
KMS Display Pipeline Overview
The basic object structure KMS presents to userspace is fairly simple.
Framebuffers (represented by struct drm_framebuffer
,
see Frame Buffer Abstraction) feed into planes. One or more (or even no)
planes feed their pixel data into a CRTC (represented by struct
drm_crtc
, see CRTC Abstraction) for blending. The precise
blending step is explained in more detail in Plane Composition Properties and
related chapters.
For the output routing the first step is encoders (represented by
struct drm_encoder
, see Encoder Abstraction). Those
are really just internal artifacts of the helper libraries used to implement KMS
drivers. Besides that they make it unecessarily more complicated for userspace
to figure out which connections between a CRTC and a connector are possible, and
what kind of cloning is supported, they serve no purpose in the userspace API.
Unfortunately encoders have been exposed to userspace, hence can’t remove them
at this point. Futhermore the exposed restrictions are often wrongly set by
drivers, and in many cases not powerful enough to express the real restrictions.
A CRTC can be connected to multiple encoders, and for an active CRTC there must
be at least one encoder.
The final, and real, endpoint in the display chain is the connector (represented
by struct drm_connector
, see Connector
Abstraction). Connectors can have different possible encoders, but the kernel
driver selects which encoder to use for each connector. The use case is DVI,
which could switch between an analog and a digital encoder. Encoders can also
drive multiple different connectors. There is exactly one active connector for
every active encoder.
Internally the output pipeline is a bit more complex and matches today’s hardware more closely:
KMS Output Pipeline
Internally two additional helper objects come into play. First, to be able to
share code for encoders (sometimes on the same SoC, sometimes off-chip) one or
more Bridges (represented by struct drm_bridge
) can be linked to an encoder. This link is static and cannot be
changed, which means the cross-bar (if there is any) needs to be mapped between
the CRTC and any encoders. Often for drivers with bridges there’s no code left
at the encoder level. Atomic drivers can leave out all the encoder callbacks to
essentially only leave a dummy routing object behind, which is needed for
backwards compatibility since encoders are exposed to userspace.
The second object is for panels, represented by struct drm_panel
, see Panel Helper Reference. Panels do not have a fixed binding
point, but are generally linked to the driver private structure that embeds
struct drm_connector
.
Note that currently the bridge chaining and interactions with connectors and panels are still in-flux and not really fully sorted out yet.
Modeset Base Object Abstraction¶
Mode Objects and Properties
The base structure for all KMS objects is struct drm_mode_object
. One of the base services it provides is tracking properties,
which are especially important for the atomic IOCTL (see Atomic Mode
Setting). The somewhat surprising part here is that properties are not
directly instantiated on each object, but free-standing mode objects themselves,
represented by struct drm_property
, which only specify
the type and value range of a property. Any given property can be attached
multiple times to different objects using drm_object_attach_property()
.
Error
kernel-doc missing
Error
kernel-doc missing
Atomic Mode Setting¶
Mode Objects and Properties
Atomic provides transactional modeset (including planes) updates, but a bit differently from the usual transactional approach of try-commit and rollback:
- Firstly, no hardware changes are allowed when the commit would fail. This allows us to implement the DRM_MODE_ATOMIC_TEST_ONLY mode, which allows userspace to explore whether certain configurations would work or not.
- This would still allow setting and rollback of just the software state, simplifying conversion of existing drivers. But auditing drivers for correctness of the atomic_check code becomes really hard with that: Rolling back changes in data structures all over the place is hard to get right.
- Lastly, for backwards compatibility and to support all use-cases, atomic updates need to be incremental and be able to execute in parallel. Hardware doesn’t always allow it, but where possible plane updates on different CRTCs should not interfere, and not get stalled due to output routing changing on different CRTCs.
Taken all together there’s two consequences for the atomic design:
- The overall state is split up into per-object state structures:
struct drm_plane_state
for planes,struct drm_crtc_state
for CRTCs andstruct drm_connector_state
for connectors. These are the only objects with userspace-visible and settable state. For internal state drivers can subclass these structures through embeddeding, or add entirely new state structures for their globally shared hardware functions. - An atomic update is assembled and validated as an entirely free-standing pile
of structures within the
drm_atomic_state
container. Driver private state structures are also tracked in the same structure; see the next chapter. Only when a state is committed is it applied to the driver and modeset objects. This way rolling back an update boils down to releasing memory and unreferencing objects like framebuffers.
Read on in this chapter, and also in Atomic Modeset Helper Functions Reference for more detailed coverage of specific topics.
Handling Driver Private State¶
Error
kernel-doc missing
Atomic Mode Setting Function Reference¶
Error
kernel-doc missing
Error
kernel-doc missing
Error
kernel-doc missing
CRTC Abstraction¶
Error
kernel-doc missing
Frame Buffer Abstraction¶
Error
kernel-doc missing
Dumb Buffer Objects¶
Error
kernel-doc missing
Plane Abstraction¶
Error
kernel-doc missing
Connector Abstraction¶
Error
kernel-doc missing
Encoder Abstraction¶
Error
kernel-doc missing
KMS Initialization and Cleanup¶
A KMS device is abstracted and exposed as a set of planes, CRTCs, encoders and connectors. KMS drivers must thus create and initialize all those objects at load time after initializing mode setting.
CRTCs (struct drm_crtc
)¶
A CRTC is an abstraction representing a part of the chip that contains a pointer to a scanout buffer. Therefore, the number of CRTCs available determines how many independent scanout buffers can be active at any given time. The CRTC structure contains several fields to support this: a pointer to some video memory (abstracted as a frame buffer object), a display mode, and an (x, y) offset into the video memory to support panning or configurations where one piece of video memory spans multiple CRTCs.
CRTC Initialization¶
A KMS device must create and register at least one struct
struct drm_crtc
instance. The instance is
allocated and zeroed by the driver, possibly as part of a larger
structure, and registered with a call to drm_crtc_init()
with a pointer to CRTC functions.
Cleanup¶
The DRM core manages its objects’ lifetime. When an object is not needed
anymore the core calls its destroy function, which must clean up and
free every resource allocated for the object. Every
drm_*_init()
call must be matched with a corresponding
drm_*_cleanup()
call to cleanup CRTCs
(drm_crtc_cleanup()
), planes
(drm_plane_cleanup()
), encoders
(drm_encoder_cleanup()
) and connectors
(drm_connector_cleanup()
). Furthermore, connectors that
have been added to sysfs must be removed by a call to
drm_connector_unregister()
before calling
drm_connector_cleanup()
.
Connectors state change detection must be cleanup up with a call to
drm_kms_helper_poll_fini()
.
Output discovery and initialization example¶
void intel_crt_init(struct drm_device *dev)
{
struct drm_connector *connector;
struct intel_output *intel_output;
intel_output = kzalloc(sizeof(struct intel_output), GFP_KERNEL);
if (!intel_output)
return;
connector = &intel_output->base;
drm_connector_init(dev, &intel_output->base,
&intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
drm_encoder_init(dev, &intel_output->enc, &intel_crt_enc_funcs,
DRM_MODE_ENCODER_DAC);
drm_mode_connector_attach_encoder(&intel_output->base,
&intel_output->enc);
/* Set up the DDC bus. */
intel_output->ddc_bus = intel_i2c_create(dev, GPIOA, "CRTDDC_A");
if (!intel_output->ddc_bus) {
dev_printk(KERN_ERR, &dev->pdev->dev, "DDC bus registration "
"failed.\n");
return;
}
intel_output->type = INTEL_OUTPUT_ANALOG;
connector->interlace_allowed = 0;
connector->doublescan_allowed = 0;
drm_encoder_helper_add(&intel_output->enc, &intel_crt_helper_funcs);
drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs);
drm_connector_register(connector);
}
In the example above (taken from the i915 driver), a CRTC, connector and encoder combination is created. A device-specific i2c bus is also created for fetching EDID data and performing monitor detection. Once the process is complete, the new connector is registered with sysfs to make its properties available to applications.
KMS Properties¶
Property Types and Blob Property Support¶
Error
kernel-doc missing
Error
kernel-doc missing
Error
kernel-doc missing
Standard Connector Properties¶
Error
kernel-doc missing
Tile Group Property¶
Error
kernel-doc missing
Explicit Fencing Properties¶
Error
kernel-doc missing
Existing KMS Properties¶
The following table gives description of drm properties exposed by various modules/drivers. Because this table is very unwieldy, do not add any new properties here. Instead document them in a section above.
Owner Module/Drivers | Group | Property Name | Type | Property Values | Object attached | Description/Restrictions |
---|---|---|---|---|---|---|
DVI-I | “subconnector” | ENUM | { “Unknown”, “DVI-D”, “DVI-A” } | Connector | TBD | |
“select subconnector” | ENUM | { “Automatic”, “DVI-D”, “DVI-A” } | Connector | TBD | ||
TV | “subconnector” | ENUM | { “Unknown”, “Composite”, “SVIDEO”, “Component”, “SCART” } | Connector | TBD | |
“select subconnector” | ENUM | { “Automatic”, “Composite”, “SVIDEO”, “Component”, “SCART” } | Connector | TBD | ||
“mode” | ENUM | { “NTSC_M”, “NTSC_J”, “NTSC_443”, “PAL_B” } etc. | Connector | TBD | ||
“left margin” | RANGE | Min=0, Max=100 | Connector | TBD | ||
“right margin” | RANGE | Min=0, Max=100 | Connector | TBD | ||
“top margin” | RANGE | Min=0, Max=100 | Connector | TBD | ||
“bottom margin” | RANGE | Min=0, Max=100 | Connector | TBD | ||
“brightness” | RANGE | Min=0, Max=100 | Connector | TBD | ||
“contrast” | RANGE | Min=0, Max=100 | Connector | TBD | ||
“flicker reduction” | RANGE | Min=0, Max=100 | Connector | TBD | ||
“overscan” | RANGE | Min=0, Max=100 | Connector | TBD | ||
“saturation” | RANGE | Min=0, Max=100 | Connector | TBD | ||
“hue” | RANGE | Min=0, Max=100 | Connector | TBD | ||
Virtual GPU | “suggested X” | RANGE | Min=0, Max=0xffffffff | Connector | property to suggest an X offset for a connector | |
“suggested Y” | RANGE | Min=0, Max=0xffffffff | Connector | property to suggest an Y offset for a connector | ||
Optional | “aspect ratio” | ENUM | { “None”, “4:3”, “16:9” } | Connector | TDB | |
i915 | Generic | “Broadcast RGB” | ENUM | { “Automatic”, “Full”, “Limited 16:235” } | Connector | When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normaly in the range 0..1.0 are remapped to the range 16/255..235/255. |
“audio” | ENUM | { “force-dvi”, “off”, “auto”, “on” } | Connector | TBD | ||
SDVO-TV | “mode” | ENUM | { “NTSC_M”, “NTSC_J”, “NTSC_443”, “PAL_B” } etc. | Connector | TBD | |
“left_margin” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“right_margin” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“top_margin” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“bottom_margin” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“hpos” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“vpos” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“contrast” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“saturation” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“hue” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“sharpness” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“flicker_filter” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“flicker_filter_adaptive” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“flicker_filter_2d” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“tv_chroma_filter” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“tv_luma_filter” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“dot_crawl” | RANGE | Min=0, Max=1 | Connector | TBD | ||
SDVO-TV/LVDS | “brightness” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | |
CDV gma-500 | Generic | “Broadcast RGB” | ENUM | { “Full”, “Limited 16:235” } | Connector | TBD |
“Broadcast RGB” | ENUM | { “off”, “auto”, “on” } | Connector | TBD | ||
Poulsbo | Generic | “backlight” | RANGE | Min=0, Max=100 | Connector | TBD |
SDVO-TV | “mode” | ENUM | { “NTSC_M”, “NTSC_J”, “NTSC_443”, “PAL_B” } etc. | Connector | TBD | |
“left_margin” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“right_margin” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“top_margin” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“bottom_margin” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“hpos” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“vpos” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“contrast” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“saturation” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“hue” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“sharpness” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“flicker_filter” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“flicker_filter_adaptive” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“flicker_filter_2d” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“tv_chroma_filter” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“tv_luma_filter” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | ||
“dot_crawl” | RANGE | Min=0, Max=1 | Connector | TBD | ||
SDVO-TV/LVDS | “brightness” | RANGE | Min=0, Max= SDVO dependent | Connector | TBD | |
armada | CRTC | “CSC_YUV” | ENUM | { “Auto” , “CCIR601”, “CCIR709” } | CRTC | TBD |
“CSC_RGB” | ENUM | { “Auto”, “Computer system”, “Studio” } | CRTC | TBD | ||
Overlay | “colorkey” | RANGE | Min=0, Max=0xffffff | Plane | TBD | |
“colorkey_min” | RANGE | Min=0, Max=0xffffff | Plane | TBD | ||
“colorkey_max” | RANGE | Min=0, Max=0xffffff | Plane | TBD | ||
“colorkey_val” | RANGE | Min=0, Max=0xffffff | Plane | TBD | ||
“colorkey_alpha” | RANGE | Min=0, Max=0xffffff | Plane | TBD | ||
“colorkey_mode” | ENUM | { “disabled”, “Y component”, “U component” , “V component”, “RGB”, “R component”, “G component”, “B component” } | Plane | TBD | ||
“brightness” | RANGE | Min=0, Max=256 + 255 | Plane | TBD | ||
“contrast” | RANGE | Min=0, Max=0x7fff | Plane | TBD | ||
“saturation” | RANGE | Min=0, Max=0x7fff | Plane | TBD | ||
exynos | CRTC | “mode” | ENUM | { “normal”, “blank” } | CRTC | TBD |
i2c/ch7006_drv | Generic | “scale” | RANGE | Min=0, Max=2 | Connector | TBD |
TV | “mode” | ENUM | { “PAL”, “PAL-M”,”PAL-N”}, ”PAL-Nc” , “PAL-60”, “NTSC-M”, “NTSC-J” } | Connector | TBD | |
nouveau | NV10 Overlay | “colorkey” | RANGE | Min=0, Max=0x01ffffff | Plane | TBD |
“contrast” | RANGE | Min=0, Max=8192-1 | Plane | TBD | ||
“brightness” | RANGE | Min=0, Max=1024 | Plane | TBD | ||
“hue” | RANGE | Min=0, Max=359 | Plane | TBD | ||
“saturation” | RANGE | Min=0, Max=8192-1 | Plane | TBD | ||
“iturbt_709” | RANGE | Min=0, Max=1 | Plane | TBD | ||
Nv04 Overlay | “colorkey” | RANGE | Min=0, Max=0x01ffffff | Plane | TBD | |
“brightness” | RANGE | Min=0, Max=1024 | Plane | TBD | ||
Display | “dithering mode” | ENUM | { “auto”, “off”, “on” } | Connector | TBD | |
“dithering depth” | ENUM | { “auto”, “off”, “on”, “static 2x2”, “dynamic 2x2”, “temporal” } | Connector | TBD | ||
“underscan” | ENUM | { “auto”, “6 bpc”, “8 bpc” } | Connector | TBD | ||
“underscan hborder” | RANGE | Min=0, Max=128 | Connector | TBD | ||
“underscan vborder” | RANGE | Min=0, Max=128 | Connector | TBD | ||
“vibrant hue” | RANGE | Min=0, Max=180 | Connector | TBD | ||
“color vibrance” | RANGE | Min=0, Max=200 | Connector | TBD | ||
omap | Generic | “zorder” | RANGE | Min=0, Max=3 | CRTC, Plane | TBD |
qxl | Generic | “hotplug_mode_update” | RANGE | Min=0, Max=1 | Connector | TBD |
radeon | DVI-I | “coherent” | RANGE | Min=0, Max=1 | Connector | TBD |
DAC enable load detect | “load detection” | RANGE | Min=0, Max=1 | Connector | TBD | |
TV Standard | “tv standard” | ENUM | { “ntsc”, “pal”, “pal-m”, “pal-60”, “ntsc-j” , “scart-pal”, “pal-cn”, “secam” } | Connector | TBD | |
legacy TMDS PLL detect | “tmds_pll” | ENUM | { “driver”, “bios” } | TBD | ||
Underscan | “underscan” | ENUM | { “off”, “on”, “auto” } | Connector | TBD | |
“underscan hborder” | RANGE | Min=0, Max=128 | Connector | TBD | ||
“underscan vborder” | RANGE | Min=0, Max=128 | Connector | TBD | ||
Audio | “audio” | ENUM | { “off”, “on”, “auto” } | Connector | TBD | |
FMT Dithering | “dither” | ENUM | { “off”, “on” } | Connector | TBD | |
“colorkey” | RANGE | Min=0, Max=0x01ffffff | Plane | TBD |