Overview

Relevant source files

• CHANGELOG.md
• CMakeLists.txt
• README.md
• src/common/init.c
• src/fastfetch.c
• src/fastfetch.h
• src/flashfetch.c
• src/logo/ascii/obsidianos.txt
• src/logo/builtin.c
• src/modules/modules.h
• src/modules/options.h

Fastfetch is a cross-platform system information tool written in C that detects and displays hardware and software information in a customizable format. This page provides a high-level introduction to fastfetch's architecture, core components, and design principles.

For installation and basic usage instructions, see Installation and Basic Usage. For configuration details, see Configuration Guide. For information about specific subsystems, see the corresponding sections in this wiki.

System Purpose

Fastfetch serves as a fast, actively maintained alternative to neofetch, designed to:

• Detect system information across 70+ modules covering hardware (CPU, GPU, memory, disk), software (OS, packages, shell), and visual elements (WM, DE, themes)
• Display information efficiently using ASCII logos, image protocols, or custom formats
• Support multiple platforms including Linux, macOS, Windows 7+, FreeBSD, OpenBSD, NetBSD, DragonFly BSD, Android, Haiku, and SunOS
• Enable extensive customization through JSONC configuration files with JSON schema validation

The codebase emphasizes performance (written in C), modularity (70+ independent detection modules), and maintainability (platform-specific abstraction).

Sources: README.md1-331 CMakeLists.txt1-8

High-Level Architecture

Architecture Diagram: Core System Components

Fastfetch follows a layered architecture where:

1. Entry points (src/fastfetch.c800 src/flashfetch.c7) initialize the global instance singleton defined in src/common/init.c20
2. Configuration flows from JSONC files via parseJsoncFile() src/fastfetch.c381 using the yyjson library into instance.config
3. Module registry ffModuleInfos[26] provides O(26) lookup of 70+ modules indexed by first letter (A-Z)
4. Detection layer uses FFPlatform abstractions to call platform-specific implementations (*_linux.c, *_windows.c, *_apple.m)
5. Output system processes format strings via ffParseFormatString() and prints through ffPrintModuleInfo()

Sources: src/fastfetch.c1-800 src/flashfetch.c7-142 src/fastfetch.h29-58 src/common/init.c20-61 src/common/modules.c CMakeLists.txt366-501

Core Data Structures

The Global Instance

Class Diagram: Global Instance Structure

The entire application state is managed through a single global instance variable of type FFinstance, defined in src/common/init.c20 This singleton contains:

• FFconfig: All user-configurable options (logo settings, display formatting, general behavior)
• FFstate: Runtime state including platform information, parsed JSON documents, and output dimensions

This design enables any module to access configuration and platform details without passing parameters through deep call chains.

Sources: src/fastfetch.h29-58 src/common/init.c20-61

Module System Architecture

Module Registry and Lifecycle

Fastfetch organizes its 70+ modules through ffModuleInfos[26] (src/common/modules.c), an array where index i corresponds to letter 'A'+i. Each entry points to a NULL-terminated array of FFModuleBaseInfo* structures. For example, ffModuleInfos[2] contains CPU, Colors, Command, Custom, etc.

Each module's FFModuleBaseInfo structure (src/common/modules.h) contains:

• name and description strings for help text
• printModule function pointer to the module's print function
• formatArgs array defining custom format placeholders

Module Lifecycle Functions:

Function Pattern	Example	Purpose
ffInit*Options()	ffInitCPUOptions()	Initialize module-specific options with defaults
ffParse*JsonObject()	ffParseCPUJsonObject()	Parse JSON configuration into options structure
ffPrint*()	ffPrintCPU()	Execute detection and print results
ffGenerate*JsonConfig()	ffGenerateCPUJsonConfig()	Generate JSON output for config generation
ffDestroy*Options()	ffDestroyCPUOptions()	Clean up allocated memory

The CPU module example shows the complete flow: ffModuleInfoCPU → ffPrintCPU() → ffDetectCPU() → ffDetectCPUImpl() in src/detection/cpu/cpu_linux.c518

