Community-built Linux DRM/KMS driver brings modern display support to SM750 HDMI card

An experimental, community-built Linux display driver has appeared for the SM750, an obscure Silicon Motion graphics chip found on a single-HDMI PCIe card, replacing the kernel's ageing framebuffer path with a modern DRM/KMS implementation. The project, published on GitHub by developer KodeMunkie and surfaced on Hacker News's front page, targets one specific board sold or marked as the SE-DP750A-HDMI.

What the driver supports

According to the repository, the qualifying card pairs a Silicon Motion SM750G10-AC (revision A1, PCI ID 126f:0750) with a Silicon Image/Lattice SiI9024ACNU HDMI transmitter and 16 MiB of display memory. The PCI ID alone is not enough to identify a working board: other SM750 cards may use VGA, a different transmitter or different GPIO wiring, and those are not currently supported.

The driver ships as a DKMS package buildable on Ubuntu 24.04 and Linux Mint 22, producing the kernel module sm750hdmidrm.ko, a name chosen so it cannot be confused with the old sm750fb.ko. The post-install reboot matters, because it lets the package blacklist Linux's existing sm750fb framebuffer driver before it can claim the card. Kernel support targets Linux 6.17 and newer, and DKMS deliberately refuses older kernels since the required DRM interfaces are missing. Compatibility paths cover the 6.x series and Linux 7.0 onward; the project reports the full test suite builds and passes against 6.17 and 7.0 Ubuntu kernels, though as an out-of-tree driver a future kernel may still force a source update.

Engineering around a slow PCIe link

The SM750's framebuffer is reached over a PCIe 1.1 x1 link, which cannot carry responsive full-screen 32-bit updates at higher resolutions. The driver's answer is dithered 16-bit RGB565 scanout: applications keep rendering in 32-bit colour, but immediately before upload the driver converts changed regions to RGB565 and applies an ordered dither with a 94% green-channel correction. Since RGB565 moves two bytes per output pixel instead of four, device-bound pixel traffic is halved while much of the apparent colour detail survives.

By default the driver uses EDID modes, a hardware cursor, coalesced updates on a worker, and eight-row DMA upload batches with automatic CPU fallback if DMA fails. Module parameters expose the tradeoffs: full XRGB8888 scanout at double the upload cost, plain undithered RGB565, DMA disabled, a software cursor, and snapshot comparison to skip unchanged pixels at the cost of extra system memory.

Pushing past the specification

The device is normally described as supporting up to 1920 pixels horizontally, but with edid_only=0 the driver exposes real 2048-wide hardware modes: 2048x864, 2048x1024, 2048x1080 and 2048x1152 at refresh rates from 50 up to 75 Hz depending on the mode. The repository is blunt about risk: these modes are not restricted by EDID, may exceed published GPU or monitor clock limits, and can result in no signal, distortion or an unstable display, so an SSH recovery route is recommended.

2048 is a hard ceiling. The SM750's primary graphics plane has an 11-bit right-edge field, so physical scanout width cannot exceed 2048 pixels no matter the height. To go wider, softscale_wide=1 creates logical desktops of 2464x1080 or 2560x1080 by horizontally compressing the image into a 2048x1080 HDMI signal, which a 2560x1080 ultrawide monitor running its full-widescreen stretch option expands back across the panel. The 2464 mode is recommended, optionally with an 8% contrast sharpening pass. The project is candid that the stretch restores screen coverage and approximately the intended aspect ratio, not lost source detail.

Why it matters

This is a case study in open source extending the life of hardware nobody else will modernise. The SM750's mainline Linux support amounts to an old framebuffer driver, while the rest of the desktop stack long ago moved to DRM/KMS; this project closes that gap for at least one board. It does so with careful engineering, bandwidth-aware dithering, batched DMA and safe fallbacks, rather than brute force, and it documents the chip's real limits, including the 2048-pixel plane constraint, instead of guessing. The scope is deliberately narrow and explicitly experimental, so it is not a general SM750 solution. But it shows that a single motivated developer can reverse-engineer the constraints of abandoned silicon, exceed the marketed specs where physics allows, and ship reproducible DKMS packaging on top, which is precisely the dynamic that keeps niche hardware useful long after vendor interest fades.