Documentation/fb/api.rst
Source file repositories/reference/linux-study-clean/Documentation/fb/api.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/fb/api.rst- Extension
.rst- Size
- 12227 bytes
- Lines
- 308
- 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.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
struct fb_fix_screeninfostruct fb_fix_screeninfostruct fb_var_screeninfostruct fb_bitfield
Annotated Snippet
struct fb_fix_screeninfo {
...
__u16 capabilities; /* see FB_CAP_* */
...
};
Application should use those capabilities to find out what features they can
expect from the device and driver.
- FB_CAP_FOURCC
The driver supports the four character code (FOURCC) based format setting API.
When supported, formats are configured using a FOURCC instead of manually
specifying color components layout.
2. Types and visuals
--------------------
Pixels are stored in memory in hardware-dependent formats. Applications need
to be aware of the pixel storage format in order to write image data to the
frame buffer memory in the format expected by the hardware.
Formats are described by frame buffer types and visuals. Some visuals require
additional information, which are stored in the variable screen information
bits_per_pixel, grayscale, red, green, blue and transp fields.
Visuals describe how color information is encoded and assembled to create
macropixels. Types describe how macropixels are stored in memory. The following
types and visuals are supported.
- FB_TYPE_PACKED_PIXELS
Macropixels are stored contiguously in a single plane. If the number of bits
per macropixel is not a multiple of 8, whether macropixels are padded to the
next multiple of 8 bits or packed together into bytes depends on the visual.
Padding at end of lines may be present and is then reported through the fixed
screen information line_length field.
- FB_TYPE_PLANES
Macropixels are split across multiple planes. The number of planes is equal to
the number of bits per macropixel, with plane i'th storing i'th bit from all
macropixels.
Planes are located contiguously in memory.
- FB_TYPE_INTERLEAVED_PLANES
Macropixels are split across multiple planes. The number of planes is equal to
the number of bits per macropixel, with plane i'th storing i'th bit from all
macropixels.
Planes are interleaved in memory. The interleave factor, defined as the
distance in bytes between the beginning of two consecutive interleaved blocks
belonging to different planes, is stored in the fixed screen information
type_aux field.
- FB_TYPE_FOURCC
Macropixels are stored in memory as described by the format FOURCC identifier
stored in the variable screen information grayscale field.
- FB_VISUAL_MONO01
Pixels are black or white and stored on a number of bits (typically one)
specified by the variable screen information bpp field.
Black pixels are represented by all bits set to 1 and white pixels by all bits
Annotation
- Detected declarations: `struct fb_fix_screeninfo`, `struct fb_fix_screeninfo`, `struct fb_var_screeninfo`, `struct fb_bitfield`.
- 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.