Kernel Mode Setting (KMS)
=========================
-Mode Setting
-============
-
Drivers must initialize the mode setting core by calling
:c:func:`drm_mode_config_init()` on the DRM device. The function
initializes the :c:type:`struct drm_device <drm_device>`
- struct drm_mode_config_funcs \*funcs;
Mode setting functions.
-Display Modes Function Reference
---------------------------------
+KMS Data Structures
+===================
-.. kernel-doc:: include/drm/drm_modes.h
+.. kernel-doc:: include/drm/drm_crtc.h
:internal:
-.. kernel-doc:: drivers/gpu/drm/drm_modes.c
+KMS API Functions
+=================
+
+.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
:export:
Atomic Mode Setting Function Reference
---------------------------------------
+======================================
.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
:export:
-.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
+.. kernel-doc:: include/drm/drm_atomic.h
:internal:
Frame Buffer Abstraction
-------------------------
-
-Frame buffers are abstract memory objects that provide a source of
-pixels to scanout to a CRTC. Applications explicitly request the
-creation of frame buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls
-and receive an opaque handle that can be passed to the KMS CRTC control,
-plane configuration and page flip functions.
-
-Frame buffers rely on the underneath memory manager for low-level memory
-operations. When creating a frame buffer applications pass a memory
-handle (or a list of memory handles for multi-planar formats) through
-the ``drm_mode_fb_cmd2`` argument. For drivers using GEM as their
-userspace buffer management interface this would be a GEM handle.
-Drivers are however free to use their own backing storage object
-handles, e.g. vmwgfx directly exposes special TTM handles to userspace
-and so expects TTM handles in the create ioctl and not GEM handles.
-
-The lifetime of a drm framebuffer is controlled with a reference count,
-drivers can grab additional references with
-:c:func:`drm_framebuffer_reference()`and drop them again with
-:c:func:`drm_framebuffer_unreference()`. For driver-private
-framebuffers for which the last reference is never dropped (e.g. for the
-fbdev framebuffer when the struct :c:type:`struct drm_framebuffer
-<drm_framebuffer>` is embedded into the fbdev helper struct)
-drivers can manually clean up a framebuffer at module unload time with
-:c:func:`drm_framebuffer_unregister_private()`.
+========================
-DRM Format Handling
--------------------
+.. kernel-doc:: drivers/gpu/drm/drm_framebuffer.c
+ :doc: overview
+
+Frame Buffer Functions Reference
+--------------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_framebuffer.c
+ :export:
-.. kernel-doc:: include/drm/drm_fourcc.h
+.. kernel-doc:: include/drm/drm_framebuffer.h
:internal:
+DRM Format Handling
+===================
+
.. kernel-doc:: drivers/gpu/drm/drm_fourcc.c
:export:
Dumb Buffer Objects
--------------------
+===================
The KMS API doesn't standardize backing storage object creation and
leaves it to driver-specific ioctls. Furthermore actually creating a
attempted on some ARM embedded platforms. Such drivers really must have
a hardware-specific ioctl to allocate suitable buffer objects.
-Output Polling
---------------
+Display Modes Function Reference
+================================
+
+.. kernel-doc:: include/drm/drm_modes.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_modes.c
+ :export:
+
+Connector Display Sink Abstraction
+==================================
-void (\*output_poll_changed)(struct drm_device \*dev);
-This operation notifies the driver that the status of one or more
-connectors has changed. Drivers that use the fb helper can just call the
-:c:func:`drm_fb_helper_hotplug_event()` function to handle this
-operation.
+.. kernel-doc:: include/drm/drm_connector.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+ :export:
KMS Initialization and Cleanup
==============================
the process is complete, the new connector is registered with sysfs to
make its properties available to applications.
-KMS API Functions
------------------
-
-.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
- :export:
-
-KMS Data Structures
--------------------
-
-.. kernel-doc:: include/drm/drm_crtc.h
- :internal:
-
KMS Locking
------------
+===========
.. kernel-doc:: drivers/gpu/drm/drm_modeset_lock.c
:doc: kms locking
pointer to the target object, a pointer to the previously created
property and an initial instance value.
+Blending and Z-Position properties
+----------------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_blend.c
+ :export:
+
Existing KMS Properties
-----------------------
.. kernel-doc:: drivers/gpu/drm/drm_irq.c
:export:
-.. kernel-doc:: include/drm/drmP.h
- :functions: drm_crtc_vblank_waitqueue
+.. kernel-doc:: include/drm/drm_irq.h
+ :internal: