sphinx.addnodesdocument)}( rawsourcechildren]( translations LanguagesNode)}(hhh](h pending_xref)}(hhh]docutils.nodesTextChinese (Simplified)}parenthsba attributes}(ids]classes]names]dupnames]backrefs] refdomainstdreftypedoc reftarget/translations/zh_CN/gpu/drm-kmsmodnameN classnameN refexplicitutagnamehhh ubh)}(hhh]hChinese (Traditional)}hh2sbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget/translations/zh_TW/gpu/drm-kmsmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hItalian}hhFsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget/translations/it_IT/gpu/drm-kmsmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hJapanese}hhZsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget/translations/ja_JP/gpu/drm-kmsmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hKorean}hhnsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget/translations/ko_KR/gpu/drm-kmsmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hPortuguese (Brazilian)}hhsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget/translations/pt_BR/gpu/drm-kmsmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hSpanish}hhsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget/translations/sp_SP/gpu/drm-kmsmodnameN classnameN refexplicituh1hhh ubeh}(h]h ]h"]h$]h&]current_languageEnglishuh1h hh _documenthsourceNlineNubhtarget)}(h .. _drm-kms:h]h}(h]h ]h"]h$]h&]refiddrm-kmsuh1hhKhhhhh9/var/lib/git/docbuild/linux/Documentation/gpu/drm-kms.rstubhsection)}(hhh](htitle)}(hKernel Mode Setting (KMS)h]hKernel Mode Setting (KMS)}(hhhhhNhNubah}(h]h ]h"]h$]h&]hid8uh1hhhhhhhhKubh paragraph)}(hXDrivers must initialize the mode setting core by calling drmm_mode_config_init() on the DRM device. The function initializes the :c:type:`struct drm_device ` mode_config field and never fails. Once done, mode configuration must be setup by initializing the following fields.h](hDrivers must initialize the mode setting core by calling drmm_mode_config_init() on the DRM device. The function initializes the }(hhhhhNhNubh)}(h(:c:type:`struct drm_device `h]hliteral)}(hhh]hstruct drm_device}(hhhhhNhNubah}(h]h ](xrefcc-typeeh"]h$]h&]uh1hhhubah}(h]h ]h"]h$]h&]refdoc gpu/drm-kms refdomainhreftypetype refexplicitrefwarn reftarget drm_deviceuh1hhhhKhhubhu mode_config field and never fails. Once done, mode configuration must be setup by initializing the following fields.}(hhhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh bullet_list)}(hhh](h list_item)}(hint min_width, min_height; int max_width, max_height; Minimum and maximum width and height of the frame buffers in pixel units. h]h)}(hint min_width, min_height; int max_width, max_height; Minimum and maximum width and height of the frame buffers in pixel units.h]hint min_width, min_height; int max_width, max_height; Minimum and maximum width and height of the frame buffers in pixel units.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubj)}(h>struct drm_mode_config_funcs \*funcs; Mode setting functions. h]h)}(h=struct drm_mode_config_funcs \*funcs; Mode setting functions.h]h=struct drm_mode_config_funcs *funcs; Mode setting functions.}(hj6hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj2ubah}(h]h ]h"]h$]h&]uh1jhjhhhhhNubeh}(h]h ]h"]h$]h&]bullet-uh1jhhhKhhhhubhtopic)}(h Contents h](h)}(hContentsh]hContents}(hjXhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjThhhKubj)}(hhh]j)}(hhh](h)}(hhh]h reference)}(hhh]hKernel Mode Setting (KMS)}(hjqhhhNhNubah}(h]hah ]h"]h$]h&]refidkernel-mode-setting-kmsuh1johjlubah}(h]h ]h"]h$]h&]uh1hhjiubj)}(hhh](j)}(hhh]h)}(hhh]jp)}(hhh]hOverview}(hjhhhNhNubah}(h]id9ah ]h"]h$]h&]refidoverviewuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh]h)}(hhh]jp)}(hhh]h!KMS Core Structures and Functions}(hjhhhNhNubah}(h]id10ah ]h"]h$]h&]refid!kms-core-structures-and-functionsuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh]h)}(hhh]jp)}(hhh]hModeset Base Object Abstraction}(hjhhhNhNubah}(h]id11ah ]h"]h$]h&]refidmodeset-base-object-abstractionuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh](h)}(hhh]jp)}(hhh]hAtomic Mode Setting}(hjhhhNhNubah}(h]id12ah ]h"]h$]h&]refidatomic-mode-settinguh1johjubah}(h]h ]h"]h$]h&]uh1hhjubj)}(hhh](j)}(hhh]h)}(hhh]jp)}(hhh]hAtomic State Lifetime}(hjhhhNhNubah}(h]id13ah ]h"]h$]h&]refidatomic-state-lifetimeuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhj ubj)}(hhh]h)}(hhh]jp)}(hhh]hHandling Driver Private State}(hj6hhhNhNubah}(h]id14ah ]h"]h$]h&]refidhandling-driver-private-stateuh1johj3ubah}(h]h ]h"]h$]h&]uh1hhj0ubah}(h]h ]h"]h$]h&]uh1jhj ubj)}(hhh]h)}(hhh]jp)}(hhh]h&Atomic Mode Setting Function Reference}(hjXhhhNhNubah}(h]id15ah ]h"]h$]h&]refid&atomic-mode-setting-function-referenceuh1johjUubah}(h]h ]h"]h$]h&]uh1hhjRubah}(h]h ]h"]h$]h&]uh1jhj ubj)}(hhh]h)}(hhh]jp)}(hhh]h,Atomic Mode Setting IOCTL and UAPI Functions}(hjzhhhNhNubah}(h]id16ah ]h"]h$]h&]refid,atomic-mode-setting-ioctl-and-uapi-functionsuh1johjwubah}(h]h ]h"]h$]h&]uh1hhjtubah}(h]h ]h"]h$]h&]uh1jhj ubeh}(h]h ]h"]h$]h&]uh1jhjubeh}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh](h)}(hhh]jp)}(hhh]hCRTC Abstraction}(hjhhhNhNubah}(h]id17ah ]h"]h$]h&]refidcrtc-abstractionuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubj)}(hhh](j)}(hhh]h)}(hhh]jp)}(hhh]hCRTC Functions Reference}(hjhhhNhNubah}(h]id18ah ]h"]h$]h&]refidcrtc-functions-referenceuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh]h)}(hhh]jp)}(hhh]h$Color Management Functions Reference}(hjhhhNhNubah}(h]id19ah ]h"]h$]h&]refid$color-management-functions-referenceuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjubeh}(h]h ]h"]h$]h&]uh1jhjubeh}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh](h)}(hhh]jp)}(hhh]hFrame Buffer Abstraction}(hjhhhNhNubah}(h]id20ah ]h"]h$]h&]refidframe-buffer-abstractionuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubj)}(hhh]j)}(hhh]h)}(hhh]jp)}(hhh]h Frame Buffer Functions Reference}(hj6hhhNhNubah}(h]id21ah ]h"]h$]h&]refid frame-buffer-functions-referenceuh1johj3ubah}(h]h ]h"]h$]h&]uh1hhj0ubah}(h]h ]h"]h$]h&]uh1jhj-ubah}(h]h ]h"]h$]h&]uh1jhjubeh}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh](h)}(hhh]jp)}(hhh]hDRM Format Handling}(hjdhhhNhNubah}(h]id22ah ]h"]h$]h&]refiddrm-format-handlinguh1johjaubah}(h]h ]h"]h$]h&]uh1hhj^ubj)}(hhh](j)}(hhh]h)}(hhh]jp)}(hhh]hFormat Modifiers}(hjhhhNhNubah}(h]id23ah ]h"]h$]h&]refidformat-modifiersuh1johjubah}(h]h ]h"]h$]h&]uh1hhj}ubah}(h]h ]h"]h$]h&]uh1jhjzubj)}(hhh]h)}(hhh]jp)}(hhh]hOpen Source User Waiver}(hjhhhNhNubah}(h]id24ah ]h"]h$]h&]refidopen-source-user-waiveruh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjzubj)}(hhh]h)}(hhh]jp)}(hhh]hFormat Functions Reference}(hjhhhNhNubah}(h]id25ah ]h"]h$]h&]refidformat-functions-referenceuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjzubeh}(h]h ]h"]h$]h&]uh1jhj^ubeh}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh]h)}(hhh]jp)}(hhh]hDumb Buffer Objects}(hjhhhNhNubah}(h]id26ah ]h"]h$]h&]refiddumb-buffer-objectsuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh](h)}(hhh]jp)}(hhh]hPlane Abstraction}(hjhhhNhNubah}(h]id27ah ]h"]h$]h&]refidplane-abstractionuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubj)}(hhh](j)}(hhh]h)}(hhh]jp)}(hhh]hPlane Functions Reference}(hj6hhhNhNubah}(h]id28ah ]h"]h$]h&]refidplane-functions-referenceuh1johj3ubah}(h]h ]h"]h$]h&]uh1hhj0ubah}(h]h ]h"]h$]h&]uh1jhj-ubj)}(hhh]h)}(hhh]jp)}(hhh]h%Plane Composition Functions Reference}(hjXhhhNhNubah}(h]id29ah ]h"]h$]h&]refid%plane-composition-functions-referenceuh1johjUubah}(h]h ]h"]h$]h&]uh1hhjRubah}(h]h ]h"]h$]h&]uh1jhj-ubj)}(hhh]h)}(hhh]jp)}(hhh]h)Plane Damage Tracking Functions Reference}(hjzhhhNhNubah}(h]id30ah ]h"]h$]h&]refid)plane-damage-tracking-functions-referenceuh1johjwubah}(h]h ]h"]h$]h&]uh1hhjtubah}(h]h ]h"]h$]h&]uh1jhj-ubj)}(hhh]h)}(hhh]jp)}(hhh]hPlane Panic Feature}(hjhhhNhNubah}(h]id31ah ]h"]h$]h&]refidplane-panic-featureuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhj-ubj)}(hhh]h)}(hhh]jp)}(hhh]hPlane Panic Functions Reference}(hjhhhNhNubah}(h]id32ah ]h"]h$]h&]refidplane-panic-functions-referenceuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhj-ubeh}(h]h ]h"]h$]h&]uh1jhjubeh}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh](h)}(hhh]jp)}(hhh]hColorop Abstraction}(hjhhhNhNubah}(h]id33ah ]h"]h$]h&]refidcolorop-abstractionuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubj)}(hhh]j)}(hhh]h)}(hhh]jp)}(hhh]hColorop Functions Reference}(hj hhhNhNubah}(h]id34ah ]h"]h$]h&]refidcolorop-functions-referenceuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjubah}(h]h ]h"]h$]h&]uh1jhjubeh}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh]h)}(hhh]jp)}(hhh]h Display Modes Function Reference}(hj9hhhNhNubah}(h]id35ah ]h"]h$]h&]refid display-modes-function-referenceuh1johj6ubah}(h]h ]h"]h$]h&]uh1hhj3ubah}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh](h)}(hhh]jp)}(hhh]hConnector Abstraction}(hj[hhhNhNubah}(h]id36ah ]h"]h$]h&]refidconnector-abstractionuh1johjXubah}(h]h ]h"]h$]h&]uh1hhjUubj)}(hhh](j)}(hhh]h)}(hhh]jp)}(hhh]hConnector Functions Reference}(hjzhhhNhNubah}(h]id37ah ]h"]h$]h&]refidconnector-functions-referenceuh1johjwubah}(h]h ]h"]h$]h&]uh1hhjtubah}(h]h ]h"]h$]h&]uh1jhjqubj)}(hhh]h)}(hhh]jp)}(hhh]hWriteback Connectors}(hjhhhNhNubah}(h]id38ah ]h"]h$]h&]refidwriteback-connectorsuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjqubeh}(h]h ]h"]h$]h&]uh1jhjUubeh}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh](h)}(hhh]jp)}(hhh]hEncoder Abstraction}(hjhhhNhNubah}(h]id39ah ]h"]h$]h&]refidencoder-abstractionuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubj)}(hhh]j)}(hhh]h)}(hhh]jp)}(hhh]hEncoder Functions Reference}(hjhhhNhNubah}(h]id40ah ]h"]h$]h&]refidencoder-functions-referenceuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjubah}(h]h ]h"]h$]h&]uh1jhjubeh}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh]h)}(hhh]jp)}(hhh]h KMS Locking}(hjhhhNhNubah}(h]id41ah ]h"]h$]h&]refid kms-lockinguh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh](h)}(hhh]jp)}(hhh]hKMS Properties}(hj9hhhNhNubah}(h]id42ah ]h"]h$]h&]refidkms-propertiesuh1johj6ubah}(h]h ]h"]h$]h&]uh1hhj3ubj)}(hhh](j)}(hhh]h)}(hhh]jp)}(hhh]h Requirements}(hjXhhhNhNubah}(h]id43ah ]h"]h$]h&]refid requirementsuh1johjUubah}(h]h ]h"]h$]h&]uh1hhjRubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]h(Property Types and Blob Property Support}(hjzhhhNhNubah}(h]id44ah ]h"]h$]h&]refid(property-types-and-blob-property-supportuh1johjwubah}(h]h ]h"]h$]h&]uh1hhjtubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]hStandard Connector Properties}(hjhhhNhNubah}(h]id45ah ]h"]h$]h&]refidstandard-connector-propertiesuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]h"HDMI Specific Connector Properties}(hjhhhNhNubah}(h]id46ah ]h"]h$]h&]refid"hdmi-specific-connector-propertiesuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]h'Analog TV Specific Connector Properties}(hjhhhNhNubah}(h]id47ah ]h"]h$]h&]refid'analog-tv-specific-connector-propertiesuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]hStandard CRTC Properties}(hjhhhNhNubah}(h]id48ah ]h"]h$]h&]refidstandard-crtc-propertiesuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]hStandard Plane Properties}(hj$hhhNhNubah}(h]id49ah ]h"]h$]h&]refidstandard-plane-propertiesuh1johj!ubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]hPlane Composition Properties}(hjFhhhNhNubah}(h]id50ah ]h"]h$]h&]refidplane-composition-propertiesuh1johjCubah}(h]h ]h"]h$]h&]uh1hhj@ubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]hDamage Tracking Properties}(hjhhhhNhNubah}(h]id51ah ]h"]h$]h&]refiddamage-tracking-propertiesuh1johjeubah}(h]h ]h"]h$]h&]uh1hhjbubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]hColor Management Properties}(hjhhhNhNubah}(h]id52ah ]h"]h$]h&]refidcolor-management-propertiesuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]hColor Format Property}(hjhhhNhNubah}(h]id53ah ]h"]h$]h&]refidcolor-format-propertyuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]hTile Group Property}(hjhhhNhNubah}(h]id54ah ]h"]h$]h&]refidtile-group-propertyuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]hExplicit Fencing Properties}(hjhhhNhNubah}(h]id55ah ]h"]h$]h&]refidexplicit-fencing-propertiesuh1johjubah}(h]h ]h"]h$]h&]uh1hhjubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]hVariable Refresh Properties}(hjhhhNhNubah}(h]id56ah ]h"]h$]h&]refidvariable-refresh-propertiesuh1johjubah}(h]h ]h"]h$]h&]uh1hhj ubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]hCursor Hotspot Properties}(hj4hhhNhNubah}(h]id57ah ]h"]h$]h&]refidcursor-hotspot-propertiesuh1johj1ubah}(h]h ]h"]h$]h&]uh1hhj.ubah}(h]h ]h"]h$]h&]uh1jhjOubj)}(hhh]h)}(hhh]jp)}(hhh]hExisting KMS Properties}(hjVhhhNhNubah}(h]id58ah ]h"]h$]h&]refidexisting-kms-propertiesuh1johjSubah}(h]h ]h"]h$]h&]uh1hhjPubah}(h]h ]h"]h$]h&]uh1jhjOubeh}(h]h ]h"]h$]h&]uh1jhj3ubeh}(h]h ]h"]h$]h&]uh1jhjubj)}(hhh](h)}(hhh]jp)}(hhh]hVertical Blanking}(hjhhhNhNubah}(h]id59ah ]h"]h$]h&]refidvertical-blankinguh1johjubah}(h]h ]h"]h$]h&]uh1hhj~ubj)}(hhh]j)}(hhh]h)}(hhh]jp)}(hhh]h "drm_crtc" "drm_plane B" -> "drm_crtc" "drm_crtc" -> "drm_encoder A" "drm_crtc" -> "drm_encoder B" } subgraph cluster_user_created { style=dashed label="Userspace-Created" node [shape=oval] "drm_framebuffer 1" -> "drm_plane A" "drm_framebuffer 2" -> "drm_plane B" } subgraph cluster_connector { style=dashed label="Hotpluggable" "drm_encoder A" -> "drm_connector A" "drm_encoder B" -> "drm_connector B" } }h]hXdigraph "KMS" { node [shape=box] subgraph cluster_static { style=dashed label="Static Objects" node [bgcolor=grey style=filled] "drm_plane A" -> "drm_crtc" "drm_plane B" -> "drm_crtc" "drm_crtc" -> "drm_encoder A" "drm_crtc" -> "drm_encoder B" } subgraph cluster_user_created { style=dashed label="Userspace-Created" node [shape=oval] "drm_framebuffer 1" -> "drm_plane A" "drm_framebuffer 2" -> "drm_plane B" } subgraph cluster_connector { style=dashed label="Hotpluggable" "drm_encoder A" -> "drm_connector A" "drm_encoder B" -> "drm_connector B" } }}hjQ sbah}(h]h ]h"]h$]h&] xml:spacepreserveuh1jO hjL hhubah}(h]h ]h"]h$]h&]altKMS Display PipelinesrclangDOTuh1jJ hjF ubhcaption)}(hKMS Display Pipeline Overviewh]hKMS Display Pipeline Overview}(hjm hhhNhNubah}(h]h ]h"]h$]h&]uh1jk hhhKhjF ubeh}(h]id4ah ]h"]h$]h&]altjh captionjo uh1jD hj3 hhhhhNubh)}(hXEThe basic object structure KMS presents to userspace is fairly simple. Framebuffers (represented by :c:type:`struct drm_framebuffer `, see `Frame Buffer Abstraction`_) feed into planes. Planes are represented by :c:type:`struct drm_plane `, see `Plane Abstraction`_ for more details. One or more (or even no) planes feed their pixel data into a CRTC (represented by :c:type:`struct drm_crtc `, see `CRTC Abstraction`_) for blending. The precise blending step is explained in more detail in `Plane Composition Properties`_ and related chapters.h](hdThe basic object structure KMS presents to userspace is fairly simple. Framebuffers (represented by }(hj hhhNhNubh)}(h2:c:type:`struct drm_framebuffer `h]h)}(hj h]hstruct drm_framebuffer}(hj hhhNhNubah}(h]h ](hhc-typeeh"]h$]h&]uh1hhj ubah}(h]h ]h"]h$]h&]refdocj refdomainhreftypetype refexplicitrefwarnjdrm_framebufferuh1hhhhK>hj ubh, see }(hj hhhNhNubjp)}(h`Frame Buffer Abstraction`_h]hFrame Buffer Abstraction}(hj hhhNhNubah}(h]h ]h"]h$]h&]nameFrame Buffer Abstractionhj&uh1johj resolvedKubh.) feed into planes. Planes are represented by }(hj hhhNhNubh)}(h&:c:type:`struct drm_plane `h]h)}(hj h]hstruct drm_plane}(hj hhhNhNubah}(h]h ](hhc-typeeh"]h$]h&]uh1hhj ubah}(h]h ]h"]h$]h&]refdocj refdomainhreftypetype refexplicitrefwarnj drm_planeuh1hhhhK>hj ubh, see }(hj hhhNhNubjp)}(h`Plane Abstraction`_h]hPlane Abstraction}(hj hhhNhNubah}(h]h ]h"]h$]h&]namePlane Abstractionhj&uh1johj j Kubhe for more details. One or more (or even no) planes feed their pixel data into a CRTC (represented by }(hj hhhNhNubh)}(h$:c:type:`struct drm_crtc `h]h)}(hj h]hstruct drm_crtc}(hj hhhNhNubah}(h]h ](hhc-typeeh"]h$]h&]uh1hhj ubah}(h]h ]h"]h$]h&]refdocj refdomainhreftypetype refexplicitrefwarnjdrm_crtcuh1hhhhK>hj ubh, see }hj sbjp)}(h`CRTC Abstraction`_h]hCRTC Abstraction}(hj hhhNhNubah}(h]h ]h"]h$]h&]nameCRTC Abstractionhjuh1johj j KubhI) for blending. The precise blending step is explained in more detail in }(hj hhhNhNubjp)}(h`Plane Composition Properties`_h]hPlane Composition Properties}(hj2 hhhNhNubah}(h]h ]h"]h$]h&]namePlane Composition Propertieshid2uh1johj j Kubh and related chapters.}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhK>hj3 hhubh)}(hX(For the output routing the first step is encoders (represented by :c:type:`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 unnecessarily 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. Furthermore 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.h](hBFor the output routing the first step is encoders (represented by }(hjM hhhNhNubh)}(h*:c:type:`struct drm_encoder `h]h)}(hjW h]hstruct drm_encoder}(hjY hhhNhNubah}(h]h ](hhc-typeeh"]h$]h&]uh1hhjU ubah}(h]h ]h"]h$]h&]refdocj refdomainhreftypetype refexplicitrefwarnj drm_encoderuh1hhhhKGhjM ubh, see }(hjM hhhNhNubjp)}(h`Encoder Abstraction`_h]hEncoder Abstraction}(hjx hhhNhNubah}(h]h ]h"]h$]h&]nameEncoder Abstractionhjuh1johjM j KubhX). Those are really just internal artifacts of the helper libraries used to implement KMS drivers. Besides that they make it unnecessarily 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. Furthermore 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.}(hjM hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKGhj3 hhubh)}(hXThe final, and real, endpoint in the display chain is the connector (represented by :c:type:`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.h](hTThe final, and real, endpoint in the display chain is the connector (represented by }(hj hhhNhNubh)}(h.:c:type:`struct drm_connector `h]h)}(hj h]hstruct drm_connector}(hj hhhNhNubah}(h]h ](hhc-typeeh"]h$]h&]uh1hhj ubah}(h]h ]h"]h$]h&]refdocj refdomainhreftypetype refexplicitrefwarnj drm_connectoruh1hhhhKShj ubh, see }(hj hhhNhNubjp)}(h`Connector Abstraction`_h]hConnector Abstraction}(hj hhhNhNubah}(h]h ]h"]h$]h&]nameConnector Abstractionhjjuh1johj j KubhXB). 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.}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKShj3 hhubh)}(h_Internally the output pipeline is a bit more complex and matches today's hardware more closely:h]haInternally the output pipeline is a bit more complex and matches today’s hardware more closely:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK[hj3 hhubjE )}(hhh](jK )}(hhh]jP )}(hXvdigraph "Output Pipeline" { node [shape=box] subgraph { "drm_crtc" [bgcolor=grey style=filled] } subgraph cluster_internal { style=dashed label="Internal Pipeline" { node [bgcolor=grey style=filled] "drm_encoder A"; "drm_encoder B"; "drm_encoder C"; } { node [bgcolor=grey style=filled] "drm_encoder B" -> "drm_bridge B" "drm_encoder C" -> "drm_bridge C1" "drm_bridge C1" -> "drm_bridge C2"; } } "drm_crtc" -> "drm_encoder A" "drm_crtc" -> "drm_encoder B" "drm_crtc" -> "drm_encoder C" subgraph cluster_output { style=dashed label="Outputs" "drm_encoder A" -> "drm_connector A"; "drm_bridge B" -> "drm_connector B"; "drm_bridge C2" -> "drm_connector C"; "drm_panel" } }h]hXvdigraph "Output Pipeline" { node [shape=box] subgraph { "drm_crtc" [bgcolor=grey style=filled] } subgraph cluster_internal { style=dashed label="Internal Pipeline" { node [bgcolor=grey style=filled] "drm_encoder A"; "drm_encoder B"; "drm_encoder C"; } { node [bgcolor=grey style=filled] "drm_encoder B" -> "drm_bridge B" "drm_encoder C" -> "drm_bridge C1" "drm_bridge C1" -> "drm_bridge C2"; } } "drm_crtc" -> "drm_encoder A" "drm_crtc" -> "drm_encoder B" "drm_crtc" -> "drm_encoder C" subgraph cluster_output { style=dashed label="Outputs" "drm_encoder A" -> "drm_connector A"; "drm_bridge B" -> "drm_connector B"; "drm_bridge C2" -> "drm_connector C"; "drm_panel" } }}hj sbah}(h]h ]h"]h$]h&]j_ j` uh1jO hj hhubah}(h]h ]h"]h$]h&]jg KMS Output Pipelineji DOTuh1jJ hj ubjl )}(hKMS Output Pipelineh]hKMS Output Pipeline}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jk hhhKhj ubeh}(h]id5ah ]h"]h$]h&]altj captionj uh1jD hj3 hhhhhNubh)}(hXInternally 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 :ref:`drm_bridges` (represented by :c:type:`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.h](hInternally 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 }(hj hhhNhNubh)}(h:ref:`drm_bridges`h]hinline)}(hj" h]h drm_bridges}(hj& hhhNhNubah}(h]h ](hstdstd-refeh"]h$]h&]uh1j$ hj ubah}(h]h ]h"]h$]h&]refdocj refdomainj0 reftyperef refexplicitrefwarnj drm_bridgesuh1hhhhKhj ubh (represented by }(hj hhhNhNubh)}(h(:c:type:`struct drm_bridge `h]h)}(hjH h]hstruct drm_bridge}(hjJ hhhNhNubah}(h]h ](hhc-typeeh"]h$]h&]uh1hhjF ubah}(h]h ]h"]h$]h&]refdocj refdomainhreftypetype refexplicitrefwarnj drm_bridgeuh1hhhhKhj ubhX) 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.}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhj3 hhubh)}(hXThe second object is for panels, represented by :c:type:`struct drm_panel `, see :ref:`drm_panel_helper`. Panels do not have a fixed binding point, but are generally linked to the driver private structure that embeds :c:type:`struct drm_connector `.h](h0The second object is for panels, represented by }(hjo hhhNhNubh)}(h&:c:type:`struct drm_panel `h]h)}(hjy h]hstruct drm_panel}(hj{ hhhNhNubah}(h]h ](hhc-typeeh"]h$]h&]uh1hhjw ubah}(h]h ]h"]h$]h&]refdocj refdomainhreftypetype refexplicitrefwarnj drm_paneluh1hhhhKhjo ubh, see }(hjo hhhNhNubh)}(h:ref:`drm_panel_helper`h]j% )}(hj h]hdrm_panel_helper}(hj hhhNhNubah}(h]h ](hstdstd-refeh"]h$]h&]uh1j$ hj ubah}(h]h ]h"]h$]h&]refdocj refdomainj reftyperef refexplicitrefwarnjdrm_panel_helperuh1hhhhKhjo ubhq. Panels do not have a fixed binding point, but are generally linked to the driver private structure that embeds }(hjo hhhNhNubh)}(h.:c:type:`struct drm_connector `h]h)}(hj h]hstruct drm_connector}(hj hhhNhNubah}(h]h ](hhc-typeeh"]h$]h&]uh1hhj ubah}(h]h ]h"]h$]h&]refdocj refdomainhreftypetype refexplicitrefwarnj drm_connectoruh1hhhhKhjo ubh.}(hjo hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhj3 hhubh)}(hNote that currently the bridge chaining and interactions with connectors and panels are still in-flux and not really fully sorted out yet.h]hNote that currently the bridge chaining and interactions with connectors and panels are still in-flux and not really fully sorted out yet.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhj3 hhubeh}(h]jah ]h"]overviewah$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(h!KMS Core Structures and Functionsh]h!KMS Core Structures and Functions}(hj hhhNhNubah}(h]h ]h"]h$]h&]hjuh1hhj hhhhhKubhindex)}(hhh]h}(h]h ]h"]h$]h&]entries](single drm_mode_config_funcs (C struct)c.drm_mode_config_funcshNtauh1j hj hhhNhNubhdesc)}(hhh](hdesc_signature)}(hdrm_mode_config_funcsh]hdesc_signature_line)}(hstruct drm_mode_config_funcsh](hdesc_sig_keyword)}(hstructh]hstruct}(hj1 hhhNhNubah}(h]h ]kah"]h$]h&]uh1j/ hj+ hhhZ/var/lib/git/docbuild/linux/Documentation/gpu/drm-kms:161: ./include/drm/drm_mode_config.hhKubhdesc_sig_space)}(h h]h }(hjC hhhNhNubah}(h]h ]wah"]h$]h&]uh1jA hj+ hhhj@ hKubh desc_name)}(hdrm_mode_config_funcsh]h desc_sig_name)}(hj' h]hdrm_mode_config_funcs}(hjZ hhhNhNubah}(h]h ]nah"]h$]h&]uh1jX hjT ubah}(h]h ](sig-namedescnameeh"]h$]h&]j_ j` uh1jR hj+ hhhj@ hKubeh}(h]h ]h"]h$]h&]j_ j` add_permalinkuh1j) sphinx_line_type declaratorhj% hhhj@ hKubah}(h]j ah ](sig sig-objecteh"]h$]h&] is_multiline _toc_parts) _toc_namehuh1j# hj@ hKhj hhubh desc_content)}(hhh]h)}(h,basic driver provided mode setting functionsh]h,basic driver provided mode setting functions}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhZ/var/lib/git/docbuild/linux/Documentation/gpu/drm-kms:161: ./include/drm/drm_mode_config.hhK*hj hhubah}(h]h ]h"]h$]h&]uh1j hj hhhj@ hKubeh}(h]h ](hstructeh"]h$]h&]domainhobjtypej desctypej noindex noindexentrynocontentsentryuh1j hhhj hNhNubh container)}(hX!-**Definition**:: struct drm_mode_config_funcs { struct drm_framebuffer *(*fb_create)(struct drm_device *dev, struct drm_file *file_priv, const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd); const struct drm_format_info *(*get_format_info)(u32 pixel_format, u64 modifier); enum drm_mode_status (*mode_valid)(struct drm_device *dev, const struct drm_display_mode *mode); int (*atomic_check)(struct drm_device *dev, struct drm_atomic_commit *state); int (*atomic_commit)(struct drm_device *dev, struct drm_atomic_commit *state, bool nonblock); struct drm_atomic_commit *(*atomic_state_alloc)(struct drm_device *dev); void (*atomic_state_clear)(struct drm_atomic_commit *state); void (*atomic_state_free)(struct drm_atomic_commit *state); }; **Members** ``fb_create`` Create a new framebuffer object. The core does basic checks on the requested metadata, but most of that is left to the driver. See :c:type:`struct drm_mode_fb_cmd2 ` for details. To validate the pixel format and modifier drivers can use drm_any_plane_has_format() to make sure at least one plane supports the requested values. Note that the driver must first determine the actual modifier used if the request doesn't have it specified, ie. when (**mode_cmd->flags** & DRM_MODE_FB_MODIFIERS) == 0. IMPORTANT: These implied modifiers for legacy userspace must be stored in struct :c:type:`drm_framebuffer`, including all relevant metadata like :c:type:`drm_framebuffer.pitches ` and :c:type:`drm_framebuffer.offsets ` if the modifier enables additional planes beyond the fourcc pixel format code. This is required by the GETFB2 ioctl. If the parameters are deemed valid and the backing storage objects in the underlying memory manager all exist, then the driver allocates a new :c:type:`drm_framebuffer` structure, subclassed to contain driver-specific information (like the internal native buffer object references). It also needs to fill out all relevant metadata, which should be done by calling drm_helper_mode_fill_fb_struct(). The initialization is finalized by calling drm_framebuffer_init(), which registers the framebuffer and makes it accessible to other threads. RETURNS: A new framebuffer with an initial reference count of 1 or a negative error code encoded with ERR_PTR(). ``get_format_info`` Allows a driver to return custom format information for special fb layouts (eg. ones with auxiliary compression control planes). RETURNS: The format information specific to the given fb metadata, or NULL if none is found. ``mode_valid`` Device specific validation of display modes. Can be used to reject modes that can never be supported. Only device wide constraints can be checked here. crtc/encoder/bridge/connector specific constraints should be checked in the .mode_valid() hook for each specific object. ``atomic_check`` This is the only hook to validate an atomic modeset update. This function must reject any modeset and state changes which the hardware or driver doesn't support. This includes but is of course not limited to: - Checking that the modes, framebuffers, scaling and placement requirements and so on are within the limits of the hardware. - Checking that any hidden shared resources are not oversubscribed. This can be shared PLLs, shared lanes, overall memory bandwidth, display fifo space (where shared between planes or maybe even CRTCs). - Checking that virtualized resources exported to userspace are not oversubscribed. For various reasons it can make sense to expose more planes, crtcs or encoders than which are physically there. One example is dual-pipe operations (which generally should be hidden from userspace if when lockstepped in hardware, exposed otherwise), where a plane might need 1 hardware plane (if it's just on one pipe), 2 hardware planes (when it spans both pipes) or maybe even shared a hardware plane with a 2nd plane (if there's a compatible plane requested on the area handled by the other pipe). - Check that any transitional state is possible and that if requested, the update can indeed be done in the vblank period without temporarily disabling some functions. - Check any other constraints the driver or hardware might have. - This callback also needs to correctly fill out the :c:type:`drm_crtc_state` in this update to make sure that drm_atomic_crtc_needs_modeset() reflects the nature of the possible update and returns true if and only if the update cannot be applied without tearing within one vblank on that CRTC. The core uses that information to reject updates which require a full modeset (i.e. blanking the screen, or at least pausing updates for a substantial amount of time) if userspace has disallowed that in its request. - The driver also does not need to repeat basic input validation like done for the corresponding legacy entry points. The core does that before calling this hook. See the documentation of **atomic_commit** for an exhaustive list of error conditions which don't have to be checked at the in this callback. See the documentation for :c:type:`struct drm_atomic_commit ` for how exactly an atomic modeset update is described. Drivers using the atomic helpers can implement this hook using drm_atomic_helper_check(), or one of the exported sub-functions of it. RETURNS: 0 on success or one of the below negative error codes: - -EINVAL, if any of the above constraints are violated. - -EDEADLK, when returned from an attempt to acquire an additional :c:type:`drm_modeset_lock` through drm_modeset_lock(). - -ENOMEM, if allocating additional state sub-structures failed due to lack of memory. - -EINTR, -EAGAIN or -ERESTARTSYS, if the IOCTL should be restarted. This can either be due to a pending signal, or because the driver needs to completely bail out to recover from an exceptional situation like a GPU hang. From a userspace point all errors are treated equally. ``atomic_commit`` This is the only hook to commit an atomic modeset update. The core guarantees that **atomic_check** has been called successfully before calling this function, and that nothing has been changed in the interim. See the documentation for :c:type:`struct drm_atomic_commit ` for how exactly an atomic modeset update is described. Drivers using the atomic helpers can implement this hook using drm_atomic_helper_commit(), or one of the exported sub-functions of it. Nonblocking commits (as indicated with the nonblock parameter) must do any preparatory work which might result in an unsuccessful commit in the context of this callback. The only exceptions are hardware errors resulting in -EIO. But even in that case the driver must ensure that the display pipe is at least running, to avoid compositors crashing when pageflips don't work. Anything else, specifically committing the update to the hardware, should be done without blocking the caller. For updates which do not require a modeset this must be guaranteed. The driver must wait for any pending rendering to the new framebuffers to complete before executing the flip. It should also wait for any pending rendering from other drivers if the underlying buffer is a shared dma-buf. Nonblocking commits must not wait for rendering in the context of this callback. An application can request to be notified when the atomic commit has completed. These events are per-CRTC and can be distinguished by the CRTC index supplied in :c:type:`drm_event` to userspace. The drm core will supply a :c:type:`struct drm_event ` in each CRTC's :c:type:`drm_crtc_state.event `. See the documentation for :c:type:`drm_crtc_state.event ` for more details about the precise semantics of this event. NOTE: Drivers are not allowed to shut down any display pipe successfully enabled through an atomic commit on their own. Doing so can result in compositors crashing if a page flip is suddenly rejected because the pipe is off. RETURNS: 0 on success or one of the below negative error codes: - -EBUSY, if a nonblocking updated is requested and there is an earlier updated pending. Drivers are allowed to support a queue of outstanding updates, but currently no driver supports that. Note that drivers must wait for preceding updates to complete if a synchronous update is requested, they are not allowed to fail the commit in that case. - -ENOMEM, if the driver failed to allocate memory. Specifically this can happen when trying to pin framebuffers, which must only be done when committing the state. - -ENOSPC, as a refinement of the more generic -ENOMEM to indicate that the driver has run out of vram, iommu space or similar GPU address space needed for framebuffer. - -EIO, if the hardware completely died. - -EINTR, -EAGAIN or -ERESTARTSYS, if the IOCTL should be restarted. This can either be due to a pending signal, or because the driver needs to completely bail out to recover from an exceptional situation like a GPU hang. From a userspace point of view all errors are treated equally. This list is exhaustive. Specifically this hook is not allowed to return -EINVAL (any invalid requests should be caught in **atomic_check**) or -EDEADLK (this function must not acquire additional modeset locks). ``atomic_state_alloc`` This optional hook can be used by drivers that want to subclass struct :c:type:`drm_atomic_commit` to be able to track their own driver-private global state easily. If this hook is implemented, drivers must also implement **atomic_state_clear** and **atomic_state_free**. Subclassing of :c:type:`drm_atomic_commit` is deprecated in favour of using :c:type:`drm_private_state` and :c:type:`drm_private_obj`. RETURNS: A new :c:type:`drm_atomic_commit` on success or NULL on failure. ``atomic_state_clear`` This hook must clear any driver private state duplicated into the passed-in :c:type:`drm_atomic_commit`. This hook is called when the caller encountered a :c:type:`drm_modeset_lock` deadlock and needs to drop all already acquired locks as part of the deadlock avoidance dance implemented in drm_modeset_backoff(). Any duplicated state must be invalidated since a concurrent atomic update might change it, and the drm atomic interfaces always apply updates as relative changes to the current state. Drivers that implement this must call drm_atomic_commit_default_clear() to clear common state. Subclassing of :c:type:`drm_atomic_commit` is deprecated in favour of using :c:type:`drm_private_state` and :c:type:`drm_private_obj`. ``atomic_state_free`` This hook needs driver private resources and the :c:type:`drm_atomic_commit` itself. Note that the core first calls drm_atomic_commit_clear() to avoid code duplicate between the clear and free hooks. Drivers that implement this must call drm_atomic_commit_default_release() to release common resources. Subclassing of :c:type:`drm_atomic_commit` is deprecated in favour of using :c:type:`drm_private_state` and :c:type:`drm_private_obj`.h](h)}(h**Definition**::h](hstrong)}(h**Definition**h]h Definition}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1j hj ubh:}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhZ/var/lib/git/docbuild/linux/Documentation/gpu/drm-kms:161: ./include/drm/drm_mode_config.hhK.hj ubjP )}(hX struct drm_mode_config_funcs { struct drm_framebuffer *(*fb_create)(struct drm_device *dev, struct drm_file *file_priv, const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd); const struct drm_format_info *(*get_format_info)(u32 pixel_format, u64 modifier); enum drm_mode_status (*mode_valid)(struct drm_device *dev, const struct drm_display_mode *mode); int (*atomic_check)(struct drm_device *dev, struct drm_atomic_commit *state); int (*atomic_commit)(struct drm_device *dev, struct drm_atomic_commit *state, bool nonblock); struct drm_atomic_commit *(*atomic_state_alloc)(struct drm_device *dev); void (*atomic_state_clear)(struct drm_atomic_commit *state); void (*atomic_state_free)(struct drm_atomic_commit *state); };h]hX struct drm_mode_config_funcs { struct drm_framebuffer *(*fb_create)(struct drm_device *dev, struct drm_file *file_priv, const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd); const struct drm_format_info *(*get_format_info)(u32 pixel_format, u64 modifier); enum drm_mode_status (*mode_valid)(struct drm_device *dev, const struct drm_display_mode *mode); int (*atomic_check)(struct drm_device *dev, struct drm_atomic_commit *state); int (*atomic_commit)(struct drm_device *dev, struct drm_atomic_commit *state, bool nonblock); struct drm_atomic_commit *(*atomic_state_alloc)(struct drm_device *dev); void (*atomic_state_clear)(struct drm_atomic_commit *state); void (*atomic_state_free)(struct drm_atomic_commit *state); };}hj sbah}(h]h ]h"]h$]h&]j_ j` uh1jO hZ/var/lib/git/docbuild/linux/Documentation/gpu/drm-kms:161: ./include/drm/drm_mode_config.hhK0hj ubh)}(h **Members**h]j )}(hj h]hMembers}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1j hj ubah}(h]h ]h"]h$]h&]uh1hhZ/var/lib/git/docbuild/linux/Documentation/gpu/drm-kms:161: ./include/drm/drm_mode_config.hhK;hj ubhdefinition_list)}(hhh](hdefinition_list_item)}(hX``fb_create`` Create a new framebuffer object. The core does basic checks on the requested metadata, but most of that is left to the driver. See :c:type:`struct drm_mode_fb_cmd2 ` for details. To validate the pixel format and modifier drivers can use drm_any_plane_has_format() to make sure at least one plane supports the requested values. Note that the driver must first determine the actual modifier used if the request doesn't have it specified, ie. when (**mode_cmd->flags** & DRM_MODE_FB_MODIFIERS) == 0. IMPORTANT: These implied modifiers for legacy userspace must be stored in struct :c:type:`drm_framebuffer`, including all relevant metadata like :c:type:`drm_framebuffer.pitches ` and :c:type:`drm_framebuffer.offsets ` if the modifier enables additional planes beyond the fourcc pixel format code. This is required by the GETFB2 ioctl. If the parameters are deemed valid and the backing storage objects in the underlying memory manager all exist, then the driver allocates a new :c:type:`drm_framebuffer` structure, subclassed to contain driver-specific information (like the internal native buffer object references). It also needs to fill out all relevant metadata, which should be done by calling drm_helper_mode_fill_fb_struct(). The initialization is finalized by calling drm_framebuffer_init(), which registers the framebuffer and makes it accessible to other threads. RETURNS: A new framebuffer with an initial reference count of 1 or a negative error code encoded with ERR_PTR(). h](hterm)}(h ``fb_create``h]h)}(hj h]h fb_create}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj ubah}(h]h ]h"]h$]h&]uh1j hZ/var/lib/git/docbuild/linux/Documentation/gpu/drm-kms:161: ./include/drm/drm_mode_config.hhKPhj ubh definition)}(hhh](h)}(hCreate a new framebuffer object. The core does basic checks on the requested metadata, but most of that is left to the driver. See :c:type:`struct drm_mode_fb_cmd2 ` for details.h](hCreate a new framebuffer object. The core does basic checks on the requested metadata, but most of that is left to the driver. See }(hj! hhhNhNubh)}(h4:c:type:`struct drm_mode_fb_cmd2 `h]h)}(hj+ h]hstruct drm_mode_fb_cmd2}(hj- hhhNhNubah}(h]h ](hhc-typeeh"]h$]h&]uh1hhj) ubah}(h]h ]h"]h$]h&]refdocj refdomainhreftypetype refexplicitrefwarn c:parent_keysphinx.domains.c LookupKey)}data]sbjdrm_mode_fb_cmd2uh1hhZ/var/lib/git/docbuild/linux/Documentation/gpu/drm-kms:161: ./include/drm/drm_mode_config.hhK2hj! ubh for details.}(hj! hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhjP hK2hj ubh)}(hX=To validate the pixel format and modifier drivers can use drm_any_plane_has_format() to make sure at least one plane supports the requested values. Note that the driver must first determine the actual modifier used if the request doesn't have it specified, ie. when (**mode_cmd->flags** & DRM_MODE_FB_MODIFIERS) == 0.h](hX To validate the pixel format and modifier drivers can use drm_any_plane_has_format() to make sure at least one plane supports the requested values. Note that the driver must first determine the actual modifier used if the request doesn’t have it specified, ie. when (}(hj[ hhhNhNubj )}(h**mode_cmd->flags**h]hmode_cmd->flags}(hjc hhhNhNubah}(h]h ]h"]h$]h&]uh1j hj[ ubh & DRM_MODE_FB_MODIFIERS) == 0.}(hj[ hhhNhNubeh}(h]h ]h"]h$]h&]uh1hhZ/var/lib/git/docbuild/linux/Documentation/gpu/drm-kms:161: ./include/drm/drm_mode_config.hhK6hj ubh)}(hXqIMPORTANT: These implied modifiers for legacy userspace must be stored in struct :c:type:`drm_framebuffer`, including all relevant metadata like :c:type:`drm_framebuffer.pitches ` and :c:type:`drm_framebuffer.offsets ` if the modifier enables additional planes beyond the fourcc pixel format code. This is required by the GETFB2 ioctl.h](hQIMPORTANT: These implied modifiers for legacy userspace must be stored in struct }(hj| hhhNhNubh)}(h:c:type:`drm_framebuffer`h]h)}(hj h]hdrm_framebuffer}(hj hhhNhNubah}(h]h ](hhc-typeeh"]h$]h&]uh1hhj ubah}(h]h ]h"]h$]h&]refdocj refdomainhreftypetype refexplicitrefwarnjG jK jdrm_framebufferuh1hhZ/var/lib/git/docbuild/linux/Documentation/gpu/drm-kms:161: ./include/drm/drm_mode_config.hhK`h]h)}(hj h]hdrm_framebuffer.pitches}(hj hhhNhNubah}(h]h ](hhc-typeeh"]h$]h&]uh1hhj ubah}(h]h ]h"]h$]h&]refdocj refdomainhreftypetype refexplicitrefwarnjG jK jdrm_framebufferuh1hhj hK`h]h)}(hj h]hdrm_framebuffer.offsets}(hj hhhNhNubah}(h]h ](hhc-typeeh"]h$]h&]uh1hhj ubah}(h]h ]h"]h$]h&]refdocj refdomainhreftypetype refexplicitrefwarnjG jK jdrm_framebufferuh1hhj hK