DocBook/drm: Clean up the paragraph on framebuffer objects
Signed-off-by: Michael Witten <mfwitten@gmail.com>
This commit is contained in:
@@ -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>
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user