Legacy framebuffer (fbdev) display drivers
The original Linux framebuffer subsystem, providing a simple linear pixel buffer interface for graphics hardware ranging from 1990s workstation cards (like DEC TGA) and embedded LCD controllers to modern firmware-provided framebuffers such as the EFI boot console on current UEFI PCs. It predates today's DRM/KMS graphics stack and is what /dev/fb0 has historically pointed at.
recommendation
Worth keeping but clearly labelled as legacy. New systems should rely on DRM/KMS drivers with fbdev emulation, but the subsystem still serves a real purpose: efifb gives modern UEFI machines a working boot console, and a long tail of older workstation and embedded hardware has no DRM equivalent. Upstream maintainers (notably Thomas Zimmermann's 2023 series) are refactoring fbdev to make more of it optional rather than removing it outright, so it remains actively maintained in a hospice-care sense.
repository signals
sources
- spinics.net
Thomas Zimmermann's 2023 fbdev patch series says modern Linux distributions have adopted DRM for graphics output, fbdev is largely legacy, and future work is to make more fbdev userspace/file-I/O pieces optional rather than remove the subsystem outright.
- cateee.net
Current LKDDb entry for CONFIG_FB shows fbdev is still present through current kernels/HEAD, and its help text explicitly says DRM provides emulated framebuffer devices on top of KMS while CONFIG_FB enables legacy native fbdev drivers.
- cateee.net
EFI framebuffer support remains in current kernels, showing fbdev still covers a live firmware-framebuffer/boot-console niche on modern UEFI systems.
- cateee.net
The directory still includes drivers for clearly legacy hardware such as DEC TGA/SFB+ boards, indicating a substantial long-tail preservation role rather than a subsystem centered on new mainstream products.
codex reasoning notes (technical)
Real driver subsystem, not an auxiliary directory: local shell inspection of drivers/video/fbdev/Kconfig shows many native framebuffer drivers and the FB menu. Upstream activity is clearly still present (given task metadata plus web-searched 2023 patch thread at spinics from turn2search2), but the thread frames fbdev as legacy and moving toward optional userspace exposure instead of immediate subsystem removal. Replacement path is explicit in local Kconfig and corroborated by LKDDb (turn3search0): DRM/KMS with fbdev emulation. Deployment is not zero because firmware framebuffers such as efifb are still relevant on new UEFI machines (turn3search3), while many native chip drivers are for old workstation/embedded hardware (turn3search1). Chosen keep-annotate: active maintenance/refactoring argues against deprecate/remove, but subsystem should be annotated as legacy with DRM preferred for new deployments.