Overview

Relevant source files

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

Fastfetch is a cross-platform system information tool written primarily in C that detects and displays hardware, operating system, and software configuration details. It emphasizes performance, modularity, and extensive platform support through a modular architecture with 70+ detection modules and platform-specific implementations.

Supported Platforms: Linux (GNU/Linux, Android), Windows 7+, macOS, FreeBSD, OpenBSD, NetBSD, DragonFly BSD, Haiku, illumos (SunOS), and GNU Hurd.

Key Capabilities: Detection of CPU, GPU, memory, disk, display servers (X11, Wayland, DWM), desktop environments, window managers, package managers (30+ on Linux), terminal emulators, shell versions, and many other system components.

For installation and basic usage, see Installation and Quick Start. For configuration, see Configuration Overview. For the simplified flashfetch variant, see Flashfetch Variant.

System Purpose and Scope

Fastfetch serves as a neofetch-like tool with active maintenance, improved performance, and enhanced accuracy. The tool's execution model follows a three-stage pipeline:

1. Detection Stage: Platform-specific APIs gather system information via functions like ffDetectCPU(), ffDetectGPU(), etc., defined in src/detection/ subdirectories
2. Formatting Stage: Detected data is processed through format strings with placeholder substitution (e.g., {name}, {vendor}, {cores})
3. Output Stage: Results are rendered as formatted text with ANSI colors, JSON output, or dynamic updating display

The architecture achieves cross-platform support through compile-time platform selection in CMake and runtime dispatch to platform-specific implementations. Each detection function has variants like cpu_linux.c, cpu_windows.c, cpu_apple.c, etc.

Sources: README.md1-16 CMakeLists.txt3-8 src/fastfetch.c1-100 src/detection/

Architecture Components

Global Instance Singleton

The entire application state is managed through a single global variable instance of type FFinstance, defined in src/common/impl/init.c and declared in src/fastfetch.h41-46 This singleton serves as the single source of truth for all configuration and runtime state throughout the application.

Component	Type	Declaration	Purpose
config	FFconfig	src/fastfetch.h23-28	User configuration from CLI args and config files
state	FFstate	src/fastfetch.h30-39	Runtime state including platform info and output buffers

Diagram: FFinstance Singleton Structure

Lifecycle Functions:

• ffInitInstance() - Initializes the singleton at program startup, parses command-line arguments
• ffStart() - Performs platform detection, connects to display server, loads logo
• ffFinish() - Prints remaining logo lines, flushes output buffers
• ffDestroyInstance() - Frees all allocated resources before exit

Sources: src/fastfetch.h23-46 src/common/impl/init.c src/options/logo.h src/options/display.h src/options/general.h src/common/FFPlatform.h

Module Registry and Execution

Fastfetch implements 70+ detection modules organized in a two-dimensional array ffModuleInfos declared in src/fastfetch.h47 The array is indexed alphabetically (A-Z) to enable efficient module lookup by name. Each module implements the FFModuleBaseInfo interface defined in src/modules/modules.c:

FFModuleBaseInfo Structure:

• name - Module identifier string (e.g., "CPU", "GPU", "Memory")
• description - Human-readable module description
• printModule - Function pointer to module's print function (e.g., ffPrintCPU)
• parseJsonObject - Function pointer for parsing JSONC configuration
• formatArgs - Array of FFModuleFormatArg defining format placeholders
• initOptions - Initializes module-specific options structure
• destroyOptions - Cleans up module-specific options structure

Diagram: Module Registry Structure and FFModuleBaseInfo Interface

Module Organization:

• Module headers consolidated in src/modules/modules.h1-77
• Module implementations in src/modules/*/ subdirectories (e.g., src/modules/cpu/cpu.c)
• Detection logic in src/detection/*/ subdirectories (e.g., src/detection/cpu/cpu.c)

Sources: src/fastfetch.h47 src/modules/modules.h1-77 src/modules/modules.c src/modules/cpu/cpu.c src/modules/gpu/gpu.c

Execution Pipeline

Application Lifecycle

The fastfetch execution follows a well-defined lifecycle implemented in src/fastfetch.c690-747:

Diagram: Application Lifecycle with Function Call Paths

Key Lifecycle Functions:

