drm-kms.7.rst 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229
  1. =======
  2. drm-kms
  3. =======
  4. -------------------
  5. Kernel Mode-Setting
  6. -------------------
  7. :Date: September 2012
  8. :Manual section: 7
  9. :Manual group: Direct Rendering Manager
  10. Synopsis
  11. ========
  12. ``#include <xf86drm.h>``
  13. ``#include <xf86drmMode.h>``
  14. Description
  15. ===========
  16. Each DRM device provides access to manage which monitors and displays are
  17. currently used and what frames to be displayed. This task is called *Kernel
  18. Mode-Setting* (KMS). Historically, this was done in user-space and called
  19. *User-space Mode-Setting* (UMS). Almost all open-source drivers now provide the
  20. KMS kernel API to do this in the kernel, however, many non-open-source binary
  21. drivers from different vendors still do not support this. You can use
  22. **drmModeSettingSupported**\ (3) to check whether your driver supports this. To
  23. understand how KMS works, we need to introduce 5 objects: *CRTCs*, *Planes*,
  24. *Encoders*, *Connectors* and *Framebuffers*.
  25. CRTCs
  26. A *CRTC* short for *CRT Controller* is an abstraction representing a part of
  27. the chip that contains a pointer to a scanout buffer. Therefore, the number
  28. of CRTCs available determines how many independent scanout buffers can be
  29. active at any given time. The CRTC structure contains several fields to
  30. support this: a pointer to some video memory (abstracted as a frame-buffer
  31. object), a list of driven connectors, a display mode and an (x, y) offset
  32. into the video memory to support panning or configurations where one piece
  33. of video memory spans multiple CRTCs. A CRTC is the central point where
  34. configuration of displays happens. You select which objects to use, which
  35. modes and which parameters and then configure each CRTC via
  36. **drmModeCrtcSet**\ (3) to drive the display devices.
  37. Planes
  38. A *plane* respresents an image source that can be blended with or overlayed
  39. on top of a CRTC during the scanout process. Planes are associated with a
  40. frame-buffer to crop a portion of the image memory (source) and optionally
  41. scale it to a destination size. The result is then blended with or overlayed
  42. on top of a CRTC. Planes are not provided by all hardware and the number of
  43. available planes is limited. If planes are not available or if not enough
  44. planes are available, the user should fall back to normal software blending
  45. (via GPU or CPU).
  46. Encoders
  47. An *encoder* takes pixel data from a CRTC and converts it to a format
  48. suitable for any attached connectors. On some devices, it may be possible to
  49. have a CRTC send data to more than one encoder. In that case, both encoders
  50. would receive data from the same scanout buffer, resulting in a *cloned*
  51. display configuration across the connectors attached to each encoder.
  52. Connectors
  53. A *connector* is the final destination of pixel-data on a device, and
  54. usually connects directly to an external display device like a monitor or
  55. laptop panel. A connector can only be attached to one encoder at a time. The
  56. connector is also the structure where information about the attached display
  57. is kept, so it contains fields for display data, *EDID* data, *DPMS* and
  58. *connection status*, and information about modes supported on the attached
  59. displays.
  60. Framebuffers
  61. *Framebuffers* are abstract memory objects that provide a source of pixel
  62. data to scanout to a CRTC. Applications explicitly request the creation of
  63. framebuffers and can control their behavior. Framebuffers rely on the
  64. underneath memory manager for low-level memory operations. When creating a
  65. framebuffer, applications pass a memory handle through the API which is used
  66. as backing storage. The framebuffer itself is only an abstract object with
  67. no data. It just refers to memory buffers that must be created with the
  68. **drm-memory**\ (7) API.
  69. Mode-Setting
  70. ------------
  71. Before mode-setting can be performed, an application needs to call
  72. **drmSetMaster**\ (3) to become *DRM-Master*. It then has exclusive access to
  73. the KMS API. A call to **drmModeGetResources**\ (3) returns a list of *CRTCs*,
  74. *Connectors*, *Encoders* and *Planes*.
  75. Normal procedure now includes: First, you select which connectors you want to
  76. use. Users are mostly interested in which monitor or display-panel is active so
  77. you need to make sure to arrange them in the correct logical order and select
  78. the correct ones to use. For each connector, you need to find a CRTC to drive
  79. this connector. If you want to clone output to two or more connectors, you may
  80. use a single CRTC for all cloned connectors (if the hardware supports this). To
  81. find a suitable CRTC, you need to iterate over the list of encoders that are
  82. available for each connector. Each encoder contains a list of CRTCs that it can
  83. work with and you simply select one of these CRTCs. If you later program the
  84. CRTC to control a connector, it automatically selects the best encoder.
  85. However, this procedure is needed so your CRTC has at least one working encoder
  86. for the selected connector. See the *Examples* section below for more
  87. information.
  88. All valid modes for a connector can be retrieved with a call to
  89. **drmModeGetConnector**\ (3) You need to select the mode you want to use and save it.
  90. The first mode in the list is the default mode with the highest resolution
  91. possible and often a suitable choice.
  92. After you have a working connector+CRTC+mode combination, you need to create a
  93. framebuffer that is used for scanout. Memory buffer allocation is
  94. driver-dependent and described in **drm-memory**\ (7). You need to create a
  95. buffer big enough for your selected mode. Now you can create a framebuffer
  96. object that uses your memory-buffer as scanout buffer. You can do this with
  97. **drmModeAddFB**\ (3) and **drmModeAddFB2**\ (3).
  98. As a last step, you want to program your CRTC to drive your selected connector.
  99. You can do this with a call to **drmModeSetCrtc**\ (3).
  100. Page-Flipping
  101. -------------
  102. A call to **drmModeSetCrtc**\ (3) is executed immediately and forces the CRTC
  103. to use the new scanout buffer. If you want smooth-transitions without tearing,
  104. you probably use double-buffering. You need to create one framebuffer object
  105. for each buffer you use. You can then call **drmModeSetCrtc**\ (3) on the next
  106. buffer to flip. If you want to synchronize your flips with *vertical-blanks*,
  107. you can use **drmModePageFlip**\ (3) which schedules your page-flip for the
  108. next *vblank*.
  109. Planes
  110. ------
  111. Planes are controlled independently from CRTCs. That is, a call to
  112. **drmModeSetCrtc**\ (3) does not affect planes. Instead, you need to call
  113. **drmModeSetPlane**\ (3) to configure a plane. This requires the plane ID, a
  114. CRTC, a framebuffer and offsets into the plane-framebuffer and the
  115. CRTC-framebuffer. The CRTC then blends the content from the plane over the CRTC
  116. framebuffer buffer during scanout. As this does not involve any
  117. software-blending, it is way faster than traditional blending. However, plane
  118. resources are limited. See **drmModeGetPlaneResources**\ (3) for more
  119. information.
  120. Cursors
  121. -------
  122. Similar to planes, many hardware also supports cursors. A cursor is a very
  123. small buffer with an image that is blended over the CRTC framebuffer. You can
  124. set a different cursor for each CRTC with **drmModeSetCursor**\ (3) and move it
  125. on the screen with **drmModeMoveCursor**\ (3). This allows to move the cursor
  126. on the screen without rerendering. If no hardware cursors are supported, you
  127. need to rerender for each frame the cursor is moved.
  128. Examples
  129. ========
  130. Some examples of how basic mode-setting can be done. See the man-page of each
  131. DRM function for more information.
  132. CRTC/Encoder Selection
  133. ----------------------
  134. If you retrieved all display configuration information via
  135. **drmModeGetResources**\ (3) as ``drmModeRes *res``, selected a connector from
  136. the list in ``res->connectors`` and retrieved the connector-information as
  137. ``drmModeConnector *conn`` via **drmModeGetConnector**\ (3) then this example
  138. shows, how you can find a suitable CRTC id to drive this connector. This
  139. function takes a file-descriptor to the DRM device (see **drmOpen**\ (3)) as
  140. ``fd``, a pointer to the retrieved resources as ``res`` and a pointer to the
  141. selected connector as ``conn``. It returns an integer smaller than 0 on
  142. failure, otherwise, a valid CRTC id is returned.
  143. ::
  144. static int modeset_find_crtc(int fd, drmModeRes *res, drmModeConnector *conn)
  145. {
  146. drmModeEncoder *enc;
  147. unsigned int i, j;
  148. /* iterate all encoders of this connector */
  149. for (i = 0; i < conn->count_encoders; ++i) {
  150. enc = drmModeGetEncoder(fd, conn->encoders[i]);
  151. if (!enc) {
  152. /* cannot retrieve encoder, ignoring... */
  153. continue;
  154. }
  155. /* iterate all global CRTCs */
  156. for (j = 0; j < res->count_crtcs; ++j) {
  157. /* check whether this CRTC works with the encoder */
  158. if (!(enc->possible_crtcs & (1 << j)))
  159. continue;
  160. /* Here you need to check that no other connector
  161. * currently uses the CRTC with id "crtc". If you intend
  162. * to drive one connector only, then you can skip this
  163. * step. Otherwise, simply scan your list of configured
  164. * connectors and CRTCs whether this CRTC is already
  165. * used. If it is, then simply continue the search here. */
  166. if (res->crtcs[j] "is unused") {
  167. drmModeFreeEncoder(enc);
  168. return res->crtcs[j];
  169. }
  170. }
  171. drmModeFreeEncoder(enc);
  172. }
  173. /* cannot find a suitable CRTC */
  174. return -ENOENT;
  175. }
  176. Reporting Bugs
  177. ==============
  178. Bugs in this manual should be reported to
  179. https://gitlab.freedesktop.org/mesa/libdrm/-/issues
  180. See Also
  181. ========
  182. **drm**\ (7), **drm-memory**\ (7), **drmModeGetResources**\ (3),
  183. **drmModeGetConnector**\ (3), **drmModeGetEncoder**\ (3),
  184. **drmModeGetCrtc**\ (3), **drmModeSetCrtc**\ (3), **drmModeGetFB**\ (3),
  185. **drmModeAddFB**\ (3), **drmModeAddFB2**\ (3), **drmModeRmFB**\ (3),
  186. **drmModePageFlip**\ (3), **drmModeGetPlaneResources**\ (3),
  187. **drmModeGetPlane**\ (3), **drmModeSetPlane**\ (3), **drmModeSetCursor**\ (3),
  188. **drmModeMoveCursor**\ (3), **drmSetMaster**\ (3), **drmAvailable**\ (3),
  189. **drmCheckModesettingSupported**\ (3), **drmOpen**\ (3)