Documentation/fb/framebuffer.rst
Source file repositories/reference/linux-study-clean/Documentation/fb/framebuffer.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/fb/framebuffer.rst- Extension
.rst- Size
- 14250 bytes
- Lines
- 354
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
=======================
The Frame Buffer Device
=======================
Last revised: May 10, 2001
0. Introduction
---------------
The frame buffer device provides an abstraction for the graphics hardware. It
represents the frame buffer of some video hardware and allows application
software to access the graphics hardware through a well-defined interface, so
the software doesn't need to know anything about the low-level (hardware
register) stuff.
The device is accessed through special device nodes, usually located in the
/dev directory, i.e. /dev/fb*.
1. User's View of /dev/fb*
--------------------------
From the user's point of view, the frame buffer device looks just like any
other device in /dev. It's a character device using major 29; the minor
specifies the frame buffer number.
By convention, the following device nodes are used (numbers indicate the device
minor numbers)::
0 = /dev/fb0 First frame buffer
1 = /dev/fb1 Second frame buffer
...
31 = /dev/fb31 32nd frame buffer
For backwards compatibility, you may want to create the following symbolic
links::
/dev/fb0current -> fb0
/dev/fb1current -> fb1
and so on...
The frame buffer devices are also `normal` memory devices, this means, you can
read and write their contents. You can, for example, make a screen snapshot by::
cp /dev/fb0 myfile
There also can be more than one frame buffer at a time, e.g. if you have a
graphics card in addition to the built-in hardware. The corresponding frame
buffer devices (/dev/fb0 and /dev/fb1 etc.) work independently.
Application software that uses the frame buffer device (e.g. the X server) will
use /dev/fb0 by default (older software uses /dev/fb0current). You can specify
an alternative frame buffer device by setting the environment variable
$FRAMEBUFFER to the path name of a frame buffer device, e.g. (for sh/bash
users)::
export FRAMEBUFFER=/dev/fb1
or (for csh users)::
setenv FRAMEBUFFER /dev/fb1
After this the X server will use the second frame buffer.
2. Programmer's View of /dev/fb*
--------------------------------
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.