Function	File	Responsibility
main()	src/fastfetch.c690-747	Entry point, orchestrates execution
ffInitInstance()	src/common/impl/init.c	Initializes global instance singleton
parseCommand()	src/fastfetch.c590-687	Parses individual CLI arguments
parseJsoncFile()	src/fastfetch.c383-433	Loads and parses JSONC configuration
ffStart()	src/common/impl/init.c	Platform detection, terminal setup
ffLogoPrint()	src/logo/logo.c	Prints logo (ASCII or image)
ffPrintFormat()	src/common/impl/printing.c	Formats module output with placeholders
ffFinish()	src/common/impl/init.c	Cleanup and remaining logo lines
ffDestroyInstance()	src/common/impl/init.c	Frees all allocated memory

Simplified Variant: The flashfetch executable in src/flashfetch.c8-147 demonstrates a hardcoded module sequence mimicking neofetch's default behavior, useful as a reference implementation.

Sources: src/fastfetch.c690-747 src/flashfetch.c8-147 src/common/impl/init.c src/common/impl/printing.c src/logo/logo.c

Platform Abstraction Strategy

Fastfetch achieves cross-platform support through compile-time platform selection in CMake and platform-specific source files:

Platform	CMake Flag	Implementation Files
Linux	LINUX=TRUE	*_linux.c, *_unix.c
Windows	WIN32=TRUE	*_windows.c, *.cpp (for C++ APIs)
macOS	APPLE=TRUE	*_apple.c, *.m (Objective-C)
FreeBSD	FreeBSD=TRUE	*_bsd.c, *_unix.c
Android	ANDROID=TRUE	*_android.c, *_linux.c

The CMake configuration in CMakeLists.txt23-50 detects the target platform and sets appropriate flags. Each module detection function (e.g., ffDetectCPU()) is implemented in platform-specific files that are conditionally compiled:

• Linux: src/detection/cpu/cpu_linux.c
• Windows: src/detection/cpu/cpu_windows.c
• macOS: src/detection/cpu/cpu_apple.c
• BSD: src/detection/cpu/cpu_bsd.c

Sources: CMakeLists.txt23-50 CMakeLists.txt515-847

Configuration System

JSONC Configuration Format

Fastfetch uses JSONC (JSON with Comments) and JSON5 formats parsed by the yyjson library (v0.12.0+). Configuration files are loaded from multiple search paths in order:

1. Absolute path or relative path specified by --config / -c flag
2. Relative path searched in ~/.config/fastfetch/ (or platform-specific config dirs)
3. Preset name searched in data directories + fastfetch/presets/
4. Executable directory + /presets/ (Windows portability)

Configuration Loading: Implemented in optionParseConfigFile() src/fastfetch.c472-569 and parseJsoncFile() src/fastfetch.c383-433

Supported Formats:

Extension	Description	yyjson Flag	Features
.json	Strict JSON	0	Standard JSON only
.jsonc	JSONC	YYJSON_READ_ALLOW_COMMENTS | YYJSON_READ_ALLOW_TRAILING_COMMAS	Comments, trailing commas
.json5	JSON5	YYJSON_READ_JSON5	Unquoted keys, single quotes, multi-line strings

Special Values:

• --config - - Read configuration from stdin
• --config none or --config "" - Disable config file loading

Sources: src/fastfetch.c383-569 src/common/impl/jsonconfig.c CMakeLists.txt277-292

Configuration Schema

The configuration structure is defined by a JSON Schema in doc/json_schema.json and implements a hierarchical options model:

Diagram: Configuration Schema Hierarchy

Parsing Functions:

Section	Parser Function	Implementation File
logo	ffOptionsParseLogoJsonConfig()	src/options/logo.c
display	ffOptionsParseDisplayJsonConfig()	src/options/display.c
general	ffOptionsParseGeneralJsonConfig()	src/options/general.c
modules	ffOptionsParseModulesJsonConfig()	src/common/impl/jsonconfig.c

Module Options: Each module type (CPU, GPU, etc.) defines its own options structure (e.g., FFCPUOptions in src/modules/cpu/option.h) with a corresponding JSON parser (parseJsonObjectCPU()).

Sources: doc/json_schema.json src/options/logo.c src/options/display.c src/options/general.c src/common/impl/jsonconfig.c

Key Features

Multi-Platform Support

Fastfetch supports 11+ operating systems with platform-specific optimizations:

