* [PATCH libdrm 1/4] man: use automake man_MANS to allow multiple suffixes
2012-09-23 14:40 [PATCH libdrm 0/4] Overview man-pages for libdrm David Herrmann
@ 2012-09-23 14:40 ` David Herrmann
2012-09-27 16:24 ` Jesse Barnes
2012-09-23 14:40 ` [PATCH libdrm 2/4] man: add man/drm.7 overview page David Herrmann
` (4 subsequent siblings)
5 siblings, 1 reply; 14+ messages in thread
From: David Herrmann @ 2012-09-23 14:40 UTC (permalink / raw)
To: dri-devel
Current man-page infrastructure supports only man3 but we wanto overview
files to be placed in man7. So use the new automake support for man_MANS
which installs the files automatically in the right location.
The current man-pages are simply moved and their header line is adjusted to the
new man-page headers.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
man/Makefile.am | 16 +++-----
man/drmAvailable.3 | 26 +++++++++++++
man/drmAvailable.man | 25 -------------
man/drmHandleEvent.3 | 48 ++++++++++++++++++++++++
man/drmHandleEvent.man | 45 -----------------------
man/drmModeGetResources.3 | 89 +++++++++++++++++++++++++++++++++++++++++++++
man/drmModeGetResources.man | 79 ----------------------------------------
7 files changed, 168 insertions(+), 160 deletions(-)
create mode 100644 man/drmAvailable.3
delete mode 100644 man/drmAvailable.man
create mode 100644 man/drmHandleEvent.3
delete mode 100644 man/drmHandleEvent.man
create mode 100644 man/drmModeGetResources.3
delete mode 100644 man/drmModeGetResources.man
diff --git a/man/Makefile.am b/man/Makefile.am
index 73068e6..f003101 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -1,11 +1,5 @@
-libmandir = $(LIB_MAN_DIR)
-libman_PRE = drmAvailable.man \
- drmHandleEvent.man \
- drmModeGetResources.man
-libman_DATA = $(libman_PRE:man=@LIB_MAN_SUFFIX@)
-EXTRA_DIST = $(libman_PRE)
-CLEANFILE = $(libman_DATA)
-SUFFIXES = .$(LIB_MAN_SUFFIX) .man
-
-.man.$(LIB_MAN_SUFFIX):
- $(AM_V_GEN)$(SED) $(MAN_SUBSTS) < $< > $@
+man_MANS = \
+ drmAvailable.3 \
+ drmHandleEvent.3 \
+ drmModeGetResources.3
+EXTRA_DIST = $(man_MANS)
diff --git a/man/drmAvailable.3 b/man/drmAvailable.3
new file mode 100644
index 0000000..d3abcf1
--- /dev/null
+++ b/man/drmAvailable.3
@@ -0,0 +1,26 @@
+.TH "drmAvailable" 3 "September 2012" "libdrm" "Direct Rendering Manager"
+.SH NAME
+drmAvailable \- determine whether a DRM kernel driver has been loaded
+
+.SH SYNOPSIS
+.nf
+.B "#include <xf86drm.h>"
+
+.B "int drmAvailable(void);"
+.fi
+
+.SH DESCRIPTION
+This function allows the caller to determine whether a kernel DRM driver is
+loaded.
+
+.SH RETURN VALUE
+If a DRM driver is currently loaded, this function returns 1. Otherwise 0
+is returned.
+
+.SH REPORTING BUGS
+Bugs in this function should be reported to http://bugs.freedesktop.org under
+the "Mesa" product, with "Other" or "libdrm" as the component.
+
+.SH "SEE ALSO"
+.BR drm (7),
+.BR drmOpen (3)
diff --git a/man/drmAvailable.man b/man/drmAvailable.man
deleted file mode 100644
index e1bb8dc..0000000
--- a/man/drmAvailable.man
+++ /dev/null
@@ -1,25 +0,0 @@
-.\" shorthand for double quote that works everywhere.
-.ds q \N'34'
-.TH drmAvailable __drivermansuffix__ __vendorversion__
-.SH NAME
-drmAvailable \- determine whether a DRM kernel driver has been loaded
-.SH SYNOPSIS
-.nf
-.B "#include <xf86drm.h>"
-
-.B "int drmAvailable(void);"
-.fi
-.SH DESCRIPTION
-This function allows the caller to determine whether a kernel DRM driver is
-loaded.
-
-.SH RETURN VALUE
-If a DRM driver is currently loaded, this function returns 1. Otherwise 0
-is returned.
-
-.SH REPORTING BUGS
-Bugs in this function should be reported to http://bugs.freedesktop.org under
-the "Mesa" product, with "Other" or "libdrm" as the component.
-
-.SH "SEE ALSO"
-drmOpen(__libmansuffix__)
diff --git a/man/drmHandleEvent.3 b/man/drmHandleEvent.3
new file mode 100644
index 0000000..bc933ed
--- /dev/null
+++ b/man/drmHandleEvent.3
@@ -0,0 +1,48 @@
+.TH "drmHandleEvent" 3 "September 2012" "libdrm" "Direct Rendering Manager"
+.SH NAME
+drmHandleEvent \- read and process pending DRM events
+
+.SH SYNOPSIS
+.nf
+.B "#include <xf86drm.h>"
+
+.B "typedef struct _drmEventContext {"
+.BI " int version;"
+.BI " void (*vblank_handler)(int fd,"
+.BI " unsigned int sequence,"
+.BI " unsigned int tv_sec,"
+.BI " unsigned int tv_usec,"
+.BI " void *user_data);"
+.BI " void (*page_flip_handler)(int fd,"
+.BI " unsigned int sequence,"
+.BI " unsigned int tv_sec,"
+.BI " unsigned int tv_usec,"
+.BI " void *user_data);"
+.B "} drmEventContext, *drmEventContextPtr;"
+
+.B "int drmHandleEvent(int fd, drmEventContextPtr evctx);"
+.fi
+
+.SH DESCRIPTION
+This function will process outstanding DRM events on
+.I fd
+, which must be an open DRM device. This function should be called after
+the DRM file descriptor has polled readable; it will read the events and
+use the passed-in
+.I evctx
+structure to call function pointers with the parameters noted above.
+
+.SH RETURN VALUE
+Returns 0 on success, or if there is no data to read from the file descriptor.
+Returns -1 if the read on the file descriptor fails or returns less than a
+full event record.
+
+.SH REPORTING BUGS
+Bugs in this function should be reported to http://bugs.freedesktop.org under
+the "Mesa" product, with "Other" or "libdrm" as the component.
+
+.SH "SEE ALSO"
+.BR drm (7),
+.BR drm-kms (7),
+.BR drmModePageFlip (3),
+.BR drmWaitVBlank (3)
diff --git a/man/drmHandleEvent.man b/man/drmHandleEvent.man
deleted file mode 100644
index b98f417..0000000
--- a/man/drmHandleEvent.man
+++ /dev/null
@@ -1,45 +0,0 @@
-.\" shorthand for double quote that works everywhere.
-.ds q \N'34'
-.TH drmHandleEvent __drivermansuffix__ __vendorversion__
-.SH NAME
-drmHandleEvent \- read and process pending DRM events
-.SH SYNOPSIS
-.nf
-.B "#include <xf86drm.h>"
-
-.B "typedef struct _drmEventContext {"
-.BI " int version;"
-.BI " void (*vblank_handler)(int fd,"
-.BI " unsigned int sequence,"
-.BI " unsigned int tv_sec,"
-.BI " unsigned int tv_usec,"
-.BI " void *user_data);"
-.BI " void (*page_flip_handler)(int fd,"
-.BI " unsigned int sequence,"
-.BI " unsigned int tv_sec,"
-.BI " unsigned int tv_usec,"
-.BI " void *user_data);"
-.B "} drmEventContext, *drmEventContextPtr;"
-
-.B "int drmHandleEvent(int fd, drmEventContextPtr evctx);"
-.fi
-.SH DESCRIPTION
-This function will process outstanding DRM events on
-.I fd
-, which must be an open DRM device. This function should be called after
-the DRM file descriptor has polled readable; it will read the events and
-use the passed-in
-.I evctx
-structure to call function pointers with the parameters noted above.
-
-.SH RETURN VALUE
-Returns 0 on success, or if there is no data to read from the file descriptor.
-Returns -1 if the read on the file descriptor fails or returns less than a
-full event record.
-
-.SH REPORTING BUGS
-Bugs in this function should be reported to http://bugs.freedesktop.org under
-the "Mesa" product, with "Other" or "libdrm" as the component.
-
-.SH "SEE ALSO"
-drmModePageFlip(__libmansuffix__), drmWaitVBlank(__libmansuffix__)
diff --git a/man/drmModeGetResources.3 b/man/drmModeGetResources.3
new file mode 100644
index 0000000..a06a58a
--- /dev/null
+++ b/man/drmModeGetResources.3
@@ -0,0 +1,89 @@
+.TH "drmModeGetResources" 7 "September 2012" "libdrm" "Direct Rendering Manager"
+.SH NAME
+drmModeGetResources \- retrieve current display configuration information
+
+.SH SYNOPSIS
+.nf
+.B "#include <xf86drmMode.h>"
+
+.BI "typedef struct _drmModeRes {"
+
+.BI " int count_fbs;"
+.BI " uint32_t *fbs;"
+
+.BI " int count_crtcs;"
+.BI " uint32_t *crtcs;"
+
+.BI " int count_connectors;"
+.BI " uint32_t *connectors;"
+
+.BI " int count_encoders;"
+.BI " uint32_t *encoders;"
+
+.BI " uint32_t min_width, max_width;"
+.BI " uint32_t min_height, max_height;"
+.B "} drmModeRes, *drmModeResPtr;"
+
+.B "drmModeResPtr drmModeGetResources(int fd);"
+.fi
+
+.SH DESCRIPTION
+This function will allocate, populate, and return a drmModeRes structure
+containing information about the current display configuration.
+
+The
+.I count_fbs
+and
+.I fbs
+fields indicate the number of currently allocated framebuffer objects (i.e.
+objects that can be attached to a given CRTC or sprite for display).
+
+The
+.I count_crtcs
+and
+.I crtcs
+fields list the available CRTCs in the configuration. A CRTC is simply
+an object that can scan out a framebuffer to a display sink, and contains
+mode timing and relative position information. CRTCs drive encoders, which
+are responsible for converting the pixel stream into a specific display
+protocol (e.g. MIPI or HDMI).
+
+The
+.I count_connectors
+and
+.I connectors
+fields list the available physical connectors on the system. Note that
+some of these may not be exposed from the chassis (e.g. LVDS or eDP).
+Connectors are attached to encoders and contain information about the
+attached display sink (e.g. width and height in mm, subpixel ordering, and
+various other properties).
+
+The
+.I count_encoders
+and
+.I encoders
+fields list the available encoders on the device. Each encoder may be
+associated with a CRTC, and may be used to drive a particular encoder.
+
+The min and max height fields indicate the maximum size of a framebuffer
+for this device (i.e. the scanout size limit).
+
+.SH RETURN VALUE
+Returns a drmModeRes structure pointer on success, 0 on failure.
+
+.SH REPORTING BUGS
+Bugs in this function should be reported to http://bugs.freedesktop.org under
+the "Mesa" product, with "Other" or "libdrm" as the component.
+
+.SH "SEE ALSO"
+.BR drm (7),
+.BR drm-kms (7),
+.BR drmModeGetFB (3),
+.BR drmModeAddFB (3),
+.BR drmModeAddFB2 (3),
+.BR drmModeRmFB (3),
+.BR drmModeDirtyFB (3),
+.BR drmModeGetCrtc (3),
+.BR drmModeSetCrtc (3),
+.BR drmModeGetEncoder (3),
+.BR drmModeGetConnector (3)
diff --git a/man/drmModeGetResources.man b/man/drmModeGetResources.man
deleted file mode 100644
index 369bf7d..0000000
--- a/man/drmModeGetResources.man
+++ /dev/null
@@ -1,79 +0,0 @@
-.\" shorthand for double quote that works everywhere.
-.ds q \N'34'
-.TH drmModeGetResources __drivermansuffix__ __vendorversion__
-.SH NAME
-drmModeGetResources \- retrieve current display configuration information
-.SH SYNOPSIS
-.nf
-.B "#include <xf86drmMode.h>"
-
-.BI "typedef struct _drmModeRes {"
-
-.BI " int count_fbs;"
-.BI " uint32_t *fbs;"
-
-.BI " int count_crtcs;"
-.BI " uint32_t *crtcs;"
-
-.BI " int count_connectors;"
-.BI " uint32_t *connectors;"
-
-.BI " int count_encoders;"
-.BI " uint32_t *encoders;"
-
-.BI " uint32_t min_width, max_width;"
-.BI " uint32_t min_height, max_height;"
-.B "} drmModeRes, *drmModeResPtr;"
-
-.B "drmModeResPtr drmModeGetResources(int fd);"
-.fi
-.SH DESCRIPTION
-This function will allocate, populate, and return a drmModeRes structure
-containing information about the current display configuration.
-
-The
-.I count_fbs
-and
-.I fbs
-fields indicate the number of currently allocated framebuffer objects (i.e.
-objects that can be attached to a given CRTC or sprite for display).
-
-The
-.I count_crtcs
-and
-.I crtcs
-fields list the available CRTCs in the configuration. A CRTC is simply
-an object that can scan out a framebuffer to a display sink, and contains
-mode timing and relative position information. CRTCs drive encoders, which
-are responsible for converting the pixel stream into a specific display
-protocol (e.g. MIPI or HDMI).
-
-The
-.I count_connectors
-and
-.I connectors
-fields list the available physical connectors on the system. Note that
-some of these may not be exposed from the chassis (e.g. LVDS or eDP).
-Connectors are attached to encoders and contain information about the
-attached display sink (e.g. width and height in mm, subpixel ordering, and
-various other properties).
-
-The
-.I count_encoders
-and
-.I encoders
-fields list the available encoders on the device. Each encoder may be
-associated with a CRTC, and may be used to drive a particular encoder.
-
-The min and max height fields indicate the maximum size of a framebuffer
-for this device (i.e. the scanout size limit).
-
-.SH RETURN VALUE
-Returns a drmModeRes structure pointer on success, 0 on failure.
-
-.SH REPORTING BUGS
-Bugs in this function should be reported to http://bugs.freedesktop.org under
-the "Mesa" product, with "Other" or "libdrm" as the component.
-
-.SH "SEE ALSO"
-drmModeGetFB(__libmansuffix__), drmModeAddFB(__libmansuffix__), drmModeAddFB2(__libmansuffix__), drmModeRmFB(__libmansuffix__), drmModeDirtyFB(__libmansuffix__), drmModeGetCrtc(__libmansuffix__), drmModeSetCrtc(__libmansuffix__), drmModeGetEncoder(__libmansuffix__), drmModeGetConnector(__libmansuffix__)
--
1.7.12.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH libdrm 1/4] man: use automake man_MANS to allow multiple suffixes
2012-09-23 14:40 ` [PATCH libdrm 1/4] man: use automake man_MANS to allow multiple suffixes David Herrmann
@ 2012-09-27 16:24 ` Jesse Barnes
0 siblings, 0 replies; 14+ messages in thread
From: Jesse Barnes @ 2012-09-27 16:24 UTC (permalink / raw)
To: David Herrmann; +Cc: dri-devel
On Sun, 23 Sep 2012 16:40:04 +0200
David Herrmann <dh.herrmann@googlemail.com> wrote:
> Current man-page infrastructure supports only man3 but we wanto overview
> files to be placed in man7. So use the new automake support for man_MANS
> which installs the files automatically in the right location.
>
> The current man-pages are simply moved and their header line is adjusted to the
> new man-page headers.
>
> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
> ---
Yeah looks nice.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH libdrm 2/4] man: add man/drm.7 overview page
2012-09-23 14:40 [PATCH libdrm 0/4] Overview man-pages for libdrm David Herrmann
2012-09-23 14:40 ` [PATCH libdrm 1/4] man: use automake man_MANS to allow multiple suffixes David Herrmann
@ 2012-09-23 14:40 ` David Herrmann
2012-09-27 16:25 ` Jesse Barnes
2012-09-23 14:40 ` [PATCH libdrm 3/4] man: add KMS " David Herrmann
` (3 subsequent siblings)
5 siblings, 1 reply; 14+ messages in thread
From: David Herrmann @ 2012-09-23 14:40 UTC (permalink / raw)
To: dri-devel
This man-page is supposed to provide an overview of the whole DRM system.
It is targeted to users that have never worked with DRM and forwards the
reader to the correct other man-pages.
Detailed information on each system are available in separate man-pages
which are currently under construction.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
man/Makefile.am | 1 +
man/drm.7 | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 100 insertions(+)
create mode 100644 man/drm.7
diff --git a/man/Makefile.am b/man/Makefile.am
index f003101..6193a95 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -1,4 +1,5 @@
man_MANS = \
+ drm.7 \
drmAvailable.3 \
drmHandleEvent.3 \
drmModeGetResources.3
diff --git a/man/drm.7 b/man/drm.7
new file mode 100644
index 0000000..d8d6f38
--- /dev/null
+++ b/man/drm.7
@@ -0,0 +1,99 @@
+.\"
+.\" Written 2012 by David Herrmann
+.\" Dedicated to the Public Domain
+.\"
+.TH "DRM" 7 "September 2012" "libdrm" "Direct Rendering Manager"
+.SH NAME
+DRM \- Direct Rendering Manager
+
+.SH SYNOPSIS
+.B #include <xf86drm.h>
+
+.SH DESCRIPTION
+The
+.B Direct Rendering Manager
+(DRM) is a framework to manage
+.B Graphics Processing Units
+(GPUs). It is designed to support the needs of complex graphics devices, usually
+containing programmable pipelines well suited to 3D graphics acceleration.
+Furthermore, it is responsible for memory management, interrupt handling and DMA
+to provide a uniform interface to applications.
+
+In earlier days, the kernel framework was solely used to provide raw hardware
+access to priviledged user-space processes which implement all the hardware
+abstraction layers. But more and more tasks where moved into the kernel. All
+these interfaces are based on
+.BR ioctl (2)
+commands on the DRM character device. The
+.B libdrm
+library provides wrappers for these system-calls and many helpers to simplify
+the API.
+
+When a GPU is detected, the DRM system loads a driver for the detected hardware
+type. Each connected GPU is then presented to user-space via a character-device
+that is usually available as
+.I /dev/dri/card0
+and can be accessed with
+.BR open (2)
+and
+.BR close (2).
+However, it still depends on the grapics driver which interfaces are available
+on these devices. If an interface is not available, the syscalls will fail with
+EINVAL.
+
+.SS Authentication
+All DRM devices provide authentication mechanisms. Only a DRM-Master is allowed
+to perform mode-setting or modify core state and only one user can be DRM-Master
+at a time. See
+.BR drmSetMaster (3)
+for information on how to become DRM-Master and what the limitations are.
+Other DRM users can be authenticated to the DRM-Master via
+.BR drmAuthMagic (3)
+so they can perform buffer allocations and rendering.
+
+.SS Mode-Setting
+Managing connected monitors and displays and changing the current modes is
+called
+.BR Mode-Setting .
+This is restricted to the current DRM-Master. Historically, this was implemented
+in user-space, but new DRM drivers implement a kernel interface to perform
+mode-setting called
+.B Kernel Mode Setting
+(KMS). If your hardware-driver supports it, you can use the KMS API provided by
+DRM. This includes allocating framebuffers, selecting modes and managing CRTCs
+and encoders. See
+.BR drm-kms (7)
+for more.
+
+.SS Memory Management
+The most sophisticated tasks for GPUs today is managing memory objects.
+Textures, framebuffers, command-buffers and all other kinds of commands for the
+GPU have to be stored in memory. The DRM driver takes care of managing all
+memory objects, flushing caches, synchronizing access and providing CPU access
+to GPU memory.
+.br
+All memory management is hardware driver dependent. However, two generic
+frameworks are available that are used by most DRM drivers. These are the
+.B Translation Table Manager
+(TTM) and the
+.B Graphics Execution Manager
+(GEM). They provide generic APIs to create, destroy and access buffers from
+user-space. However, there are still many differences between the drivers so
+driver-depedent code is still needed. Many helpers are provided in
+.B libgbm
+(Graphics Buffer Manager) from the
+.IR mesa-project .
+For more information on DRM memory-management, see
+.BR drm-memory (7).
+
+.SH REPORTING BUGS
+Bugs in this manual should be reported to http://bugs.freedesktop.org under
+the "Mesa" product, with "Other" or "libdrm" as the component.
+
+.SH "SEE ALSO"
+.BR drm-kms (7),
+.BR drm-memory (7),
+.BR drmSetMaster (3),
+.BR drmAuthMagic (3),
+.BR drmAvailable (3),
+.BR drmOpen (3)
--
1.7.12.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH libdrm 2/4] man: add man/drm.7 overview page
2012-09-23 14:40 ` [PATCH libdrm 2/4] man: add man/drm.7 overview page David Herrmann
@ 2012-09-27 16:25 ` Jesse Barnes
0 siblings, 0 replies; 14+ messages in thread
From: Jesse Barnes @ 2012-09-27 16:25 UTC (permalink / raw)
To: David Herrmann; +Cc: dri-devel
On Sun, 23 Sep 2012 16:40:05 +0200
David Herrmann <dh.herrmann@googlemail.com> wrote:
> This man-page is supposed to provide an overview of the whole DRM system.
> It is targeted to users that have never worked with DRM and forwards the
> reader to the correct other man-pages.
>
> Detailed information on each system are available in separate man-pages
> which are currently under construction.
>
> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
> ---
> man/Makefile.am | 1 +
> man/drm.7 | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 100 insertions(+)
> create mode 100644 man/drm.7
>
> diff --git a/man/Makefile.am b/man/Makefile.am
> index f003101..6193a95 100644
> --- a/man/Makefile.am
> +++ b/man/Makefile.am
> @@ -1,4 +1,5 @@
> man_MANS = \
> + drm.7 \
> drmAvailable.3 \
> drmHandleEvent.3 \
> drmModeGetResources.3
> diff --git a/man/drm.7 b/man/drm.7
> new file mode 100644
> index 0000000..d8d6f38
> --- /dev/null
> +++ b/man/drm.7
> @@ -0,0 +1,99 @@
> +.\"
> +.\" Written 2012 by David Herrmann
> +.\" Dedicated to the Public Domain
> +.\"
> +.TH "DRM" 7 "September 2012" "libdrm" "Direct Rendering Manager"
> +.SH NAME
> +DRM \- Direct Rendering Manager
> +
> +.SH SYNOPSIS
> +.B #include <xf86drm.h>
> +
> +.SH DESCRIPTION
> +The
> +.B Direct Rendering Manager
> +(DRM) is a framework to manage
> +.B Graphics Processing Units
> +(GPUs). It is designed to support the needs of complex graphics devices, usually
> +containing programmable pipelines well suited to 3D graphics acceleration.
> +Furthermore, it is responsible for memory management, interrupt handling and DMA
> +to provide a uniform interface to applications.
> +
> +In earlier days, the kernel framework was solely used to provide raw hardware
> +access to priviledged user-space processes which implement all the hardware
> +abstraction layers. But more and more tasks where moved into the kernel. All
> +these interfaces are based on
> +.BR ioctl (2)
> +commands on the DRM character device. The
> +.B libdrm
> +library provides wrappers for these system-calls and many helpers to simplify
> +the API.
> +
> +When a GPU is detected, the DRM system loads a driver for the detected hardware
> +type. Each connected GPU is then presented to user-space via a character-device
> +that is usually available as
> +.I /dev/dri/card0
> +and can be accessed with
> +.BR open (2)
> +and
> +.BR close (2).
> +However, it still depends on the grapics driver which interfaces are available
> +on these devices. If an interface is not available, the syscalls will fail with
> +EINVAL.
> +
> +.SS Authentication
> +All DRM devices provide authentication mechanisms. Only a DRM-Master is allowed
> +to perform mode-setting or modify core state and only one user can be DRM-Master
> +at a time. See
> +.BR drmSetMaster (3)
> +for information on how to become DRM-Master and what the limitations are.
> +Other DRM users can be authenticated to the DRM-Master via
> +.BR drmAuthMagic (3)
> +so they can perform buffer allocations and rendering.
> +
> +.SS Mode-Setting
> +Managing connected monitors and displays and changing the current modes is
> +called
> +.BR Mode-Setting .
> +This is restricted to the current DRM-Master. Historically, this was implemented
> +in user-space, but new DRM drivers implement a kernel interface to perform
> +mode-setting called
> +.B Kernel Mode Setting
> +(KMS). If your hardware-driver supports it, you can use the KMS API provided by
> +DRM. This includes allocating framebuffers, selecting modes and managing CRTCs
> +and encoders. See
> +.BR drm-kms (7)
> +for more.
> +
> +.SS Memory Management
> +The most sophisticated tasks for GPUs today is managing memory objects.
> +Textures, framebuffers, command-buffers and all other kinds of commands for the
> +GPU have to be stored in memory. The DRM driver takes care of managing all
> +memory objects, flushing caches, synchronizing access and providing CPU access
> +to GPU memory.
> +.br
> +All memory management is hardware driver dependent. However, two generic
> +frameworks are available that are used by most DRM drivers. These are the
> +.B Translation Table Manager
> +(TTM) and the
> +.B Graphics Execution Manager
> +(GEM). They provide generic APIs to create, destroy and access buffers from
> +user-space. However, there are still many differences between the drivers so
> +driver-depedent code is still needed. Many helpers are provided in
> +.B libgbm
> +(Graphics Buffer Manager) from the
> +.IR mesa-project .
> +For more information on DRM memory-management, see
> +.BR drm-memory (7).
> +
> +.SH REPORTING BUGS
> +Bugs in this manual should be reported to http://bugs.freedesktop.org under
> +the "Mesa" product, with "Other" or "libdrm" as the component.
> +
> +.SH "SEE ALSO"
> +.BR drm-kms (7),
> +.BR drm-memory (7),
> +.BR drmSetMaster (3),
> +.BR drmAuthMagic (3),
> +.BR drmAvailable (3),
> +.BR drmOpen (3)
Nice.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH libdrm 3/4] man: add KMS overview page
2012-09-23 14:40 [PATCH libdrm 0/4] Overview man-pages for libdrm David Herrmann
2012-09-23 14:40 ` [PATCH libdrm 1/4] man: use automake man_MANS to allow multiple suffixes David Herrmann
2012-09-23 14:40 ` [PATCH libdrm 2/4] man: add man/drm.7 overview page David Herrmann
@ 2012-09-23 14:40 ` David Herrmann
2012-09-27 16:28 ` Jesse Barnes
2012-09-23 14:40 ` [PATCH libdrm 4/4] man: add drm-memory man-page David Herrmann
` (2 subsequent siblings)
5 siblings, 1 reply; 14+ messages in thread
From: David Herrmann @ 2012-09-23 14:40 UTC (permalink / raw)
To: dri-devel
drm-kms.7 is an overview page which contains basic information on kernel
mode-setting. It is targeted to users that are not familiar with DRM
internals and gives short examples how basic mode-setting can be
performed.
It introduces the main vocabulary including CRTCs, encoders, connectors,
framebuffers, planes and cursors.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
man/Makefile.am | 1 +
man/drm-kms.7 | 269 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 270 insertions(+)
create mode 100644 man/drm-kms.7
diff --git a/man/Makefile.am b/man/Makefile.am
index 6193a95..7ce7ac4 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -1,5 +1,6 @@
man_MANS = \
drm.7 \
+ drm-kms.7 \
drmAvailable.3 \
drmHandleEvent.3 \
drmModeGetResources.3
diff --git a/man/drm-kms.7 b/man/drm-kms.7
new file mode 100644
index 0000000..38838bf
--- /dev/null
+++ b/man/drm-kms.7
@@ -0,0 +1,269 @@
+.\"
+.\" Written 2012 by David Herrmann
+.\" Dedicated to the Public Domain
+.\"
+.TH "DRM-KMS" 7 "September 2012" "libdrm" "Direct Rendering Manager"
+.SH NAME
+DRM-KMS \- Kernel Mode-Setting
+
+.SH SYNOPSIS
+.B #include <xf86drm.h>
+.br
+.B #include <xf86drmMode.h>
+
+.SH DESCRIPTION
+Each DRM device provides access to manage which monitors and displays are
+currently used and what frames to be displayed. This task is called
+.BR "Kernel Mode-Setting " (KMS).
+Historically, this was done in user-space and called
+.BR "User-space Mode-Setting " (UMS).
+Almost all open-source drivers now provide the KMS kernel API to do this in the
+kernel, however, many non-open-source binary drivers from different vendors
+still do not support this. You can use
+.BR drmModeSettingSupported (3)
+to check whether your driver supports this.
+.br
+To understand how KMS works, we need to introduce 5 objects:
+.IR CRTCs ", " Planes ", " Encoders ", " Connectors " and " Framebuffers
+
+.IP "\fBCRTCs\fP"
+A
+.BR CRTC ,
+short for
+.B CRT Controller
+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 list of driven connectors, 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.
+.br
+A CRTC is the central point where configuration of displays happens. You select
+which objects to use, which modes and which parameters and then configure each
+CRTC via
+.BR drmModeCrtcSet (3)
+to drive the display devices.
+
+.IP "\fBPlanes\fP"
+A
+.B plane
+respresents an image source that can be blended with or overlayed on top of a
+CRTC during the scanout process. Planes are associated with a frame-buffer to
+crop a portion of the image memory (source) and optionally scale it to a
+destination size. The result is then blended with or overlayed on top of a CRTC.
+.br
+Planes are not provided by all hardware and the number of available planes is
+limited. If planes are not available or if not enough planes are available, the
+user should fall back to normal software blending (via GPU or CPU).
+
+.IP "\fBEncoders\fP"
+An
+.B encoder
+takes pixel data from a CRTC and converts it to a format suitable for any
+attached connectors. On some devices, it may be possible to have a CRTC send
+data to more than one encoder. In that case, both encoders would receive data
+from the same scanout buffer, resulting in a
+.I cloned
+display configuration across the connectors attached to each encoder.
+
+.IP "\fBConnectors\fP"
+A
+.B connector
+is the final destination of pixel-data on a device, and usually connects
+directly to an external display device like a monitor or laptop panel. A
+connector can only be attached to one encoder at a time. The connector is also
+the structure where information about the attached display is kept, so it
+contains fields for display data,
+.IR EDID " data, " DPMS " and " "connection status" ,
+and information about modes supported on the attached displays.
+
+.IP "\fBFramebuffers\fP"
+.B Framebuffers
+are abstract memory objects that provide a source of pixel data to scanout to a
+CRTC. Applications explicitely request the creation of framebuffers and can
+control their behavior.
+.br
+Framebuffers rely on the underneath memory manager for low-level memory
+operations. When creating a framebuffer, applications pass a memory handle
+through the API which is used as backing storage. The framebuffer itself is only
+an abstract object with no data. It just refers to memory buffers that must be
+created with the
+.BR drm-memory (7)
+API.
+
+.SS Mode-Setting
+Before mode-setting can be performed, an application needs to call
+.BR drmSetMaster (3)
+to become
+.IR DRM-Master "."
+It then has exclusive access to the KMS API. A call to
+.BR drmModeGetResources (3)
+returns a list of
+.IR CRTCs ", " Connectors ", " Encoders " and " Planes "."
+
+Normal procedure now includes: First, you select which connectors you want to
+use. Users are mostly interested in which monitor or display-panel is active so
+you need to make sure to arrange them in the correct logical order and select
+the correct ones to use. For each connector, you need to find a CRTC to drive
+this connector. If you want to clone output to two or more connectors, you may
+use a single CRTC for all cloned connectors (if the hardware supports this). To
+find a suitable CRTC, you need to iterate over the list of encoders that are
+available for each connector. Each encoder contains a list of CRTCs that it can
+work with and you simply select one of these CRTCs. If you later program the
+CRTC to control a connector, it automatically selects the best encoder. However,
+this procedure is needed so your CRTC has at least one working encoder for the
+selected connector. See the
+.B Examples
+section below for more information.
+
+All valid modes for a connector can be retrieved with a call to
+.BR drmModeGetConnector "(3)."
+You need to select the mode you want to use and save it. The first mode in the
+list is the default mode with the highest resolution possible and often a
+suitable choice.
+
+After you have a working connector+CRTC+mode combination, you need to create a
+framebuffer that is used for scanout. Memory buffer allocation is
+driver-depedent and described in
+.BR drm-memory "(7)."
+You need to create a buffer big enough for your selected mode. Now you can
+create a framebuffer object that uses your memory-buffer as scanout buffer. You
+can do this with
+.BR drmModeAddFB "(3) and " drmModeAddFB2 "(3)."
+
+As a last step, you want to program your CRTC to drive your selected connector.
+You can do this with a call to
+.BR drmModeSetCrtc "(3)."
+
+.SS Page-Flipping
+A call to
+.BR drmModeSetCrtc (3)
+is executed immediately and forces the CRTC to use the new scanout buffer. If
+you want smooth-transitions without tearing, you probably use double-buffering.
+You need to create one framebuffer object for each buffer you use. You can then
+call
+.BR drmModeSetCrtc (3)
+on the next buffer to flip. If you want to synchronize your flips with
+.IR "vertical-blanks" ","
+you can use
+.BR drmModePageFlip (3)
+which schedules your page-flip for the next
+.IR vblank "."
+
+.SS Planes
+Planes are controlled independently from CRTCs. That is, a call to
+.BR drmModeSetCrtc (3)
+does not affect planes. Instead, you need to call
+.BR drmModeSetPlane (3)
+to configure a plane. This requires the plane ID, a CRTC, a framebuffer and
+offsets into the plane-framebuffer and the CRTC-framebuffer. The CRTC then
+blends the content from the plane over the CRTC framebuffer buffer during
+scanout. As this does not involve any software-blending, it is way faster than
+traditional blending. However, plane resources are limited. See
+.BR drmModeGetPlaneResources (3)
+for more information.
+
+.SS Cursors
+Similar to planes, many hardware also supports cursors. A cursor is a very small
+buffer with an image that is blended over the CRTC framebuffer. You can set a
+different cursor for each CRTC with
+.BR drmModeSetCursor (3)
+and move it on the screen with
+.BR drmModeMoveCursor "(3)."
+This allows to move the cursor on the screen without rerendering. If no hardware
+cursors are supported, you need to rerender for each frame the cursor is moved.
+
+.SH EXAMPLES
+Some examples of how basic mode-setting can be done. See the man-page of each
+DRM function for more information.
+
+.SS CRTC/Encoder Selection
+If you retrieved all display configuration information via
+.BR drmModeGetResources (3)
+as
+.BR drmModeRes " *" res ","
+selected a connector from the list in
+.BR "res" "->" "connectors"
+and retrieved the connector-information as
+.BR "drmModeConnector" " *" "conn" " via " drmModeGetConnector (3)
+then this example shows, how you can find a suitable CRTC id to drive this
+connector. This function takes a file-descriptor to the DRM device
+.RB "(see " drmOpen "(3)) as " "fd" ","
+a pointer to the retrieved resources as
+.B res
+and a pointer to the selected connector as
+.BR "conn" "."
+It returns an integer smaller than 0 on failure, otherwise, a valid CRTC id is
+returned.
+
+.in +4n
+.nf
+static int modeset_find_crtc(int fd, drmModeRes *res, drmModeConnector *conn)
+{
+ drmModeEncoder *enc;
+ unsigned int i, j;
+
+ /* iterate all encoders of this connector */
+ for (i = 0; i < conn->count_encoders; ++i) {
+ enc = drmModeGetEncoder(fd, conn->encoders[i]);
+ if (!enc) {
+ /* cannot retrieve encoder, ignoring... */
+ continue;
+ }
+
+ /* iterate all global CRTCs */
+ for (j = 0; j < res->count_crtcs; ++j) {
+ /* check whether this CRTC works with the encoder */
+ if (!(enc->possible_crtcs & (1 << j)))
+ continue;
+
+
+ /* Here you need to check that no other connector
+ * currently uses the CRTC with id "crtc". If you intend
+ * to drive one connector only, then you can skip this
+ * step. Otherwise, simply scan your list of configured
+ * connectors and CRTCs whether this CRTC is already
+ * used. If it is, then simply continue the search here. */
+ if (res->crtcs[j] "is unused") {
+ drmModeFreeEncoder(enc);
+ return res->crtcs[j];
+ }
+ }
+
+ drmModeFreeEncoder(enc);
+ }
+
+ /* cannot find a suitable CRTC */
+ return -ENOENT;
+}
+.fi
+.in
+
+.SH REPORTING BUGS
+Bugs in this manual should be reported to http://bugs.freedesktop.org under
+the "Mesa" product, with "Other" or "libdrm" as the component.
+
+.SH "SEE ALSO"
+.BR drm (7),
+.BR drm-memory (7),
+.BR drmModeGetResources (3),
+.BR drmModeGetConnector (3),
+.BR drmModeGetEncoder (3),
+.BR drmModeGetCrtc (3),
+.BR drmModeSetCrtc (3),
+.BR drmModeGetFB (3),
+.BR drmModeAddFB (3),
+.BR drmModeAddFB2 (3),
+.BR drmModeDirtyFB (3),
+.BR drmModeRmFB (3),
+.BR drmModePageFlip (3),
+.BR drmModeGetPlaneResources (3),
+.BR drmModeGetPlane (3),
+.BR drmModeSetPlane (3),
+.BR drmModeSetCursor (3),
+.BR drmModeMoveCursor (3),
+.BR drmSetMaster (3),
+.BR drmAvailable (3),
+.BR drmCheckModesettingSupported (3),
+.BR drmOpen (3)
--
1.7.12.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH libdrm 3/4] man: add KMS overview page
2012-09-23 14:40 ` [PATCH libdrm 3/4] man: add KMS " David Herrmann
@ 2012-09-27 16:28 ` Jesse Barnes
0 siblings, 0 replies; 14+ messages in thread
From: Jesse Barnes @ 2012-09-27 16:28 UTC (permalink / raw)
To: David Herrmann; +Cc: dri-devel
On Sun, 23 Sep 2012 16:40:06 +0200
David Herrmann <dh.herrmann@googlemail.com> wrote:
> drm-kms.7 is an overview page which contains basic information on kernel
> mode-setting. It is targeted to users that are not familiar with DRM
> internals and gives short examples how basic mode-setting can be
> performed.
> It introduces the main vocabulary including CRTCs, encoders, connectors,
> framebuffers, planes and cursors.
>
> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
> ---
> man/Makefile.am | 1 +
> man/drm-kms.7 | 269 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 270 insertions(+)
> create mode 100644 man/drm-kms.7
>
> diff --git a/man/Makefile.am b/man/Makefile.am
> index 6193a95..7ce7ac4 100644
> --- a/man/Makefile.am
> +++ b/man/Makefile.am
> @@ -1,5 +1,6 @@
> man_MANS = \
> drm.7 \
> + drm-kms.7 \
> drmAvailable.3 \
> drmHandleEvent.3 \
> drmModeGetResources.3
> diff --git a/man/drm-kms.7 b/man/drm-kms.7
> new file mode 100644
> index 0000000..38838bf
> --- /dev/null
> +++ b/man/drm-kms.7
> @@ -0,0 +1,269 @@
> +.\"
> +.\" Written 2012 by David Herrmann
> +.\" Dedicated to the Public Domain
> +.\"
> +.TH "DRM-KMS" 7 "September 2012" "libdrm" "Direct Rendering Manager"
> +.SH NAME
> +DRM-KMS \- Kernel Mode-Setting
> +
> +.SH SYNOPSIS
> +.B #include <xf86drm.h>
> +.br
> +.B #include <xf86drmMode.h>
> +
> +.SH DESCRIPTION
> +Each DRM device provides access to manage which monitors and displays are
> +currently used and what frames to be displayed. This task is called
> +.BR "Kernel Mode-Setting " (KMS).
> +Historically, this was done in user-space and called
> +.BR "User-space Mode-Setting " (UMS).
> +Almost all open-source drivers now provide the KMS kernel API to do this in the
> +kernel, however, many non-open-source binary drivers from different vendors
> +still do not support this. You can use
> +.BR drmModeSettingSupported (3)
> +to check whether your driver supports this.
> +.br
> +To understand how KMS works, we need to introduce 5 objects:
> +.IR CRTCs ", " Planes ", " Encoders ", " Connectors " and " Framebuffers
> +
> +.IP "\fBCRTCs\fP"
> +A
> +.BR CRTC ,
> +short for
> +.B CRT Controller
> +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 list of driven connectors, 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.
Kind of... planes make this more complicated and should arguably have
been split from the mode timing pixel sources from the outset...
But you cover that below so I think it's fine.
> +.br
> +A CRTC is the central point where configuration of displays happens. You select
> +which objects to use, which modes and which parameters and then configure each
> +CRTC via
> +.BR drmModeCrtcSet (3)
> +to drive the display devices.
> +
> +.IP "\fBPlanes\fP"
> +A
> +.B plane
> +respresents an image source that can be blended with or overlayed on top of a
> +CRTC during the scanout process. Planes are associated with a frame-buffer to
> +crop a portion of the image memory (source) and optionally scale it to a
> +destination size. The result is then blended with or overlayed on top of a CRTC.
> +.br
> +Planes are not provided by all hardware and the number of available planes is
> +limited. If planes are not available or if not enough planes are available, the
> +user should fall back to normal software blending (via GPU or CPU).
> +
> +.IP "\fBEncoders\fP"
> +An
> +.B encoder
> +takes pixel data from a CRTC and converts it to a format suitable for any
> +attached connectors. On some devices, it may be possible to have a CRTC send
> +data to more than one encoder. In that case, both encoders would receive data
> +from the same scanout buffer, resulting in a
> +.I cloned
> +display configuration across the connectors attached to each encoder.
> +
> +.IP "\fBConnectors\fP"
> +A
> +.B connector
> +is the final destination of pixel-data on a device, and usually connects
> +directly to an external display device like a monitor or laptop panel. A
> +connector can only be attached to one encoder at a time. The connector is also
> +the structure where information about the attached display is kept, so it
> +contains fields for display data,
> +.IR EDID " data, " DPMS " and " "connection status" ,
> +and information about modes supported on the attached displays.
> +
> +.IP "\fBFramebuffers\fP"
> +.B Framebuffers
> +are abstract memory objects that provide a source of pixel data to scanout to a
> +CRTC. Applications explicitely request the creation of framebuffers and can
> +control their behavior.
> +.br
> +Framebuffers rely on the underneath memory manager for low-level memory
> +operations. When creating a framebuffer, applications pass a memory handle
> +through the API which is used as backing storage. The framebuffer itself is only
> +an abstract object with no data. It just refers to memory buffers that must be
> +created with the
> +.BR drm-memory (7)
> +API.
> +
> +.SS Mode-Setting
> +Before mode-setting can be performed, an application needs to call
> +.BR drmSetMaster (3)
> +to become
> +.IR DRM-Master "."
> +It then has exclusive access to the KMS API. A call to
> +.BR drmModeGetResources (3)
> +returns a list of
> +.IR CRTCs ", " Connectors ", " Encoders " and " Planes "."
> +
> +Normal procedure now includes: First, you select which connectors you want to
> +use. Users are mostly interested in which monitor or display-panel is active so
> +you need to make sure to arrange them in the correct logical order and select
> +the correct ones to use. For each connector, you need to find a CRTC to drive
> +this connector. If you want to clone output to two or more connectors, you may
> +use a single CRTC for all cloned connectors (if the hardware supports this). To
> +find a suitable CRTC, you need to iterate over the list of encoders that are
> +available for each connector. Each encoder contains a list of CRTCs that it can
> +work with and you simply select one of these CRTCs. If you later program the
> +CRTC to control a connector, it automatically selects the best encoder. However,
> +this procedure is needed so your CRTC has at least one working encoder for the
> +selected connector. See the
> +.B Examples
> +section below for more information.
> +
> +All valid modes for a connector can be retrieved with a call to
> +.BR drmModeGetConnector "(3)."
> +You need to select the mode you want to use and save it. The first mode in the
> +list is the default mode with the highest resolution possible and often a
> +suitable choice.
> +
> +After you have a working connector+CRTC+mode combination, you need to create a
> +framebuffer that is used for scanout. Memory buffer allocation is
> +driver-depedent and described in
> +.BR drm-memory "(7)."
> +You need to create a buffer big enough for your selected mode. Now you can
> +create a framebuffer object that uses your memory-buffer as scanout buffer. You
> +can do this with
> +.BR drmModeAddFB "(3) and " drmModeAddFB2 "(3)."
> +
> +As a last step, you want to program your CRTC to drive your selected connector.
> +You can do this with a call to
> +.BR drmModeSetCrtc "(3)."
> +
> +.SS Page-Flipping
> +A call to
> +.BR drmModeSetCrtc (3)
> +is executed immediately and forces the CRTC to use the new scanout buffer. If
> +you want smooth-transitions without tearing, you probably use double-buffering.
> +You need to create one framebuffer object for each buffer you use. You can then
> +call
> +.BR drmModeSetCrtc (3)
> +on the next buffer to flip. If you want to synchronize your flips with
> +.IR "vertical-blanks" ","
> +you can use
> +.BR drmModePageFlip (3)
> +which schedules your page-flip for the next
> +.IR vblank "."
> +
> +.SS Planes
> +Planes are controlled independently from CRTCs. That is, a call to
> +.BR drmModeSetCrtc (3)
> +does not affect planes. Instead, you need to call
> +.BR drmModeSetPlane (3)
> +to configure a plane. This requires the plane ID, a CRTC, a framebuffer and
> +offsets into the plane-framebuffer and the CRTC-framebuffer. The CRTC then
> +blends the content from the plane over the CRTC framebuffer buffer during
> +scanout. As this does not involve any software-blending, it is way faster than
> +traditional blending. However, plane resources are limited. See
> +.BR drmModeGetPlaneResources (3)
> +for more information.
> +
> +.SS Cursors
> +Similar to planes, many hardware also supports cursors. A cursor is a very small
> +buffer with an image that is blended over the CRTC framebuffer. You can set a
> +different cursor for each CRTC with
> +.BR drmModeSetCursor (3)
> +and move it on the screen with
> +.BR drmModeMoveCursor "(3)."
> +This allows to move the cursor on the screen without rerendering. If no hardware
> +cursors are supported, you need to rerender for each frame the cursor is moved.
> +
> +.SH EXAMPLES
> +Some examples of how basic mode-setting can be done. See the man-page of each
> +DRM function for more information.
> +
> +.SS CRTC/Encoder Selection
> +If you retrieved all display configuration information via
> +.BR drmModeGetResources (3)
> +as
> +.BR drmModeRes " *" res ","
> +selected a connector from the list in
> +.BR "res" "->" "connectors"
> +and retrieved the connector-information as
> +.BR "drmModeConnector" " *" "conn" " via " drmModeGetConnector (3)
> +then this example shows, how you can find a suitable CRTC id to drive this
> +connector. This function takes a file-descriptor to the DRM device
> +.RB "(see " drmOpen "(3)) as " "fd" ","
> +a pointer to the retrieved resources as
> +.B res
> +and a pointer to the selected connector as
> +.BR "conn" "."
> +It returns an integer smaller than 0 on failure, otherwise, a valid CRTC id is
> +returned.
> +
> +.in +4n
> +.nf
> +static int modeset_find_crtc(int fd, drmModeRes *res, drmModeConnector *conn)
> +{
> + drmModeEncoder *enc;
> + unsigned int i, j;
> +
> + /* iterate all encoders of this connector */
> + for (i = 0; i < conn->count_encoders; ++i) {
> + enc = drmModeGetEncoder(fd, conn->encoders[i]);
> + if (!enc) {
> + /* cannot retrieve encoder, ignoring... */
> + continue;
> + }
> +
> + /* iterate all global CRTCs */
> + for (j = 0; j < res->count_crtcs; ++j) {
> + /* check whether this CRTC works with the encoder */
> + if (!(enc->possible_crtcs & (1 << j)))
> + continue;
> +
> +
> + /* Here you need to check that no other connector
> + * currently uses the CRTC with id "crtc". If you intend
> + * to drive one connector only, then you can skip this
> + * step. Otherwise, simply scan your list of configured
> + * connectors and CRTCs whether this CRTC is already
> + * used. If it is, then simply continue the search here. */
> + if (res->crtcs[j] "is unused") {
> + drmModeFreeEncoder(enc);
> + return res->crtcs[j];
> + }
> + }
> +
> + drmModeFreeEncoder(enc);
> + }
> +
> + /* cannot find a suitable CRTC */
> + return -ENOENT;
> +}
> +.fi
> +.in
> +
> +.SH REPORTING BUGS
> +Bugs in this manual should be reported to http://bugs.freedesktop.org under
> +the "Mesa" product, with "Other" or "libdrm" as the component.
> +
> +.SH "SEE ALSO"
> +.BR drm (7),
> +.BR drm-memory (7),
> +.BR drmModeGetResources (3),
> +.BR drmModeGetConnector (3),
> +.BR drmModeGetEncoder (3),
> +.BR drmModeGetCrtc (3),
> +.BR drmModeSetCrtc (3),
> +.BR drmModeGetFB (3),
> +.BR drmModeAddFB (3),
> +.BR drmModeAddFB2 (3),
> +.BR drmModeDirtyFB (3),
> +.BR drmModeRmFB (3),
> +.BR drmModePageFlip (3),
> +.BR drmModeGetPlaneResources (3),
> +.BR drmModeGetPlane (3),
> +.BR drmModeSetPlane (3),
> +.BR drmModeSetCursor (3),
> +.BR drmModeMoveCursor (3),
> +.BR drmSetMaster (3),
> +.BR drmAvailable (3),
> +.BR drmCheckModesettingSupported (3),
> +.BR drmOpen (3)
Could probably include a bit more sample code here, but that's no
reason not to push.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH libdrm 4/4] man: add drm-memory man-page
2012-09-23 14:40 [PATCH libdrm 0/4] Overview man-pages for libdrm David Herrmann
` (2 preceding siblings ...)
2012-09-23 14:40 ` [PATCH libdrm 3/4] man: add KMS " David Herrmann
@ 2012-09-23 14:40 ` David Herrmann
2012-09-24 7:45 ` Michel Dänzer
2012-09-27 16:31 ` Jesse Barnes
2012-09-24 19:51 ` [PATCH libdrm 0/4] Overview man-pages for libdrm Thierry Reding
2012-09-24 21:41 ` Alan Coopersmith
5 siblings, 2 replies; 14+ messages in thread
From: David Herrmann @ 2012-09-23 14:40 UTC (permalink / raw)
To: dri-devel
The drm-memory man-page (aliased as drm-gem, drm-mm and drm-ttm) describes
the high-level overview of different memory-management frameworks used in
the DRM subsystem. It is really targeted at driver-independent semantics
(and where it applies, syntax). It links to all other man-pages if more
driver-dependent information is needed.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
---
man/Makefile.am | 4 +
man/drm-gem.7 | 1 +
man/drm-memory.7 | 412 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
man/drm-mm.7 | 1 +
man/drm-ttm.7 | 1 +
5 files changed, 419 insertions(+)
create mode 100644 man/drm-gem.7
create mode 100644 man/drm-memory.7
create mode 100644 man/drm-mm.7
create mode 100644 man/drm-ttm.7
diff --git a/man/Makefile.am b/man/Makefile.am
index 7ce7ac4..ded3b4a 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -1,6 +1,10 @@
man_MANS = \
drm.7 \
drm-kms.7 \
+ drm-memory.7 \
+ drm-mm.7 \
+ drm-gem.7 \
+ drm-ttm.7 \
drmAvailable.3 \
drmHandleEvent.3 \
drmModeGetResources.3
diff --git a/man/drm-gem.7 b/man/drm-gem.7
new file mode 100644
index 0000000..258b5a3
--- /dev/null
+++ b/man/drm-gem.7
@@ -0,0 +1 @@
+.so man7/drm-memory.7
diff --git a/man/drm-memory.7 b/man/drm-memory.7
new file mode 100644
index 0000000..1eff38a
--- /dev/null
+++ b/man/drm-memory.7
@@ -0,0 +1,412 @@
+.\"
+.\" Written 2012 by David Herrmann
+.\" Dedicated to the Public Domain
+.\"
+.TH "DRM-MEMORY" 7 "September 2012" "libdrm" "Direct Rendering Manager"
+.SH NAME
+DRM-Memory \- DRM Memory Management
+
+.SH SYNOPSIS
+.B #include <xf86drm.h>
+
+.SH DESCRIPTION
+Many modern high-end GPUs come with their own memory managers. They even include
+several different caches that need to be synchronized during access. Textures,
+framebuffers, command buffers and more need to be stored in memory that can be
+accessed quickly by the GPU. Therefore, memory management on GPUs is highly
+driver\- and hardware\-dependent.
+
+However, there are several frameworks in the kernel that are used by more than
+one driver. These can be used for trivial mode-setting without requiring
+driver-dependent code. But for hardware-accelerated rendering you need to read
+the manual pages for the driver you want to work with.
+
+.SS Dumb-Buffers
+Almost all in-kernel DRM hardware drivers support an API called
+.BR "Dumb-Buffers" "."
+This API allows to create buffers of arbitrary size that can be used for
+scanout. These buffers can be memory mapped via
+.BR mmap (2)
+so you can render into them on the CPU. However, GPU access to these buffers is
+often not possible. Therefore, they are fine for simple tasks but not suitable
+for complex compositions and renderings.
+
+The
+.B DRM_IOCTL_MODE_CREATE_DUMB
+ioctl can be used to create a dumb buffer. The kernel will return a 32bit handle
+that can be used to manage the buffer with the DRM API. You can create
+framebuffers with
+.BR drmModeAddFB (3)
+and use it for mode-setting and scanout.
+.br
+To access the buffer, you first need to retrieve the offset of the buffer. The
+.B DRM_IOCTL_MODE_MAP_DUMB
+ioctl requests the DRM subsystem to prepare the buffer for memory-mapping and
+returns a fake-offset that can be used with
+.BR mmap "(2)."
+
+The
+.B DRM_IOCTL_MODE_CREATE_DUMB
+ioctl takes as argument a structure of type
+.IR "struct drm_mode_create_dumb" :
+
+.in +4n
+.nf
+struct drm_mode_create_dumb {
+ __u32 height;
+ __u32 width;
+ __u32 bpp;
+ __u32 flags;
+
+ __u32 handle;
+ __u32 pitch;
+ __u64 size;
+};
+.fi
+.in
+
+The fields
+.IR "height" ", " "width" ", " "bpp" " and " "flags"
+have to be provided by the caller. The other fields are filled by the kernel
+with the return values.
+.IR "height" " and " "width"
+are the dimensions of the rectangular buffer that is created.
+.I "bpp"
+is the number of bits-per-pixel and must be a multiple of
+.IR 8 "."
+You most commonly want to pass
+.I 32
+here. The
+.I "flags"
+field is currently unused and must be zeroed. Different flags to modify the
+behavior may be added in the future.
+.br
+After calling the ioctl, the
+.IR "handle" ", " "pitch" " and " "size"
+fields are filled by the kernel.
+.I "handle"
+is a 32bit gem handle that identifies the buffer. This is used by several other
+calls that take a gem-handle or memory-buffer as argument. The
+.I "pitch"
+field is the
+.IR pitch " or " stride
+of the new buffer. Most drivers use 32bit or 64bit aligned stride-values. The
+.I "size"
+field contains the absolute size in bytes of the buffer. This can normally also
+be computed with
+"(height * pitch + width) * bpp / 4".
+
+To prepare the buffer for
+.BR mmap (2)
+you need to use the
+.B DRM_IOCTL_MODE_MAP_DUMB
+ioctl. It takes as argument a structure of type
+.IR "struct drm_mode_map_dumb" :
+
+.in +4n
+.nf
+struct drm_mode_map_dumb {
+ __u32 handle;
+ __u32 pad;
+
+ __u64 offset;
+};
+.fi
+.in
+
+You need to put the gem-handle that was previously retrieved via
+.B DRM_IOCTL_MODE_CREATE_DUMB
+into the
+.I "handle"
+field. The
+.I "pad"
+field is unused padding and must be zeroed. After completion, the
+.I offset
+field will contain an offset that can be used with
+.BR mmap (2)
+on the DRM file-descriptor.
+
+If you don't need your dumb-buffer, anymore, you have to destroy it with
+.BR DRM_IOCTL_MODE_DESTROY_DUMB "."
+If you close the DRM file-descriptor, all open dumb-buffers are automatically
+destroyed.
+.br
+This ioctl takes as argument a structure of type
+.IR "struct drm_mode_destroy_dumb" :
+
+.in +4n
+.nf
+struct drm_mode_destroy_dumb {
+ __u32 handle;
+};
+.fi
+.in
+
+You only need to put your handle into the
+.I handle
+field. After this call, the handle is invalid and may be reused for new buffers
+by the dumb-API.
+
+.SS TTM
+.B TTM
+stands for
+.B Translation Table Manager
+and is another generic memory-manager provided by the kernel. Only the radeon
+driver uses it. See the radeon manpages for more information on
+memory-management with radeon and TTM.
+
+.SS GEM
+.B GEM
+stands for
+.B Graphics Execution Manager
+and is a generic DRM memory-management framework in the kernel, that is used by
+many different drivers. Gem is designed to manage graphics memory, control
+access to the graphics device execution context and handle essentially NUMA
+environment unique to modern graphics hardware. Gem allows multiple applications
+to share graphics device resources without the need to constantly reload the
+entire graphics card. Data may be shared between multiple applications with gem
+ensuring that the correct memory synchronization occurs.
+
+Gem provides simple mechanisms to manage graphics data and control execution
+flow within the linux DRM subsystem. However, gem is not a complete framework
+that is fully driver independent. Instead, if provides many functions that are
+shared between many drivers, but each driver has to implement most of
+memory-management with driver-dependent ioctls. This manpage tries to describe
+the semantics (and if it applies, the syntax) that is shared between all drivers
+that use gem.
+
+All GEM APIs are defined as
+.BR ioctl (2)
+on the DRM file descriptor. An application must be authorized via
+.BR drmAuthMagic (2)
+to the current DRM-Master to access the GEM subsystem. A driver that does not
+support gem will return
+.I ENODEV
+for all these ioctls. Invalid object handles return
+.I EINVAL
+and invalid object names return
+.IR ENOENT "."
+
+Gem provides explicit memory management primitives. System pages are allocated
+when the object is created, either as the fundamental storage for hardware where
+system memory is used by the graphics processor directly, or as backing store
+for graphics-processor resident memory.
+
+Objects are referenced from user-space using handles. These are, for all intents
+and purposes, equivalent to file descriptors but avoid the overhead. Newer
+kernel drivers also support the
+.BR drm-prime (7)
+infrastructure which can return real file-descriptor for gem-handles using the
+linux dma-buf API.
+.br
+Objects may be published with a name so that other applications and processes
+can access them. The name remains valid as long as the object exists.
+.br
+Gem-objects are reference counted in the kernel. The object is only destroyed
+when all handles from user-space were closed.
+
+Gem-buffers cannot be created with a generic API. Each driver provides its own
+API to create gem-buffers. See for example
+.BR DRM_I915_GEM_CREATE ", " DRM_NOUVEAU_GEM_NEW " or " DRM_RADEON_GEM_CREATE .
+Each of these ioctls returns a gem-handle that can be passed to different
+generic ioctls.
+.br
+The
+.I libgbm
+library from the
+.I mesa3D
+distribution tries to provide a driver-independent API to create gbm buffers and
+retrieve a gbm-handle to them. It allows to create buffers for different
+use-cases including scanout, rendering, cursors and CPU-access. See the libgbm
+library for more information or look at the driver-dependent man-pages
+.RI "(for example " drm-intel "(7) or " drm-radeon "(7))."
+
+Gem-buffers can be closed with the
+.B DRM_IOCTL_GEM_CLOSE
+ioctl. It takes as argument a structure of type
+.IR "struct drm_gem_close" :
+
+.in +4n
+.nf
+struct drm_gem_close {
+ __u32 handle;
+ __u32 pad;
+};
+.fi
+.in
+
+The
+.I handle
+field is the gem-handle to be closed. The
+.I pad
+field is unused padding. It must be zeroed. After this call the gem handle
+cannot be used by this process anymore and may be reused for new gem objects by
+the gem API.
+
+If you want to share gem-objects between different processes, you can create a
+name for them and pass this name to other processes which can then open this
+gem-object. Names are currently 32bit integer IDs and have no special
+protection. That is, if you put a name on your gem-object, every other client
+that has access to the DRM device and is authenticated via
+.BR drmAuthMagic (3)
+to the current DRM-Master, can
+.I guess
+the name and open or access the gem-object. If you want more fine-grained access
+control, you can use the new
+.BR drm-prime (7)
+API to retrieve file-descriptors for gem-handles.
+.br
+To create a name for a gem-handle, you use the
+.B DRM_IOCTL_GEM_FLINK
+ioctl. It takes as argument a structure of type
+.IR "struct drm_gem_flink" :
+
+.in +4n
+.nf
+struct drm_gem_flink {
+ __u32 handle;
+ __u32 name;
+};
+.fi
+.in
+
+You have to put your handle into the
+.I handle
+field. After completion, the kernel has put the new unique name into the
+.I name
+field. You can now pass this name to other processes which can then import the
+name with the
+.B DRM_IOCTL_GEM_OPEN
+ioctl. It takes as argument a structure of type
+.IR "struct drm_gem_open" :
+
+.in +4n
+.nf
+struct drm_gem_open {
+ __u32 name;
+
+ __u32 handle;
+ __u32 size;
+};
+.fi
+.in
+
+You have to fill in the
+.I name
+field with the name of the gem-object that you want to open. The kernel will
+fill in the
+.I handle
+and
+.I size
+fields with the new handle and size of the gem-object. You can now access the
+gem-object via the handle as if you created it with the gem API.
+
+Besides generic buffer management, the GEM API does not provide any generic
+access. Each driver implements its own functionality on top of this API. This
+includes execution-buffers, GTT management, context creation, CPU access, GPU
+I/O and more.
+.br
+The next higher-level API is
+.BR OpenGL .
+So if you want to use more GPU features, you should use the
+.I mesa3D
+library to create OpenGL contexts on DRM devices. This does
+.I not
+require any windowing-system like X11, but can also be done on raw DRM devices.
+However, this is beyond the scope of this man-page. You may have a look at other
+mesa3D manpages, including libgbm and libEGL.
+2D software-rendering (rendering with the CPU) can be achieved with the
+dumb-buffer-API in a driver-independent fashion, however, for
+hardware-accelerated 2D or 3D rendering you must use OpenGL. Any other API that
+tries to abstract the driver-internals to access GEM-execution-buffers and other
+GPU internals, would simply reinvent OpenGL so it is not provided. But if you
+need more detailed information for a specific driver, you may have a look into
+the driver-manpages, including
+.BR drm-intel "(7), " drm-radeon "(7) and " drm-nouveau (7).
+.br
+However, the
+.BR drm-prime (7)
+infrastructure and the generic gem API as described here allow display-managers
+to handle graphics-buffers and render-clients without any deeper knowledge of
+the GPU that is used. Moreover, it allows to move objects between GPUs and
+implement complex display-servers that don't do any rendering on their own. See
+its man-page for more information.
+
+.SH EXAMPLES
+This section includes examples for basic memory-management tasks.
+
+.SS Dumb-Buffers
+This examples shows how to create a dumb-buffer via the generic DRM API. This is
+driver-independent (as long as the driver supports dumb-buffers) and provides
+memory-mapped buffers that can be used for scanout.
+.br
+This example creates a full-HD 1920x1080 buffer with 32 bits-per-pixel and a
+color-depth of 24 bits. The buffer is then bound to a framebuffer which can be
+used for scanout with the KMS API
+.RB "(see " drm-kms "(7))."
+
+.in +4n
+.nf
+ struct drm_mode_create_dumb creq;
+ struct drm_mode_destroy_dumb dreq;
+ struct drm_mode_map_dumb mreq;
+ uint32_t fb;
+ int ret;
+ void *map;
+
+ /* create dumb buffer */
+ memset(&creq, 0, sizeof(creq));
+ creq.width = 1920;
+ creq.height = 1080;
+ creq.bpp = 32;
+ ret = drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &creq);
+ if (ret < 0) {
+ /* buffer creation failed; see "errno" for more error codes */
+ ...
+ }
+ /* creq.pitch, creq.handle and creq.size are filled by this ioctl with
+ * the requested values and can be used now. */
+
+ /* create framebuffer object for the dumb-buffer */
+ ret = drmModeAddFB(fd, 1920, 1080, 24, 32, creq.pitch, creq.handle, &fb);
+ if (ret) {
+ /* frame buffer creation failed; see "errno" */
+ ...
+ }
+ /* the framebuffer "fb" can now used for scanout with KMS */
+
+ /* prepare buffer for memory mapping */
+ memset(&mreq, 0, sizeof(mreq));
+ mreq.handle = creq.handle;
+ ret = drmIoctl(fd, DRM_IOCTL_MODE_MAP_DUMB, &mreq);
+ if (ret) {
+ /* DRM buffer preparation failed; see "errno" */
+ ...
+ }
+ /* mreq.offset now contains the new offset that can be used with mmap() */
+
+ /* perform actual memory mapping */
+ map = mmap(0, creq.size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, mreq.offset);
+ if (map == MAP_FAILED) {
+ /* memory-mapping failed; see "errno" */
+ ...
+ }
+
+ /* clear the framebuffer to 0 */
+ memset(map, 0, creq.size);
+.fi
+.in
+
+.SH REPORTING BUGS
+Bugs in this manual should be reported to http://bugs.freedesktop.org under
+the "Mesa" product, with "Other" or "libdrm" as the component.
+
+.SH "SEE ALSO"
+.BR drm (7),
+.BR drm-kms (7),
+.BR drmAvailable (3),
+.BR drmOpen (3),
+.BR drm-intel (7),
+.BR drm-radeon (7),
+.BR drm-nouveau (7),
+.BR drm-prime (7)
diff --git a/man/drm-mm.7 b/man/drm-mm.7
new file mode 100644
index 0000000..258b5a3
--- /dev/null
+++ b/man/drm-mm.7
@@ -0,0 +1 @@
+.so man7/drm-memory.7
diff --git a/man/drm-ttm.7 b/man/drm-ttm.7
new file mode 100644
index 0000000..258b5a3
--- /dev/null
+++ b/man/drm-ttm.7
@@ -0,0 +1 @@
+.so man7/drm-memory.7
--
1.7.12.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH libdrm 4/4] man: add drm-memory man-page
2012-09-23 14:40 ` [PATCH libdrm 4/4] man: add drm-memory man-page David Herrmann
@ 2012-09-24 7:45 ` Michel Dänzer
2012-09-24 16:58 ` David Herrmann
2012-09-27 16:31 ` Jesse Barnes
1 sibling, 1 reply; 14+ messages in thread
From: Michel Dänzer @ 2012-09-24 7:45 UTC (permalink / raw)
To: David Herrmann; +Cc: dri-devel
On Son, 2012-09-23 at 16:40 +0200, David Herrmann wrote:
> +
> +.SS TTM
> +.B TTM
> +stands for
> +.B Translation Table Manager
> +and is another generic memory-manager provided by the kernel. Only the radeon
> +driver uses it. See the radeon manpages for more information on
> +memory-management with radeon and TTM.
What made you think only radeon uses TTM? nouveau, vmwgfx, ast, cirrus
and mgag200 also use it. I suspect the emerging openchrome KMS support
does as well.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH libdrm 4/4] man: add drm-memory man-page
2012-09-24 7:45 ` Michel Dänzer
@ 2012-09-24 16:58 ` David Herrmann
0 siblings, 0 replies; 14+ messages in thread
From: David Herrmann @ 2012-09-24 16:58 UTC (permalink / raw)
To: Michel Dänzer; +Cc: dri-devel
Hi Michel
On Mon, Sep 24, 2012 at 9:45 AM, Michel Dänzer <michel@daenzer.net> wrote:
> On Son, 2012-09-23 at 16:40 +0200, David Herrmann wrote:
>> +
>> +.SS TTM
>> +.B TTM
>> +stands for
>> +.B Translation Table Manager
>> +and is another generic memory-manager provided by the kernel. Only the radeon
>> +driver uses it. See the radeon manpages for more information on
>> +memory-management with radeon and TTM.
>
> What made you think only radeon uses TTM? nouveau, vmwgfx, ast, cirrus
> and mgag200 also use it. I suspect the emerging openchrome KMS support
> does as well.
Whoops, that was my first conception, but I forgot to fix that.
Anyway, I didn't know of any generic API that I could write about here
either so I think I will leave the "TTM" section pretty short. Or any
ideas what could be included here?
Thanks for reviewing! Will be fixed in the next revision.
David
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH libdrm 4/4] man: add drm-memory man-page
2012-09-23 14:40 ` [PATCH libdrm 4/4] man: add drm-memory man-page David Herrmann
2012-09-24 7:45 ` Michel Dänzer
@ 2012-09-27 16:31 ` Jesse Barnes
1 sibling, 0 replies; 14+ messages in thread
From: Jesse Barnes @ 2012-09-27 16:31 UTC (permalink / raw)
To: David Herrmann; +Cc: dri-devel
On Sun, 23 Sep 2012 16:40:07 +0200
David Herrmann <dh.herrmann@googlemail.com> wrote:
> The drm-memory man-page (aliased as drm-gem, drm-mm and drm-ttm) describes
> the high-level overview of different memory-management frameworks used in
> the DRM subsystem. It is really targeted at driver-independent semantics
> (and where it applies, syntax). It links to all other man-pages if more
> driver-dependent information is needed.
>
> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
> ---
> man/Makefile.am | 4 +
> man/drm-gem.7 | 1 +
> man/drm-memory.7 | 412 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> man/drm-mm.7 | 1 +
> man/drm-ttm.7 | 1 +
> 5 files changed, 419 insertions(+)
> create mode 100644 man/drm-gem.7
> create mode 100644 man/drm-memory.7
> create mode 100644 man/drm-mm.7
> create mode 100644 man/drm-ttm.7
>
> diff --git a/man/Makefile.am b/man/Makefile.am
> index 7ce7ac4..ded3b4a 100644
> --- a/man/Makefile.am
> +++ b/man/Makefile.am
> @@ -1,6 +1,10 @@
> man_MANS = \
> drm.7 \
> drm-kms.7 \
> + drm-memory.7 \
> + drm-mm.7 \
> + drm-gem.7 \
> + drm-ttm.7 \
> drmAvailable.3 \
> drmHandleEvent.3 \
> drmModeGetResources.3
> diff --git a/man/drm-gem.7 b/man/drm-gem.7
> new file mode 100644
> index 0000000..258b5a3
> --- /dev/null
> +++ b/man/drm-gem.7
> @@ -0,0 +1 @@
> +.so man7/drm-memory.7
> diff --git a/man/drm-memory.7 b/man/drm-memory.7
> new file mode 100644
> index 0000000..1eff38a
> --- /dev/null
> +++ b/man/drm-memory.7
> @@ -0,0 +1,412 @@
> +.\"
> +.\" Written 2012 by David Herrmann
> +.\" Dedicated to the Public Domain
> +.\"
> +.TH "DRM-MEMORY" 7 "September 2012" "libdrm" "Direct Rendering Manager"
> +.SH NAME
> +DRM-Memory \- DRM Memory Management
> +
> +.SH SYNOPSIS
> +.B #include <xf86drm.h>
> +
> +.SH DESCRIPTION
> +Many modern high-end GPUs come with their own memory managers. They even include
> +several different caches that need to be synchronized during access. Textures,
> +framebuffers, command buffers and more need to be stored in memory that can be
> +accessed quickly by the GPU. Therefore, memory management on GPUs is highly
> +driver\- and hardware\-dependent.
> +
> +However, there are several frameworks in the kernel that are used by more than
> +one driver. These can be used for trivial mode-setting without requiring
> +driver-dependent code. But for hardware-accelerated rendering you need to read
> +the manual pages for the driver you want to work with.
> +
> +.SS Dumb-Buffers
> +Almost all in-kernel DRM hardware drivers support an API called
> +.BR "Dumb-Buffers" "."
> +This API allows to create buffers of arbitrary size that can be used for
> +scanout. These buffers can be memory mapped via
> +.BR mmap (2)
> +so you can render into them on the CPU. However, GPU access to these buffers is
> +often not possible. Therefore, they are fine for simple tasks but not suitable
> +for complex compositions and renderings.
> +
> +The
> +.B DRM_IOCTL_MODE_CREATE_DUMB
> +ioctl can be used to create a dumb buffer. The kernel will return a 32bit handle
> +that can be used to manage the buffer with the DRM API. You can create
> +framebuffers with
> +.BR drmModeAddFB (3)
> +and use it for mode-setting and scanout.
> +.br
> +To access the buffer, you first need to retrieve the offset of the buffer. The
> +.B DRM_IOCTL_MODE_MAP_DUMB
> +ioctl requests the DRM subsystem to prepare the buffer for memory-mapping and
> +returns a fake-offset that can be used with
> +.BR mmap "(2)."
> +
> +The
> +.B DRM_IOCTL_MODE_CREATE_DUMB
> +ioctl takes as argument a structure of type
> +.IR "struct drm_mode_create_dumb" :
> +
> +.in +4n
> +.nf
> +struct drm_mode_create_dumb {
> + __u32 height;
> + __u32 width;
> + __u32 bpp;
> + __u32 flags;
> +
> + __u32 handle;
> + __u32 pitch;
> + __u64 size;
> +};
> +.fi
> +.in
> +
> +The fields
> +.IR "height" ", " "width" ", " "bpp" " and " "flags"
> +have to be provided by the caller. The other fields are filled by the kernel
> +with the return values.
> +.IR "height" " and " "width"
> +are the dimensions of the rectangular buffer that is created.
> +.I "bpp"
> +is the number of bits-per-pixel and must be a multiple of
> +.IR 8 "."
> +You most commonly want to pass
> +.I 32
> +here. The
> +.I "flags"
> +field is currently unused and must be zeroed. Different flags to modify the
> +behavior may be added in the future.
> +.br
> +After calling the ioctl, the
> +.IR "handle" ", " "pitch" " and " "size"
> +fields are filled by the kernel.
> +.I "handle"
> +is a 32bit gem handle that identifies the buffer. This is used by several other
> +calls that take a gem-handle or memory-buffer as argument. The
> +.I "pitch"
> +field is the
> +.IR pitch " or " stride
> +of the new buffer. Most drivers use 32bit or 64bit aligned stride-values. The
> +.I "size"
> +field contains the absolute size in bytes of the buffer. This can normally also
> +be computed with
> +"(height * pitch + width) * bpp / 4".
> +
> +To prepare the buffer for
> +.BR mmap (2)
> +you need to use the
> +.B DRM_IOCTL_MODE_MAP_DUMB
> +ioctl. It takes as argument a structure of type
> +.IR "struct drm_mode_map_dumb" :
> +
> +.in +4n
> +.nf
> +struct drm_mode_map_dumb {
> + __u32 handle;
> + __u32 pad;
> +
> + __u64 offset;
> +};
> +.fi
> +.in
> +
> +You need to put the gem-handle that was previously retrieved via
> +.B DRM_IOCTL_MODE_CREATE_DUMB
> +into the
> +.I "handle"
> +field. The
> +.I "pad"
> +field is unused padding and must be zeroed. After completion, the
> +.I offset
> +field will contain an offset that can be used with
> +.BR mmap (2)
> +on the DRM file-descriptor.
> +
> +If you don't need your dumb-buffer, anymore, you have to destroy it with
> +.BR DRM_IOCTL_MODE_DESTROY_DUMB "."
> +If you close the DRM file-descriptor, all open dumb-buffers are automatically
> +destroyed.
> +.br
> +This ioctl takes as argument a structure of type
> +.IR "struct drm_mode_destroy_dumb" :
> +
> +.in +4n
> +.nf
> +struct drm_mode_destroy_dumb {
> + __u32 handle;
> +};
> +.fi
> +.in
> +
> +You only need to put your handle into the
> +.I handle
> +field. After this call, the handle is invalid and may be reused for new buffers
> +by the dumb-API.
> +
> +.SS TTM
> +.B TTM
> +stands for
> +.B Translation Table Manager
> +and is another generic memory-manager provided by the kernel. Only the radeon
> +driver uses it. See the radeon manpages for more information on
> +memory-management with radeon and TTM.
> +
> +.SS GEM
> +.B GEM
> +stands for
> +.B Graphics Execution Manager
> +and is a generic DRM memory-management framework in the kernel, that is used by
> +many different drivers. Gem is designed to manage graphics memory, control
> +access to the graphics device execution context and handle essentially NUMA
> +environment unique to modern graphics hardware. Gem allows multiple applications
> +to share graphics device resources without the need to constantly reload the
> +entire graphics card. Data may be shared between multiple applications with gem
> +ensuring that the correct memory synchronization occurs.
> +
> +Gem provides simple mechanisms to manage graphics data and control execution
> +flow within the linux DRM subsystem. However, gem is not a complete framework
> +that is fully driver independent. Instead, if provides many functions that are
> +shared between many drivers, but each driver has to implement most of
> +memory-management with driver-dependent ioctls. This manpage tries to describe
> +the semantics (and if it applies, the syntax) that is shared between all drivers
> +that use gem.
> +
> +All GEM APIs are defined as
> +.BR ioctl (2)
> +on the DRM file descriptor. An application must be authorized via
> +.BR drmAuthMagic (2)
> +to the current DRM-Master to access the GEM subsystem. A driver that does not
> +support gem will return
> +.I ENODEV
> +for all these ioctls. Invalid object handles return
> +.I EINVAL
> +and invalid object names return
> +.IR ENOENT "."
> +
> +Gem provides explicit memory management primitives. System pages are allocated
> +when the object is created, either as the fundamental storage for hardware where
> +system memory is used by the graphics processor directly, or as backing store
> +for graphics-processor resident memory.
> +
> +Objects are referenced from user-space using handles. These are, for all intents
> +and purposes, equivalent to file descriptors but avoid the overhead. Newer
> +kernel drivers also support the
> +.BR drm-prime (7)
> +infrastructure which can return real file-descriptor for gem-handles using the
> +linux dma-buf API.
> +.br
> +Objects may be published with a name so that other applications and processes
> +can access them. The name remains valid as long as the object exists.
> +.br
> +Gem-objects are reference counted in the kernel. The object is only destroyed
> +when all handles from user-space were closed.
> +
> +Gem-buffers cannot be created with a generic API. Each driver provides its own
> +API to create gem-buffers. See for example
> +.BR DRM_I915_GEM_CREATE ", " DRM_NOUVEAU_GEM_NEW " or " DRM_RADEON_GEM_CREATE .
> +Each of these ioctls returns a gem-handle that can be passed to different
> +generic ioctls.
> +.br
> +The
> +.I libgbm
> +library from the
> +.I mesa3D
> +distribution tries to provide a driver-independent API to create gbm buffers and
> +retrieve a gbm-handle to them. It allows to create buffers for different
> +use-cases including scanout, rendering, cursors and CPU-access. See the libgbm
> +library for more information or look at the driver-dependent man-pages
> +.RI "(for example " drm-intel "(7) or " drm-radeon "(7))."
> +
> +Gem-buffers can be closed with the
> +.B DRM_IOCTL_GEM_CLOSE
> +ioctl. It takes as argument a structure of type
> +.IR "struct drm_gem_close" :
> +
> +.in +4n
> +.nf
> +struct drm_gem_close {
> + __u32 handle;
> + __u32 pad;
> +};
> +.fi
> +.in
> +
> +The
> +.I handle
> +field is the gem-handle to be closed. The
> +.I pad
> +field is unused padding. It must be zeroed. After this call the gem handle
> +cannot be used by this process anymore and may be reused for new gem objects by
> +the gem API.
> +
> +If you want to share gem-objects between different processes, you can create a
> +name for them and pass this name to other processes which can then open this
> +gem-object. Names are currently 32bit integer IDs and have no special
> +protection. That is, if you put a name on your gem-object, every other client
> +that has access to the DRM device and is authenticated via
> +.BR drmAuthMagic (3)
> +to the current DRM-Master, can
> +.I guess
> +the name and open or access the gem-object. If you want more fine-grained access
> +control, you can use the new
> +.BR drm-prime (7)
> +API to retrieve file-descriptors for gem-handles.
> +.br
> +To create a name for a gem-handle, you use the
> +.B DRM_IOCTL_GEM_FLINK
> +ioctl. It takes as argument a structure of type
> +.IR "struct drm_gem_flink" :
> +
> +.in +4n
> +.nf
> +struct drm_gem_flink {
> + __u32 handle;
> + __u32 name;
> +};
> +.fi
> +.in
> +
> +You have to put your handle into the
> +.I handle
> +field. After completion, the kernel has put the new unique name into the
> +.I name
> +field. You can now pass this name to other processes which can then import the
> +name with the
> +.B DRM_IOCTL_GEM_OPEN
> +ioctl. It takes as argument a structure of type
> +.IR "struct drm_gem_open" :
> +
> +.in +4n
> +.nf
> +struct drm_gem_open {
> + __u32 name;
> +
> + __u32 handle;
> + __u32 size;
> +};
> +.fi
> +.in
> +
> +You have to fill in the
> +.I name
> +field with the name of the gem-object that you want to open. The kernel will
> +fill in the
> +.I handle
> +and
> +.I size
> +fields with the new handle and size of the gem-object. You can now access the
> +gem-object via the handle as if you created it with the gem API.
> +
> +Besides generic buffer management, the GEM API does not provide any generic
> +access. Each driver implements its own functionality on top of this API. This
> +includes execution-buffers, GTT management, context creation, CPU access, GPU
> +I/O and more.
> +.br
> +The next higher-level API is
> +.BR OpenGL .
> +So if you want to use more GPU features, you should use the
> +.I mesa3D
> +library to create OpenGL contexts on DRM devices. This does
> +.I not
> +require any windowing-system like X11, but can also be done on raw DRM devices.
> +However, this is beyond the scope of this man-page. You may have a look at other
> +mesa3D manpages, including libgbm and libEGL.
> +2D software-rendering (rendering with the CPU) can be achieved with the
> +dumb-buffer-API in a driver-independent fashion, however, for
> +hardware-accelerated 2D or 3D rendering you must use OpenGL. Any other API that
> +tries to abstract the driver-internals to access GEM-execution-buffers and other
> +GPU internals, would simply reinvent OpenGL so it is not provided. But if you
> +need more detailed information for a specific driver, you may have a look into
> +the driver-manpages, including
> +.BR drm-intel "(7), " drm-radeon "(7) and " drm-nouveau (7).
> +.br
> +However, the
> +.BR drm-prime (7)
> +infrastructure and the generic gem API as described here allow display-managers
> +to handle graphics-buffers and render-clients without any deeper knowledge of
> +the GPU that is used. Moreover, it allows to move objects between GPUs and
> +implement complex display-servers that don't do any rendering on their own. See
> +its man-page for more information.
> +
> +.SH EXAMPLES
> +This section includes examples for basic memory-management tasks.
> +
> +.SS Dumb-Buffers
> +This examples shows how to create a dumb-buffer via the generic DRM API. This is
> +driver-independent (as long as the driver supports dumb-buffers) and provides
> +memory-mapped buffers that can be used for scanout.
> +.br
> +This example creates a full-HD 1920x1080 buffer with 32 bits-per-pixel and a
> +color-depth of 24 bits. The buffer is then bound to a framebuffer which can be
> +used for scanout with the KMS API
> +.RB "(see " drm-kms "(7))."
> +
> +.in +4n
> +.nf
> + struct drm_mode_create_dumb creq;
> + struct drm_mode_destroy_dumb dreq;
> + struct drm_mode_map_dumb mreq;
> + uint32_t fb;
> + int ret;
> + void *map;
> +
> + /* create dumb buffer */
> + memset(&creq, 0, sizeof(creq));
> + creq.width = 1920;
> + creq.height = 1080;
> + creq.bpp = 32;
> + ret = drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &creq);
> + if (ret < 0) {
> + /* buffer creation failed; see "errno" for more error codes */
> + ...
> + }
> + /* creq.pitch, creq.handle and creq.size are filled by this ioctl with
> + * the requested values and can be used now. */
> +
> + /* create framebuffer object for the dumb-buffer */
> + ret = drmModeAddFB(fd, 1920, 1080, 24, 32, creq.pitch, creq.handle, &fb);
> + if (ret) {
> + /* frame buffer creation failed; see "errno" */
> + ...
> + }
> + /* the framebuffer "fb" can now used for scanout with KMS */
> +
> + /* prepare buffer for memory mapping */
> + memset(&mreq, 0, sizeof(mreq));
> + mreq.handle = creq.handle;
> + ret = drmIoctl(fd, DRM_IOCTL_MODE_MAP_DUMB, &mreq);
> + if (ret) {
> + /* DRM buffer preparation failed; see "errno" */
> + ...
> + }
> + /* mreq.offset now contains the new offset that can be used with mmap() */
> +
> + /* perform actual memory mapping */
> + map = mmap(0, creq.size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, mreq.offset);
> + if (map == MAP_FAILED) {
> + /* memory-mapping failed; see "errno" */
> + ...
> + }
> +
> + /* clear the framebuffer to 0 */
> + memset(map, 0, creq.size);
> +.fi
> +.in
> +
> +.SH REPORTING BUGS
> +Bugs in this manual should be reported to http://bugs.freedesktop.org under
> +the "Mesa" product, with "Other" or "libdrm" as the component.
> +
> +.SH "SEE ALSO"
> +.BR drm (7),
> +.BR drm-kms (7),
> +.BR drmAvailable (3),
> +.BR drmOpen (3),
> +.BR drm-intel (7),
> +.BR drm-radeon (7),
> +.BR drm-nouveau (7),
> +.BR drm-prime (7)
> diff --git a/man/drm-mm.7 b/man/drm-mm.7
> new file mode 100644
> index 0000000..258b5a3
> --- /dev/null
> +++ b/man/drm-mm.7
> @@ -0,0 +1 @@
> +.so man7/drm-memory.7
> diff --git a/man/drm-ttm.7 b/man/drm-ttm.7
> new file mode 100644
> index 0000000..258b5a3
> --- /dev/null
> +++ b/man/drm-ttm.7
> @@ -0,0 +1 @@
> +.so man7/drm-memory.7
Heh, this one highlights the lack of documentation we have for other
libs like Mesa and libgbm. :)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH libdrm 0/4] Overview man-pages for libdrm
2012-09-23 14:40 [PATCH libdrm 0/4] Overview man-pages for libdrm David Herrmann
` (3 preceding siblings ...)
2012-09-23 14:40 ` [PATCH libdrm 4/4] man: add drm-memory man-page David Herrmann
@ 2012-09-24 19:51 ` Thierry Reding
2012-09-24 21:35 ` David Herrmann
2012-09-24 21:41 ` Alan Coopersmith
5 siblings, 1 reply; 14+ messages in thread
From: Thierry Reding @ 2012-09-24 19:51 UTC (permalink / raw)
To: David Herrmann; +Cc: dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 1914 bytes --]
On Sun, Sep 23, 2012 at 04:40:03PM +0200, David Herrmann wrote:
> Hi
>
> This tries to continue the effort to document libdrm. I actually removed the
> X11-like man-page generation code as autotools now support man_MANS. The
> previous approach required every manpage to be in the same man-group. However,
> API calls belong in man3 and overview pages into man7. So I just use the simpler
> approach without all the replacements. It turns out, no man-page did use them so
> we can add it again if one really needs them.
>
> The other 3 patches add a generic drm.7 overview page, a drm-kms.7 overview page
> and a drm-memory.7 overview page. Also some aliases are installed, including
> drm-gem.7 => drm-memory.7
> drm-ttm.7 => drm-memory.7
> Please note that you cannot open the aliased pages with "man ./man/drm-gem.7".
> You must install them before they work correctly as they require the directory
> to be "man7" not "man".
You should be able to do "man -l ./man/drm-gem.7" without the need to
install.
> Anyway, any comments are welcome. This is really just something to start on and
> any corrections are appreciated.
>
> I have also added many dead-links to some other overview pages, including
> drm-prime.7: Short introduction to the PRIME API
> drm-intel.7,
> drm-radeon.7,
> drm-noueveau.7: Driver-dependent DRM API
> And many links to undocumented API calls. Feel free to write short stub-pages
> for any of them. It's better than nothing.
>
> I am also no groff/troff expert, but I think the pages look quite nice. And I
> recommend reading the pages with "man ./man/drm*.7" if you want to review them.
> Plain troff is really ugly to read.
Did you consider rewriting the man-pages in docbook? Generating the
manpages is usually more involved but it also allows other forms of
documentation (PDF, HTML, ...) to be generated easily.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH libdrm 0/4] Overview man-pages for libdrm
2012-09-24 19:51 ` [PATCH libdrm 0/4] Overview man-pages for libdrm Thierry Reding
@ 2012-09-24 21:35 ` David Herrmann
0 siblings, 0 replies; 14+ messages in thread
From: David Herrmann @ 2012-09-24 21:35 UTC (permalink / raw)
To: Thierry Reding; +Cc: dri-devel
Hi Thierry
On Mon, Sep 24, 2012 at 9:51 PM, Thierry Reding
<thierry.reding@avionic-design.de> wrote:
> On Sun, Sep 23, 2012 at 04:40:03PM +0200, David Herrmann wrote:
>> Hi
>>
>> This tries to continue the effort to document libdrm. I actually removed the
>> X11-like man-page generation code as autotools now support man_MANS. The
>> previous approach required every manpage to be in the same man-group. However,
>> API calls belong in man3 and overview pages into man7. So I just use the simpler
>> approach without all the replacements. It turns out, no man-page did use them so
>> we can add it again if one really needs them.
>>
>> The other 3 patches add a generic drm.7 overview page, a drm-kms.7 overview page
>> and a drm-memory.7 overview page. Also some aliases are installed, including
>> drm-gem.7 => drm-memory.7
>> drm-ttm.7 => drm-memory.7
>> Please note that you cannot open the aliased pages with "man ./man/drm-gem.7".
>> You must install them before they work correctly as they require the directory
>> to be "man7" not "man".
>
> You should be able to do "man -l ./man/drm-gem.7" without the need to
> install.
Ah, thanks, that works.
>> Anyway, any comments are welcome. This is really just something to start on and
>> any corrections are appreciated.
>>
>> I have also added many dead-links to some other overview pages, including
>> drm-prime.7: Short introduction to the PRIME API
>> drm-intel.7,
>> drm-radeon.7,
>> drm-noueveau.7: Driver-dependent DRM API
>> And many links to undocumented API calls. Feel free to write short stub-pages
>> for any of them. It's better than nothing.
>>
>> I am also no groff/troff expert, but I think the pages look quite nice. And I
>> recommend reading the pages with "man ./man/drm*.7" if you want to review them.
>> Plain troff is really ugly to read.
>
> Did you consider rewriting the man-pages in docbook? Generating the
> manpages is usually more involved but it also allows other forms of
> documentation (PDF, HTML, ...) to be generated easily.
I played with docbook today to create some wayland man-pages. Apart
from an install-bug for aliases that I had to fix with a short SED
script, it works nicely. I think I will convert it to XML files in the
next revision.
Thanks!
David
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH libdrm 0/4] Overview man-pages for libdrm
2012-09-23 14:40 [PATCH libdrm 0/4] Overview man-pages for libdrm David Herrmann
` (4 preceding siblings ...)
2012-09-24 19:51 ` [PATCH libdrm 0/4] Overview man-pages for libdrm Thierry Reding
@ 2012-09-24 21:41 ` Alan Coopersmith
5 siblings, 0 replies; 14+ messages in thread
From: Alan Coopersmith @ 2012-09-24 21:41 UTC (permalink / raw)
To: David Herrmann; +Cc: dri-devel
On 09/23/12 03:40 PM, David Herrmann wrote:
> Hi
>
> This tries to continue the effort to document libdrm. I actually removed the
> X11-like man-page generation code as autotools now support man_MANS. The
> previous approach required every manpage to be in the same man-group. However,
> API calls belong in man3 and overview pages into man7. So I just use the simpler
> approach without all the replacements. It turns out, no man-page did use them so
> we can add it again if one really needs them.
The X.Org rules were made to handle distros & OS'es using different man
sections. For instance, on System V OS'es (including Solaris), overview man
pages go in section 5, drivers in section 7. Linux adopted the BSD section
numbers, so this is much less interesting for libdrm than it was for XFree86
and X.Org back in the day, since we can just patch Solaris into working and
let upstream use the common section numbers for the rest.
--
-Alan Coopersmith- alan.coopersmith@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
^ permalink raw reply [flat|nested] 14+ messages in thread