Commit 5a462d58 authored by Michael Witten's avatar Michael Witten

DocBook/drm: Clean up the paragraph on framebuffer objects

Signed-off-by: default avatarMichael Witten <mfwitten@gmail.com>
parent 964d32dc
...@@ -795,14 +795,12 @@ void intel_crt_init(struct drm_device *dev) ...@@ -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>
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment