Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to DirectFB.
Nothing was collected or created yet.
DirectFB
View on Wikipediafrom Wikipedia
| DirectFB | |
|---|---|
| Original author | Denis Oliver Kropp |
| Stable release | 1.7.7
/ February 1, 2015 |
| Repository | github |
| Written in | C[1] |
| Operating system | Linux, macOS |
| Type | Library |
| License | LGPL |
| Website | DirectFB web (archive.org) |
| DirectFB2 | |
|---|---|
| Developer | Nicolas Caramelli |
| Repository | github |
| Website | directfb2 |
DirectFB (Direct Frame Buffer), now continued as DirectFB2, is a software library with a small memory footprint that provides graphics acceleration, input device handling and abstraction layer, and integrated windowing system with support for translucent windows and multiple display layers on top of the Linux framebuffer without requiring any kernel modifications.[2][3] DirectFB is free and open-source software subject to the terms of the GNU Lesser General Public License (LGPL).
The library allows developers an alternative to a full X Window System (X11) server used in Unix-like operating systems. DirectFB allows applications to talk directly to video hardware through a direct API, speeding up and simplifying graphic operations.
It is often used by games and embedded systems developers to circumvent the overhead of a full X Window System server implementation.[citation needed] In 2006, a version of DirectFB was included in the software stack for the CE Linux Forum's Audio/Video Graphics Specification V2.[4]
DirectFB can host XDirectFB, a rootless X server implementation that uses DirectFB windows for X11 top-level windows. XDirectFB is an interface that mimics the X11 interface through the DirectFB API to simplify running applications written for X11 on DirectFB.[5]
DirectFBGL is an OpenGL extension for DirectFB/XDirectFB that uses Direct Rendering Infrastructure (DRI) in the Mesa 3D library to support OpenGL hardware acceleration.
Among the products that use DirectFB are LinuxTV, Ben Nanonote, the unreleased Palm Foleo mobile companion, the webOS operating system, Panasonic Viera Connect TVs and the Philips TVs based on jointSPACE.[6]
See also
[edit]
- Direct Rendering Manager
- KMS driver
- General Graphics Interface
- Linux framebuffer
- SVGAlib, a low-level graphics library which runs on Linux and FreeBSD
References
[edit]- ^ "Ohloh Analysis Summary - DirectFB". Archived from the original on 2012-10-10. Retrieved 2009-09-02.
- ^ "directfb.net". Archived from the original on 2016-11-04.
- ^ "DirectFB". elinux.org. Archived from the original on 2023-03-20.
- ^ "AudioVideoGraphicsSpec_V2 - CE Linux Public". Archived from the original on 2008-07-04. Retrieved 2008-06-06.
- ^ Configuring DirectFB Archived 2014-10-18 at the Wayback Machine
- ^ jointSPACE web site
External links
[edit]DirectFB
View on Grokipediafrom Grokipedia
DirectFB is a thin graphics library designed for embedded systems, providing hardware-accelerated access to the Linux framebuffer device (/dev/fb) without requiring kernel modifications or dependencies beyond the standard C library.[1] It facilitates direct rendering of graphics, input device handling (such as keyboards, mice, and joysticks), and an integrated windowing system, enabling efficient multimedia applications on resource-constrained hardware like set-top boxes and portable devices.[2] Initially developed to support advanced graphics operations including blitting, blending, and color keying, DirectFB emphasizes minimal memory footprint and maximal performance through hardware-specific drivers for chipsets like Matrox G200/G400/G450 and ATI Rage 128.[1]
The project originated in 2000 under Convergence GmbH, a German company focused on digital television software, with early contributions from developers including Andreas Hundt and Denis Oliver Kropp.[3] The first release, version 0.9.0, arrived in 2001, followed by stable versions such as 1.0 in 2007, 1.2 in 2008, 1.4 in 2009, and 1.6 in 2012, with the last official release (1.7.7) in 2015.[4] As an open-source initiative under the GNU Lesser General Public License, it garnered contributions from a global community and integrated support for media formats like JPEG, PNG, MPEG video, and TrueType fonts via libraries such as FreeType and FFmpeg.[2] Development slowed after 2016, coinciding with the disappearance of its official website and leading to its removal from distributions like Debian in January 2025, amid the rise of alternatives like X11 and Wayland.[4][5]
Key features include a modular architecture with core APIs for surfaces (pixel data areas), layers (display regions), and windows supporting translucency via ARGB blending, alongside resource management for exclusive fullscreen access.[1] It supports multi-application cores through the Linux Fusion kernel module, enabling shared graphics contexts, and extends to input abstraction for devices like infrared remotes.[2] Compatibility spans GNU/Linux, with historical ports to FreeBSD, NetBSD, OpenBSD (tested on early 2000s versions), and experimentally to Mac OS X, alongside integrations for OpenGL (via DirectFBGL and EGL) and Vulkan extensions (via VK_EXT_directfb_surface).[2] These capabilities made DirectFB suitable for digital TV, automotive displays, and other embedded scenarios requiring low-latency rendering without a full desktop environment.[6]
DirectFB has seen revival efforts through DirectFB2, a 2021 fork hosted on GitHub, which as of 2025 remains under development with a Meson build system, pure C implementation, and enhanced modularity while retaining focus on small-footprint embedded targets, though it is not yet stable.[4][7] This iteration includes providers for fonts (DGIFF), images (DFIFF), and videos (DFVFF), alongside examples like video playback tools and ongoing plans for broader OS support beyond Linux, toolkits such as GTK+ and Qt, and applications including terminals and web browsers.[4] Though not positioned as a competitor to modern compositors, DirectFB (original and DirectFB2) remains relevant for legacy and specialized embedded graphics needs.[4]
History
Origins
DirectFB was founded in the early 2000s by Denis Oliver Kropp, along with Andreas Hundt, at Convergence GmbH in Germany. Development commenced in May 2000, with the project officially starting in July of that year, driven by the need for an efficient graphics solution on Linux systems. The library was released as open-source software under the GNU Lesser General Public License (LGPL) version 2 or later, enabling broad adoption and contributions from the community.[8][9] The primary goal of DirectFB was to offer direct access to framebuffer devices, facilitating hardware-accelerated graphics rendering without the overhead of the X Window System. This approach targeted resource-constrained environments, particularly embedded Linux systems, where traditional windowing systems proved too demanding. The initial public versions, emerging around 2000–2001, emphasized a minimal memory footprint and high performance to support multimedia applications effectively.[8][9] Early development addressed key limitations of the Linux framebuffer console, such as the absence of built-in hardware acceleration and inadequate support for input devices. By building upon the framebuffer interface and integrating drivers for graphics hardware like Matrox cards, DirectFB enabled accelerated operations—including alpha blending and offscreen rendering—initially demonstrated in applications like the game ClanBomber, achieving up to 700 frames per second. These enhancements filled critical gaps for developers seeking lightweight, performant graphics in non-desktop scenarios.[8]Evolution and Fork
DirectFB's development progressed through several stable release series, beginning with the first public release, version 0.9.0, in 2001. Subsequent milestones included stable versions 1.0 in 2007, 1.2 in 2008, 1.4 in 2009, and 1.6 in 2012, each introducing enhancements in stability, hardware support, and features like improved rendering APIs. The project culminated in the 1.7 series, beginning with version 1.7.0 on July 11, 2013, which introduced major bug fixes, new APIs, and improved performance, including a task manager and support for additional image formats like WebP and TIFF. Subsequent minor updates, such as 1.7.1 in October 2013 and 1.7.5 in July 2014, focused on further refinements and stability improvements, with the final 1.7.7 release on February 1, 2015, addressing lingering issues in graphics acceleration and input handling.[10][4] Following the 1.7.7 release, the project entered a period of stagnation, with no official updates after 2015 and the last commit occurring in 2016 on an unpublished 1.8 branch. This inactivity stemmed from shifting maintainer priorities, including the original developer's focus on other endeavors, compounded by the growing adoption of modern display servers like Wayland, which reduced the demand for framebuffer-based solutions in embedded Linux environments. The official DirectFB website went offline around August 2015, further signaling the project's dormancy, though mirrors like GitHub preserved the codebase.[4][11] In late 2021, Nicolas Caramelli initiated the DirectFB2 fork to revive and modernize the library specifically for resource-constrained embedded systems, with the first commits on December 6, 2021, targeting the restoration of the core library's functionality. This effort aimed to address the deprecation of traditional Linux framebuffer (fbdev) drivers in newer kernels, which threatened compatibility for legacy embedded applications reliant on DirectFB's lightweight graphics acceleration. By modularizing the codebase, adopting the Meson build system, and eliminating external dependencies beyond libc, DirectFB2 seeks to sustain the project's utility without positioning it as a competitor to Wayland or X11. Development has continued, with additions such as NuttX support (June 2023), OpenGL ES via SwiftShader (October 2023), and media providers for fonts, images, music, and video (April 2024), remaining active as of 2025.[12][13][4]Technical Overview
Core Design Principles
DirectFB adopts a framebuffer-centric model, leveraging direct access to the Linux framebuffer device (/dev/fb) to enable hardware graphics acceleration without requiring kernel modifications, thereby enhancing portability across various embedded systems. This approach allows applications to interact with graphics hardware in user space through memory-mapped interfaces, handling video mode setup, viewport adjustments, and software fallbacks for unsupported operations. By building atop the standard Linux framebuffer abstraction layer, DirectFB avoids the overhead associated with full graphical servers like X11, making it suitable for resource-constrained environments.[14][10][13] The library's modularity is achieved through a layered architecture that provides well-defined interfaces for key components, including surfaces (via IDirectFBSurface for rendering operations), contexts for managing display layers, and events for input handling. This design supports multiple display layers—common in hardware like TV set-top boxes—and enables compositing via an integrated, lightweight windowing system without necessitating a complete desktop environment. Loadable modules further promote extensibility, covering image providers, video decoders, fonts, input devices, and graphics drivers, allowing developers to customize functionality as needed.[14][15][10] Performance optimizations in DirectFB prioritize minimal overhead for real-time applications, support efficient hardware overlays for alpha blending and acceleration. A task manager facilitates multi-core rendering, while the overall thin library footprint—dependent only on libc—ensures low resource usage, with examples demonstrating 2D rendering at 60 frames per second on specific hardware like the Broadcom 97425. These elements collectively enable high-throughput graphics in embedded scenarios.[10][14] DirectFB is distributed under the GNU Lesser General Public License (LGPL), which permits its integration into proprietary embedded software while requiring source code availability for the library itself, fostering widespread adoption in commercial applications.[2]System Integration
DirectFB integrates closely with the Linux kernel, primarily relying on the framebuffer device (fbdev) subsystem for direct access to graphics hardware. This dependency allows DirectFB to leverage kernel-provided framebuffer drivers for initializing and managing display devices without requiring a full graphical stack like X11. For instance, configurations often utilize kernel modules such as vesafb for VESA BIOS-based framebuffers on x86 systems or intelfb for Intel graphics hardware, enabling accelerated access to video memory during boot and runtime.[16][17][18] The build and installation process for DirectFB involves compilation against the GNU C Library (glibc), ensuring compatibility with standard Linux user-space environments. Developers typically run./configure with options like --enable-multi for multi-application support (which requires the linux-fusion kernel module), followed by make and make install, which installs libraries and headers to a specified prefix. For embedded deployments, cross-compilation is facilitated by toolchains such as those generated by Buildroot, where DirectFB is included as a configurable package that automates the integration of dependencies like libpthread and optional libraries (e.g., libfreetype for font rendering). This approach supports targeting resource-constrained devices by minimizing footprint while maintaining hardware acceleration.[2][19][20]
DirectFB provides compatibility layers for multiple processor architectures, including ARM and x86, allowing seamless adaptation across diverse hardware platforms. On ARM-based systems, integration with bootloaders like U-Boot ensures proper device initialization prior to kernel handover, where U-Boot configures peripherals and memory mappings that the subsequent Linux kernel exposes via fbdev for DirectFB consumption. This layered approach enables DirectFB to initialize graphics without custom drivers in many cases, relying on the bootloader and kernel for low-level setup.[2][21][22]
At runtime, DirectFB employs configuration files and environment variables for fine-tuning system behavior, such as layer stacking and input device mapping. The primary configuration file, directfbrc, located at /etc/directfbrc for system-wide settings or ~/.directfbrc for user-specific overrides, defines options like primary-layer=<id> to specify the default display layer or linux-input-devices to map input sources (e.g., touchscreens or keyboards). Environment variables like DFBARGS allow overriding these settings from the command line, while DIRECTFB_SESSION enables joining multi-application sessions by specifying a shared memory identifier. These mechanisms support dynamic adjustments for layer composition in composited environments and input routing without recompilation.[18][2]
Architecture
Graphics Subsystem
The graphics subsystem of DirectFB forms the core of its rendering pipeline, providing direct access to hardware for efficient 2D graphics operations on top of the Linux framebuffer device. It abstracts low-level framebuffer interactions through a unified API, enabling applications to perform rendering tasks with minimal overhead, particularly in resource-constrained embedded environments. This subsystem prioritizes hardware acceleration where available, falling back to software emulation to ensure portability across diverse graphics hardware. The graphics subsystem integrates with the optional Linux Fusion kernel module to enable multi-application cores with shared graphics contexts.[14][23] Central to the graphics subsystem is the surface model, implemented via theIDirectFBSurface interface, which represents rectangular regions of pixel data that can reside in either video memory or system RAM. Surfaces are created using IDirectFB::CreateSurface() with a DFBSurfaceDescription structure specifying attributes like size, pixel format (e.g., ARGB, RGB16), and capabilities such as double buffering for smooth updates. Manipulation occurs through methods like Blit() for copying rectangular regions from one surface to another (supporting source/destination clipping and color keying), FillRectangle() for solid-color fills, and SetAlpha() combined with blending flags for alpha blending operations that enable semi-transparent overlays. These operations allow developers to build complex visuals, such as textured sprites or layered UI elements, by chaining blits with blending modes like DSBLIT_BLEND_ALPHACHANNEL for per-pixel alpha or DSBLIT_BLEND_COLORALPHA for uniform transparency. Double buffering is toggled via SetConfiguration() and synchronized with Flip(), ensuring flicker-free rendering by swapping front and back buffers.[14][23][24]
Acceleration support in the graphics subsystem is achieved through modular backends, or graphics drivers, that interface directly with GPU hardware via memory-mapped I/O ports, bypassing kernel mediation for user-space execution of 2D operations. These drivers enable hardware-accelerated blitting, filling, line drawing, and advanced transformations such as scaling (via StretchBlit()) and rotation (supported on compatible hardware through matrix-based SetMatrix() calls on surfaces). For example, drivers for Matrox G200/G400 series GPUs accelerate full 2D pipelines including alpha blending and color space conversion, while embedded SoC drivers like those for NXP i.MX53 provide acceleration for scaling and rotation in video-heavy applications. Primary support targets embedded and legacy discrete GPUs like ATI Rage 128 and 3dfx Voodoo series, with software rendering fallback for unsupported hardware including modern Intel and NVIDIA GPUs. Software fallbacks, optimized with MMX on x86, ensure functionality on unaccelerated hardware.[14][23][25]
The layer system facilitates multi-layer compositing by managing independent display layers in video RAM, each configurable as primary (full-screen output) or secondary (overlays). Layers are enumerated and configured via IDirectFBDisplayLayer, supporting z-ordering through priority settings and translucency via alpha blending between layers (e.g., using DSBLIT_BLEND_ALPHACHANNEL for hardware-mixed overlays). Primary surfaces map to the main layer for root rendering, while secondary surfaces enable efficient compositing of video streams or UI elements without full-screen redraws, ideal for embedded multimedia where hardware layers handle chroma-keyed video under graphics. This setup allows multiple layers on supported hardware, with the number depending on the graphics device, region-specific clipping and source rectangle blitting to optimize composition.[14][26][23]
Output handling integrates with video encoders and display hardware for embedded contexts, supporting TV-out via drivers like Matrox's for NTSC/PAL encoding and multi-monitor setups through layered outputs or cloned framebuffers. In embedded systems, the subsystem routes rendered surfaces to encoders (e.g., via V4L2 integration for /dev/video devices), enabling synchronized HDMI/SDI output with format conversion and deinterlacing, as seen in i.MX platforms where primary layers feed hardware video pipelines for low-latency TV display. Input events can briefly trigger surface updates in this pipeline, such as redrawing overlays on touch input.[14][23][25]
Input and Event Handling
DirectFB manages input and event handling through a unified interface that allows applications to capture and process events from various devices without direct kernel interaction. The core mechanism revolves around the IDirectFBEventBuffer interface, which enables applications to create dedicated event buffers for polling or waiting on incoming inputs. These buffers collect events such as key presses, mouse movements, and touch interactions, which are then dispatched to applications via callbacks registered with the buffer. This event-driven model supports both blocking and non-blocking operations, allowing efficient integration into application loops while minimizing latency in resource-constrained embedded environments.[27][4] Device support in DirectFB is provided through modular input drivers, with the primary backend being the linux_input driver that interfaces with the Linux evdev subsystem via /dev/input/event* devices. This driver handles a wide range of peripherals, including keyboards, mice, and touchscreens, by translating kernel-generated events into DirectFB's internal format. For multi-touch gestures, the driver leverages the Linux input protocol's multi-touch extensions, enabling recognition of simultaneous contact points and gesture patterns common in embedded touch interfaces. Joystick integration is similarly supported through evdev, allowing game controllers and analog devices to generate axis, button, and hat events that applications can process for interactive control.[15][28][4] Input transformation occurs within the event processing pipeline, where DirectFB applies coordinate mapping to align physical device coordinates with virtual surfaces or windows. This involves matrix-based transformations to handle scaling, rotation, and translation, ensuring accurate event delivery across layered or multi-monitor setups. For embedded sensors prone to environmental interference, DirectFB incorporates filtering mechanisms to mitigate noise, such as debouncing for erratic touch signals or smoothing algorithms for imprecise analog inputs, drawing from the underlying Linux input driver's calibration capabilities. Graphics surfaces can respond to these transformed events by updating their state, such as highlighting interactive elements.[4][29] The security model for input access emphasizes controlled permissions to prevent unauthorized device interception. DirectFB applications can operate without root privileges through appropriate file permissions on devices like /dev/fb* and /dev/input/*, typically by adding users to the 'video' and 'input' groups for access to framebuffers and event streams. This approach balances usability in embedded systems with security by restricting direct hardware manipulation.[2][30]Features
Rendering and Acceleration
DirectFB supports hardware-accelerated 2D primitives essential for efficient graphics rendering in resource-constrained environments, including StretchBlit for scaled and transformed image transfers, FillRectangle for solid-color area filling, and DrawLine for vector-based line rendering.[4] These operations leverage chipset-specific drivers, such as those for the Vivante GC320 GPU, to offload computation from the CPU, with software fallbacks for unsupported features. Alpha compositing in DirectFB enables seamless blending of graphical elements through support for all Porter-Duff rules, implemented via nine distinct blending functions for source and destination alpha channels, including per-pixel modulation for translucent GUI components.[14] This allows developers to apply operations like source-over and destination-in directly to surfaces, facilitating complex visual effects without excessive CPU involvement when hardware acceleration is available.[14] Video playback integration focuses on efficient decoding and overlay rendering, utilizing libraries such as libmpeg2 for MPEG formats to decode streams into DirectFB surfaces, with provisions for zero-copy transfer to hardware decoders to minimize latency in embedded multimedia applications.[14] Providers like DirectFBVideoProvider handle overlay compositing, ensuring synchronized rendering of video layers alongside 2D graphics.[15] Performance benchmarking in embedded scenarios demonstrates the impact of these features; for instance, hardware-accelerated rendering in sample applications achieves up to 60 frames per second at 720p resolution on platforms like Raspberry Pi, avoiding CPU fallbacks for sustained playback and UI responsiveness.[31]Windowing and Layer Management
DirectFB's windowing system is built around the IDirectFBWindow interface, which enables developers to create and manage resizable, decorated windows suitable for embedded and non-desktop environments. This interface provides methods for positioning, sizing, and closing windows, while supporting focus management to handle user input directed to the active window. Windows are rendered as surfaces with support for translucency through ARGB pixel formats and per-pixel alpha blending, allowing for overlapping compositions in a window stack managed by the default window manager module, libdirectfbwm_default.so.[14][15] Layer management in DirectFB allows for the configuration of multiple display layers via the IDirectFBDisplayLayer interface, which is essential for scenarios such as video walls or heads-up displays where distinct visual planes need independent control. Each layer occupies a separate area in video memory and supports alpha blending for stacking, with priority settings determining the rendering order and composition without requiring repaints of upper layers when lower ones update. Layers can be configured using tools like dfblayer or the directfbrc configuration file, accommodating hardware capabilities that vary from a single layer on standard PCs to several on set-top box systems. SubSurfaces within layers further enable targeted rendering for specific regions, such as video overlays.[14][17][26] Input focus and clipping mechanisms ensure precise event handling and rendering boundaries in multi-window applications. Region-based event routing directs inputs from devices—accessed through IDirectFBInputDevice and IDirectFBInputBuffer interfaces—to the focused window based on its spatial position and stacking order, supporting keyboards, mice, and other peripherals via Linux input abstractions. Clipping is implemented through scissoring and SubSurface restrictions, which confine drawing operations to defined regions and prevent overlaps or artifacts in layered or stacked windows.[14] Theming in DirectFB is facilitated by the Fusion IPC layer, which supports basic widget sets for consistent user interfaces across multi-process GUIs. Fusion, enabled via the fusion.ko kernel module or user-space implementation, allows shared resource management and inter-process communication, enabling multiple applications to cooperate on windowing and input without conflicts. This setup is configurable during build with options for single- or multi-application cores, promoting efficient resource sharing in environments like embedded multimedia systems.[15][4]Applications
Embedded and Multimedia Use Cases
DirectFB has found significant application in embedded Linux environments, particularly within resource-constrained devices such as set-top boxes, where it enables efficient UI rendering and video decoding without the overhead of a full graphical operating system like X11.[23] By providing direct access to framebuffer hardware, DirectFB supports lightweight multimedia systems, such as GeexBox, a compact (6 MB) media center that leverages DirectFB for handling MP3, OGG, DivX, XviD, VCD, SVCD, DVD, and JPEG playback through its integrated video providers for formats like MPEG1/2 and AVI.[23] This approach minimizes memory footprint and boot times, making it suitable for devices with limited RAM and storage.[13] In multimedia frameworks, DirectFB integrates seamlessly with GStreamer via the dfbvideosink element, which renders video frames directly onto DirectFB surfaces for accelerated playback in pipelines.[32] This integration supports two modes: standalone for fullscreen video with automatic scaling and mode switching, and embedded for rendering into application-specific surfaces, enabling efficient handling of real-time video in scenarios like digital kiosks or automotive infotainment systems.[32] For instance, developers can use commands likegst-launch-1.0 videotestsrc ! dfbvideosink to test hue, saturation, and brightness adjustments, demonstrating its role in building robust, hardware-accelerated multimedia applications on embedded platforms.[32]
DirectFB excels in real-time constraints, offering low-latency drawing capabilities for games and animations through hardware-accelerated operations like blitting and blending.[4] It supports ported SDL applications and includes demonstration programs such as df_knuckles for 3D rendering, df_neo for scaling animations, and df_particle for particle effects like fountains, which highlight its suitability for interactive, performance-sensitive tasks in embedded gaming or UI animations.[23][4] Additionally, tools like DFBSee for media playback and DFBView for image viewing further illustrate its use in real-time multimedia scenarios.[4]
The library's power efficiency stems from its direct hardware control, which bypasses unnecessary abstraction layers to reduce CPU usage and power consumption in battery-powered devices.[23] With a core library size of approximately 1 MB and no dependencies beyond libc, DirectFB2—the maintained fork—optimizes for such environments by enabling multiple applications to share graphics resources via its Fusion IPC mechanism, thus conserving energy in prolonged operations like video streaming or interactive displays.[28][4]