Sources: src/common/modules.c src/common/modules.h src/modules/cpu/cpu.c src/modules/cpu/option.h src/detection/cpu/cpu.c src/detection/cpu/cpu_linux.c518 src/modules/modules.h1-76

Application Lifecycle

Platform Abstraction Pattern

Fastfetch achieves cross-platform support through compile-time file selection:

1. Unified API: Each detection function (e.g., ffDetectCPU()) is declared in src/detection/cpu/cpu.c with a common signature returning standardized result structures

2. CMake-based Selection: CMakeLists.txt503-836 conditionally includes platform-specific source files:

3. Platform-Specific Implementations:

   • Linux: Uses /proc/cpuinfo, sysfs, DRM, Wayland/XCB protocols
   • Windows: Uses Registry, WMI, DXGI, vendor-specific APIs (NVAPI, ADL)
   • macOS: Uses sysctl, IOKit, Metal, CoreGraphics

4. Common Result Structures: All implementations populate the same FFCPUResult, FFGPUResult, FFOSResult structures defined in src/detection/*/\\*.h

Example: CPU Detection Flow

ffPrintCPU() [modules/cpu/cpu.c] → ffDetectCPU() [detection/cpu/cpu.c] → ffDetectCPUImpl() [detection/cpu/cpu_linux.c:518] → Parse /proc/cpuinfo → Query sysfs for frequency → Populate FFCPUResult 

For detailed platform-specific implementation strategies, see Cross-Platform Abstraction Patterns.

Sources: CMakeLists.txt503-836 src/detection/cpu/cpu.c src/detection/cpu/cpu_linux.c518 src/detection/gpu/gpu_linux.c src/detection/os/os_linux.c src/detection/cpu/cpu_windows.c src/detection/gpu/gpu_windows.c

Build System Overview

Component	Implementation	Purpose
Build Tool	CMake 3.12+	Cross-platform build configuration
Platform Detection	CMakeLists.txt26-50	Detect Linux, FreeBSD, macOS, Windows, etc.
Dependency Management	pkg-config, find_package	Optional library detection (Vulkan, Wayland, ImageMagick, etc.)
Data Embedding	Python scripts	Generate C include files for PCI IDs, logos, help text
Binary Outputs	fastfetch, flashfetch	Flexible and hardcoded variants
Testing	CTest	Unit test execution

Fastfetch uses CMake to orchestrate compilation across 10+ platforms. Python scripts preprocess data files (PCI IDs, AMD GPU IDs, ASCII logos) into C header files for embedding. The build produces two binaries:

• fastfetch: Fully configurable, supports all options
• flashfetch: Hardcoded module list, demonstrates neofetch-compatible output

For complete build system documentation, see Cross-Platform Build Configuration.

Sources: CMakeLists.txt1-500

Configuration System Overview

Fastfetch uses JSONC (JSON with comments) for configuration, validated against a JSON schema:

Configuration Flow

The configuration system supports:

• Multiple input sources: CLI flags, JSONC files, environment variables, compiled defaults (in priority order)
• JSON5 syntax: Since yyjson 0.12, supports unquoted keys, trailing commas, comments
• Schema validation: doc/json_schema.json defines all valid options
• Per-module configuration: Each module has its own FF*Options structure

For detailed configuration documentation, see Configuration and Schema System and Configuration Guide.

Sources: src/fastfetch.c381-544 src/common/jsonconfig.c1-200

Output and Formatting

Fastfetch provides two primary output modes:

Mode	Implementation	Use Case
Terminal Output	ANSI escape sequences	Human-readable display with colors, logos
JSON Output	--format json flag	Machine-readable, for scripts and tools

The formatting system uses a template engine (ffParseFormatString()) that supports:

• Placeholders: {name}, {value}, {1}, {2}
• Conditionals: {?temp}...{?} (show if temp exists)
• Modifiers: {:width}, {>pad}, {~substr}
• Colors: {#FF0000}, {#color-name}

Each module defines format arguments in its FFModuleBaseInfo::formatArgs array, accessible via fastfetch -h <module>-format.

For complete formatting documentation, see Format String System.

Sources: src/common/format.c1-500 src/common/printing.c1-300

Logo System

Logo Type Implementations

Type	Source	Implementation	Code Reference
Built-in ASCII	src/logo/ascii/*.txt	Embedded at build time in logo_builtin.h	src/logo/builtin.c13-732
Custom ASCII	User files (e.g., ~/.config/fastfetch/logos/)	Loaded from disk at runtime	src/logo/logo.c
Image (Kitty)	PNG/JPG via --logo <path>	Kitty graphics protocol	src/logo/image/image.c
Image (iTerm2)	PNG/JPG via ImageMagick	iTerm2 inline images	src/logo/image/im6.c src/logo/image/im7.c
Image (Sixel)	PNG/JPG via ImageMagick/Chafa	Sixel graphics protocol	src/logo/image/image.c
Raw	Pre-rendered ANSI files	Direct terminal output	src/logo/logo.c

Built-in Logo Organization:

Built-in logos are defined in src/logo/builtin.c13-732 as static arrays A[], B[], C[], etc., containing FFlogo structures:

The build system (CMakeLists.txt352-360) generates logo_builtin.h from ASCII text files, embedding them as C string literals with color codes ($1, $2, etc.).

Logo Selection and Printing:

1. ffLogoBuiltinSelect() searches arrays alphabetically for matching distro name
2. ffLogoPrint() src/logo/logo.c133 replaces color placeholders and outputs to terminal
3. Logo width stored in instance.state.logoWidth for text alignment

For logo configuration details, see Logo Rendering System.

Sources: src/logo/builtin.c5-732 src/logo/logo.c133 src/logo/image/image.c CMakeLists.txt352-360 src/logo/ascii/obsidianos.txt1-17

Utility Libraries

Fastfetch implements custom data structures for memory safety and performance:

Library	Type	Purpose
FFstrbuf	Dynamic string	Growable string buffer with boundary checking
FFlist	Dynamic array	Generic type-safe list with automatic resizing
FFPlatform	Struct	Cross-platform path and environment abstractions

These utilities avoid C string vulnerabilities and provide consistent memory management across the codebase. Integration with external libraries (yyjson, etc.) uses wrapper functions to maintain safety guarantees.

For complete utility documentation, see Core Data Structures.

Sources: src/util/FFstrbuf.c1-500 src/util/FFlist.c1-300 src/util/platform/FFPlatform.c1-400

Key Design Principles

1. Performance:

   • Written in C with minimal allocations
   • Caching for expensive operations (CPU frequency, package counts)
   • Platform-specific optimizations (e.g., posix_spawn vs fork)
   • CMakeLists.txt180-187 enables LTO for release builds

2. Modularity:

   • 70+ independent modules in src/modules/
   • Standard lifecycle: ffInit*Options() → ffPrint*() → ffDestroy*Options()
   • Each module isolated with its own option structure

3. Portability:

   • Single codebase supports 10+ OSes
   • Platform detection in CMakeLists.txt26-50
   • Platform-specific files selected at compile time: *_linux.c, *_windows.c, *_apple.m, *_bsd.c

4. Safety:

   • FFstrbuf src/util/FFstrbuf.c prevents buffer overflows
   • FFlist src/util/FFlist.c provides type-safe dynamic arrays
   • Memory cleanup via __attribute__((cleanup)) in flashfetch

5. Extensibility:

   • Format string engine src/common/format.c supports placeholders and conditionals
   • JSON schema doc/json_schema.json defines extensible configuration
   • Module-specific format args in FFModuleBaseInfo::formatArgs

6. Maintainability:

   • Consistent naming: ffDetect*(), ffPrint*(), ff*Options
   • Generated help text from src/data/help.json
   • CI/CD builds for 20+ platform/architecture combinations

Related Documentation

For detailed information about specific subsystems:

• Application structure and initialization: Application Lifecycle and Entry Points
• Module implementation details: Module System Architecture
• Configuration file format: Configuration and Schema System
• Hardware detection methods: Detection Subsystems
• Output customization: Presentation and Output Systems
• Development and building: Build System and Development

Sources: README.md1-331 CMakeLists.txt1-8 src/fastfetch.c1-800 src/flashfetch.c1-143