summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorMichael Witten <mfwitten@gmail.com>2011-08-29 17:58:46 +0000
committerMichael Witten <mfwitten@gmail.com>2011-08-29 20:00:32 +0000
commit5a462d58c84a2f5ed161daced2c7df34357c6d3d (patch)
treec393849b004832a53ef749e7230ef3e92c53c2d1 /Documentation
parent964d32dcbefcfda015bc33dc76414b05c6f512de (diff)
downloadlinux-next-5a462d58c84a2f5ed161daced2c7df34357c6d3d.tar.gz
DocBook/drm: Clean up the paragraph on framebuffer objects
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/DocBook/drm.tmpl14
1 files changed, 6 insertions, 8 deletions
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 606a989d8895..a39e76bae03d 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -795,14 +795,12 @@ void intel_crt_init(struct drm_device *dev)
<sect1>
<title>Framebuffer management</title>
<para>
- In order to set a mode on a given CRTC, encoder and connector
- configuration, clients need to provide a framebuffer object which
- provides a source of pixels for the CRTC to deliver to the encoder(s)
- and ultimately the connector(s) in the configuration. A framebuffer
- is fundamentally a driver specific memory object, made into an opaque
- handle by the DRM addfb function. Once an fb has been created this
- way it can be passed to the KMS mode setting routines for use in
- a configuration.
+ Clients need to provide a framebuffer object which provides a source
+ of pixels for a CRTC to deliver to the encoder(s) and ultimately the
+ connector(s). A framebuffer is fundamentally a driver specific memory
+ object, made into an opaque handle by the DRM's addfb() function.
+ Once a framebuffer has been created this way, it may be passed to the
+ KMS mode setting routines for use in a completed configuration.
</para>
</sect1>