DocBook/drm: Clean up the paragraph on framebuffer objects

Signed-off-by: Michael Witten <mfwitten@gmail.com>
This commit is contained in:
Michael Witten
2011-08-29 17:58:46 +00:00
parent 964d32dcbe
commit 5a462d58c8

View File

@@ -795,14 +795,12 @@ void intel_crt_init(struct drm_device *dev)
<sect1> <sect1>
<title>Framebuffer management</title> <title>Framebuffer management</title>
<para> <para>
In order to set a mode on a given CRTC, encoder and connector Clients need to provide a framebuffer object which provides a source
configuration, clients need to provide a framebuffer object which of pixels for a CRTC to deliver to the encoder(s) and ultimately the
provides a source of pixels for the CRTC to deliver to the encoder(s) connector(s). A framebuffer is fundamentally a driver specific memory
and ultimately the connector(s) in the configuration. A framebuffer object, made into an opaque handle by the DRM's addfb() function.
is fundamentally a driver specific memory object, made into an opaque Once a framebuffer has been created this way, it may be passed to the
handle by the DRM addfb function. Once an fb has been created this KMS mode setting routines for use in a completed configuration.
way it can be passed to the KMS mode setting routines for use in
a configuration.
</para> </para>
</sect1> </sect1>