Documentation/fb/sisfb.rst
Source file repositories/reference/linux-study-clean/Documentation/fb/sisfb.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/fb/sisfb.rst- Extension
.rst- Size
- 6694 bytes
- Lines
- 161
- 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
=====================================
sisfb - SiS framebuffer device driver
=====================================
sisfb is a framebuffer device driver for SiS (Silicon Integrated Systems)
graphics chips. Supported are:
- SiS 300 series: SiS 300/305, 540, 630(S), 730(S)
- SiS 315 series: SiS 315/H/PRO, 55x, (M)65x, 740, (M)661(F/M)X, (M)741(GX)
- SiS 330 series: SiS 330 ("Xabre"), (M)760
Why do I need a framebuffer driver?
===================================
sisfb is eg. useful if you want a high-resolution text console. Besides that,
sisfb is required to run DirectFB (which comes with an additional, dedicated
driver for the 315 series).
On the 300 series, sisfb on kernels older than 2.6.3 furthermore plays an
important role in connection with DRM/DRI: Sisfb manages the memory heap
used by DRM/DRI for 3D texture and other data. This memory management is
required for using DRI/DRM.
Kernels >= around 2.6.3 do not need sisfb any longer for DRI/DRM memory
management. The SiS DRM driver has been updated and features a memory manager
of its own (which will be used if sisfb is not compiled). So unless you want
a graphical console, you don't need sisfb on kernels >=2.6.3.
Sidenote: Since this seems to be a commonly made mistake: sisfb and vesafb
cannot be active at the same time! Do only select one of them in your kernel
configuration.
How are parameters passed to sisfb?
===================================
Well, it depends: If compiled statically into the kernel, use lilo's append
statement to add the parameters to the kernel command line. Please see lilo's
(or GRUB's) documentation for more information. If sisfb is a kernel module,
parameters are given with the modprobe (or insmod) command.
Example for sisfb as part of the static kernel: Add the following line to your
lilo.conf::
append="video=sisfb:mode:1024x768x16,mem:12288,rate:75"
Example for sisfb as a module: Start sisfb by typing::
modprobe sisfb mode=1024x768x16 rate=75 mem=12288
A common mistake is that folks use a wrong parameter format when using the
driver compiled into the kernel. Please note: If compiled into the kernel,
the parameter format is video=sisfb:mode:none or video=sisfb:mode:1024x768x16
(or whatever mode you want to use, alternatively using any other format
described above or the vesa keyword instead of mode). If compiled as a module,
the parameter format reads mode=none or mode=1024x768x16 (or whatever mode you
want to use). Using a "=" for a ":" (and vice versa) is a huge difference!
Additionally: If you give more than one argument to the in-kernel sisfb, the
arguments are separated with ",". For example::
video=sisfb:mode:1024x768x16,rate:75,mem:12288
How do I use it?
================
Preface statement: This file only covers very little of the driver's
capabilities and features. Please refer to the author's and maintainer's
website at http://www.winischhofer.net/linuxsisvga.shtml for more
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.