Platform	Detection APIs	Notable Features
Linux	sysfs, /proc, DRM, X11, Wayland	30+ package managers, Vulkan, OpenGL, OpenCL
Windows	WinAPI, WMI, Registry, Performance Counters	DirectX, Windows 7+ compatibility
macOS	IOKit, CoreGraphics, sysctls, Metal	Objective-C APIs, Cocoa framework
FreeBSD	sysctl, kvm, libdrm, libgeom	ZFS support, DRM detection
Android	Android APIs, Linux fallbacks	Termux support, device tree parsing

Platform detection is performed in src/common/impl/FFPlatform.c during initialization, populating the instance.state.platform structure.

Sources: CMakeLists.txt23-50 src/common/impl/FFPlatform.c

Output Formats

Fastfetch supports multiple output modes:

1. Text Output (default): Formatted text with ANSI colors, aligned with logo
2. JSON Output (--json or -j): Machine-readable structured data via yyjson
3. Dynamic Mode (--dynamic-interval): Auto-refreshing display for real-time monitoring

The output system is implemented in src/common/impl/printing.c with functions like ffPrintFormat() and ffPrintFormatString() that support placeholder substitution.

Sources: src/common/impl/printing.c src/fastfetch.c569-587

Logo System

Fastfetch includes 200+ built-in ASCII logos defined in src/logo/ascii/*.txt and supports multiple rendering methods:

Logo Types:

Type	Implementation	Description
builtin	src/logo/builtin.c	200+ OS logos compiled into binary
file	src/logo/logo.c	ASCII text files with color codes ($1-$9)
file-raw	src/logo/logo.c	Raw text files without processing
data	src/logo/logo.c	Logo data passed as string
command	src/logo/logo.c	Execute command and use output
command-raw	src/logo/logo.c	Execute command, display raw output
Image protocols	src/logo/image/	iTerm, Kitty, Sixel via ImageMagick/Chafa

Built-in Logo Structure: Each logo is represented by an FFlogo struct defined in src/logo/builtin.c5-11:

Logo Registry: Built-in logos organized alphabetically in arrays A[], B[], ..., Z[] in src/logo/builtin.c13-30000 with the registry function ffLogoBuiltinGet() performing name-based lookup.

Build-Time Generation: Logos are embedded via CMake script CMakeLists.txt361-369 which reads src/logo/ascii/*.txt files and generates logo_builtin.h with C string literals.

Sources: src/logo/builtin.c5-100 src/logo/logo.c src/logo/image/ CMakeLists.txt361-369

Build System

The CMake build system in CMakeLists.txt1-2600 provides extensive cross-platform configurability:

Diagram: CMake Build System Flow

Key Build Components:

Component	Lines	Description
Platform detection	CMakeLists.txt23-50	Sets LINUX, WIN32, APPLE, etc.
Feature options	CMakeLists.txt70-128	ENABLE_* flags via cmake_dependent_option
Source lists	CMakeLists.txt375-513	Common sources in LIBFASTFETCH_SRC
Platform sources	CMakeLists.txt515-1300	Platform-conditional source files
Data generation	CMakeLists.txt263-370	Python scripts for embedding data
Target definitions	CMakeLists.txt1373-1450	fastfetch and flashfetch executables

Generated Files:

• fastfetch_config.h - Feature flags and build configuration
• fastfetch_datatext.h - Embedded text data (help, structure)
• logo_builtin.h - Embedded ASCII logos as #define macros

Sources: CMakeLists.txt1-2600 CMakeLists.txt23-50 CMakeLists.txt70-128 CMakeLists.txt263-370 CMakeLists.txt375-1300

Utility Libraries

Fastfetch includes custom utility libraries optimized for performance:

Library	Type	Purpose	Key Operations
FFstrbuf	Dynamic string buffer	Efficient string manipulation	Create, append, trim, format
FFlist	Generic dynamic array	Type-safe collections	Add, iterate, destroy
Platform utilities	I/O and process helpers	File reading, process execution	Parse files, spawn processes

The FFstrbuf structure implements a three-state model:

• Empty state: Zero overhead (NULL pointer)
• Static state: Points to string literals (no allocation)
• Dynamic state: Heap-allocated with automatic growth

This design minimizes memory allocations while supporting efficient string operations throughout the codebase.

Sources: src/common/impl/FFstrbuf.c src/common/impl/FFlist.c src/common/FFstrbuf.h src/common/FFlist.h