Documentation/fb/uvesafb.rst
Source file repositories/reference/linux-study-clean/Documentation/fb/uvesafb.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/fb/uvesafb.rst- Extension
.rst- Size
- 7409 bytes
- Lines
- 189
- 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
==========================================================
uvesafb - A Generic Driver for VBE2+ compliant video cards
==========================================================
1. Requirements
---------------
uvesafb should work with any video card that has a Video BIOS compliant
with the VBE 2.0 standard.
Unlike other drivers, uvesafb makes use of a userspace helper called
v86d. v86d is used to run the x86 Video BIOS code in a simulated and
controlled environment. This allows uvesafb to function on arches other
than x86. Check the v86d documentation for a list of currently supported
arches.
v86d source code can be downloaded from the following website:
https://github.com/mjanusz/v86d
Please refer to the v86d documentation for detailed configuration and
installation instructions.
Note that the v86d userspace helper has to be available at all times in
order for uvesafb to work properly. If you want to use uvesafb during
early boot, you will have to include v86d into an initramfs image, and
either compile it into the kernel or use it as an initrd.
2. Caveats and limitations
--------------------------
uvesafb is a _generic_ driver which supports a wide variety of video
cards, but which is ultimately limited by the Video BIOS interface.
The most important limitations are:
- Lack of any type of acceleration.
- A strict and limited set of supported video modes. Often the native
or most optimal resolution/refresh rate for your setup will not work
with uvesafb, simply because the Video BIOS doesn't support the
video mode you want to use. This can be especially painful with
widescreen panels, where native video modes don't have the 4:3 aspect
ratio, which is what most BIOS-es are limited to.
- Adjusting the refresh rate is only possible with a VBE 3.0 compliant
Video BIOS. Note that many nVidia Video BIOS-es claim to be VBE 3.0
compliant, while they simply ignore any refresh rate settings.
3. Configuration
----------------
uvesafb can be compiled either as a module, or directly into the kernel.
In both cases it supports the same set of configuration options, which
are either given on the kernel command line or as module parameters, e.g.::
video=uvesafb:1024x768-32,mtrr:3,ywrap (compiled into the kernel)
# modprobe uvesafb mode_option=1024x768-32 mtrr=3 scroll=ywrap (module)
Accepted options:
======= =========================================================
ypan Enable display panning using the VESA protected mode
interface. The visible screen is just a window of the
video memory, console scrolling is done by changing the
start of the window. This option is available on x86
only and is the default option on that architecture.
ywrap Same as ypan, but assumes your gfx board can wrap-around
the video memory (i.e. starts reading from top if it
reaches the end of video memory). Faster than ypan.
Available on x86 only.
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.