Kernel maintainers cut Linux support for 44-year-old graphics card

Kernel developers removed support for a 44-year-old graphics card in Linux 7.2, according to XDA's June 17 report. The supplied report metadata identifies the affected hardware by age, not model, but the result stays clear: users who run mainline Linux on that class of original graphics hardware need an older kernel, an out-of-tree patch or a hardware swap.

The Linux project publishes upstream releases at kernel.org and develops the kernel in a public Git tree. A removal in that tree differs from a distribution package change. Fedora, Arch, Debian and other maintainers can carry patches for a time, but most distributions use upstream hardware support as the base for future kernels.

For desktop users, Linux 7.2 changes little. AMD, Intel and Nvidia graphics support runs through the DRM/KMS stack, Mesa, Wayland compositors and Xorg drivers. A card from 1982 predates PCI, GPU command processors and 3D acceleration APIs, so it plays no part in that path. You will keep Wayland support on a laptop after kernel developers remove code for a board from the first IBM PC era.

Retrocomputing users face a different problem. If you maintain an old x86 machine as a working Linux host, kernel support can matter more than desktop polish. The graphics driver may give you a framebuffer console and boot logs. After Linux 7.2, you need to keep a kernel that contains the driver or carry the code yourself.

The developer case for removal starts with maintenance. Kernel developers have to review patches and handle bug reports. Old graphics drivers can touch I/O ports and console paths that few maintainers can test on real hardware. Without users who can test patches, maintainers carry dead code with risk attached.

Linux has made similar calls across old x86 support. Kernel maintainers have targeted i486-era CPU support, AMD K5 support and Intel 440BX EDAC code in recent cleanup work covered by outlets that track the kernel, including Phoronix, Tom's Hardware and TechRadar Pro. Those changes share one theme: maintainers want fewer special cases in code paths that touch timing and memory.

If you build kernels for older machines, check your config before you move to Linux 7.2. Run lspci -nn or lshw -C display on systems that support those tools. Save dmesg output from a working boot and compare your .config against the new kernel with make oldconfig. A missing symbol for the graphics driver tells you the upgrade needs a plan.

For hobby systems, the clean migration path starts with a known-good long-term kernel. Keep the matching source and config file with the machine. Add compiler notes beside them. If you need network exposure, put the old box behind a firewall and move internet-facing work to supported hardware. If the machine serves as a museum piece or lab target, treat the kernel as part of the artifact.

Developers who need current user space on old hardware have two practical options. They can forward-port the driver as an out-of-tree module if the code fits current kernel APIs, or they can move the workload to newer display hardware and keep the old card for DOS, BSD or period-correct Linux builds. The first option costs engineering time. The second option preserves the machine with fewer surprises.

Cross-platform maintainers should read this as a reminder about support floors. Android kernels and desktop Linux distributions set hardware baselines that move. Teams that ship appliances or test rigs on old PCs should document kernel pins and graphics dependencies. They should list replacement parts beside that documentation.

For old-computer owners, Linux 7.2 sets a sharper boundary around original-era graphics hardware. If you depend on that card, freeze the known-good stack, record the boot path and decide who owns the driver before your next kernel upgrade.