Glonce

sm750hdmifb driver brings real ultrawide output to old SM750 GPUs

toolsThe Glonce editorsHacker News🔥48Glonce rating48Impact18Novelty55Relevance65Surprise30Players15Credibility88
sm750hdmifb driver brings real ultrawide output to old SM750 GPUs

KodeMunkie has released sm750hdmifb, an open-source Linux driver built for one specific board: the SE-DP750A-HDMI, a single-HDMI PCIe card using the Silicon Motion SM750G10-AC GPU (revision A1), a Silicon Image/Lattice SiI9024ACNUHDMI HDMI transmitter, 16 MiB of display memory and one HDMI output, identified by PCI ID 126f:0750. The project is explicit that the PCI ID alone is not enough to guarantee support: other SM750 cards using VGA output, a different transmitter, or different GPIO wiring are not covered.

Installation on Ubuntu 24.04 or Linux Mint 22 goes through DKMS: install build-essential, dkms, matching linux-headers and libdrm-dev, clone the repository, run make check and ./build-package.sh, then install the resulting .deb (the documented example is version 0.5.5) and reboot. The reboot matters because it lets the new package blacklist the kernel's existing in-tree sm750fb driver before that driver claims the card; the new kernel module is named sm750hdmidrm.ko specifically so it cannot be confused with sm750fb.ko. The driver targets Linux 6.17 and newer, and DKMS deliberately refuses to build on older kernels because the DRM interfaces it needs are not present there. The source carries compatibility paths across the 6.17-to-6.x series and into the 7.0-plus line, and it currently builds and passes its full test suite against 6.17 and 7.0 Ubuntu kernels, with a manual CI workflow also building against Ubuntu 24.04's 6.17 headers. There is no fixed upper kernel version cap, but the project warns that because it is out-of-tree, a future kernel could still change internal DRM APIs and require a source update even within the intended range.

By default the driver uses monitor EDID modes and a dithered 16-bit RGB565 scanout rather than full 32-bit color, with a hardware cursor, coalesced worker updates, and eight-row DMA batch uploads that fall back safely if DMA fails. The reasoning is bandwidth: the SM750 framebuffer sits behind a PCIe 1.1 x1 link, and XRGB8888 sends four bytes per output pixel where RGB565 sends two, so the dithered RGB565 path roughly halves device-bound pixel traffic while preserving most of the apparent color detail.

The headline capability is ultrawide output. The card is normally described as supporting up to 1920 pixels horizontally, but setting edid_only=0 exposes real 2048-wide hardware modes, and setting softscale_wide=1 adds two wider logical desktops on top of that, both requiring a physical 2560x1080 ultrawide monitor with full widescreen stretch enabled in its own on-screen menu. The hardware ceiling is fixed: the SM750's primary graphics plane has an 11-bit right-edge field, so its real scanout width cannot exceed 2048 pixels no matter what software does; the wider 2464 and 2560 modes are logical, software-side desktops that the card still outputs as a 2048-pixel signal, which the monitor then stretches back to its full physical width.

The two wide modes trade differently. The 2560x1080 mode applies a 20% horizontal compression, squeezing the 2560-wide logical desktop down to the 2048-pixel signal, and the monitor then expands that signal by 25% to refill its panel, giving a true 2560x1080-sized workspace at the cost of some fine horizontal detail. The 2464x1080 mode is the one the project recommends for a physical 2560x1080 monitor: it starts with 3.75% fewer desktop pixels, compresses width by only 16.9%, and the resulting image ends up about 3.9% wider than its logical geometry, a small aspect distortion the project describes as generally hard to notice, in exchange for better responsiveness and a sharper picture. Enabling sharpen=1 is recommended alongside it, applying a fixed 8% contrast sharpen after compression. The default rgb565-bbdither scanout format uses an 8x8 ordered dither that KodeMunkie designed specifically for this card, with an adjustable green-channel correction set to 94% and a pattern anchored to screen coordinates so it does not crawl during small updates. A documented all-features test profile (edid_only=0, softscale_wide=1, sharpen=1, scanout_format=rgb565-bbdither, double_shadow=1, enable_dma=1) carries an explicit warning that it disables EDID restrictions and exposes clocks above specification, which can blank or destabilize the display; the project recommends keeping SSH or another recovery route available before experimenting. A photographed demo shows the driver filling a 2560x1080 panel at 75 Hz.

The HN submission was titled 'Why open source rocks,' and the project's own documentation explains why: it says the driver was built through extensive AI-assisted or vibe coding. The author states he specified and physically tested the behavior and designed the custom dither himself, but does not claim enough Linux DRM, KMS, DKMS, or kernel-framework expertise to independently guarantee every implementation detail, and is publishing the source for review and improvement rather than as a claim of finished, expert-audited kernel quality. The project is licensed GPL-2.0-only; DDK-derived files came from the Linux kernel's own GPL-2.0 staging sm750fb driver, and no proprietary Silicon Motion driver, binary object, or firmware blob is included or linked. The documentation also notes that the official SM750 specification is itself known to be wrong about at least one hardware-observed partial-update boundary, and that empirically verified workarounds already in the source must not be removed just because an ideal model or the specification says they are unnecessary.

Key facts

  • sm750hdmifb is a new open-source Linux DKMS driver targeting one specific board, the SE-DP750A-HDMI (Silicon Motion SM750G10-AC rev A1, SiI9024ACNUHDMI transmitter, 16 MiB display memory, PCI ID 126f:0750), and requires Linux 6.17 or newer.
  • The SM750's primary graphics plane has an 11-bit right-edge field, capping real hardware output at 2048 pixels wide; the driver's 2464x1080 and 2560x1080 ultrawide modes are software-side logical desktops that still leave the card outputting a 2048-pixel signal for the monitor to stretch.
  • The 2560x1080 mode compresses the desktop by 20% then relies on the monitor expanding the signal 25%; the recommended 2464x1080 mode compresses only 16.9%, keeps 3.75% fewer desktop pixels, and ends about 3.9% wider than its logical geometry.
  • The default scanout is a dithered 16-bit RGB565 image, using a custom 8x8 dither with 94% green-channel correction, instead of 32-bit color, because the card's PCIe 1.1 x1 link cannot sustain XRGB8888's 4 bytes per pixel; RGB565's 2 bytes roughly halves that traffic.
  • The author says the driver was built through extensive AI-assisted or vibe coding, was physically tested on real hardware, and is released GPL-2.0-only with no proprietary Silicon Motion code; experimental non-EDID modes can destabilize the display and the project recommends keeping SSH access available before trying them.

Why it matters

Legacy, niche graphics hardware like the SM750-based SE-DP750A-HDMI card is normally stuck with whatever in-tree driver the kernel ships, capped at whatever the vendor documented. sm750hdmifb is a from-scratch, out-of-tree, AI-assisted project that goes past that: it exposes a genuine 2048-pixel hardware mode the card was not advertised to reach, adds a software path to a real 2560x1080 ultrawide desktop, and documents a place where the official SM750 specification is itself wrong. The HN submitter's chosen framing, 'why open source rocks,' points at exactly that: one person reverse-engineering and shipping a fix that neither the silicon vendor nor the upstream kernel driver provided.

Who it affects

Owners of the specific SE-DP750A-HDMI board (Silicon Motion SM750G10-AC revision A1, PCI ID 126f:0750, SiI9024ACNUHDMI transmitter) running Ubuntu 24.04 or Linux Mint 22 on a Linux 6.17 or newer kernel. The project is explicit that other SM750 cards, including ones with VGA output, a different transmitter, or different GPIO wiring, are not supported even if they share the PCI ID. Anyone chasing the ultrawide modes also needs a physical 2560x1080 monitor with full widescreen stretch enabled in its own on-screen menu.

How to use it

Install build-essential, dkms, matching linux-headers, and libdrm-dev, clone the repository, run make check and ./build-package.sh, install the resulting .deb (the documented example is version 0.5.5), and reboot; the reboot lets the package blacklist the kernel's existing sm750fb driver before it claims the card, and the new module is named sm750hdmidrm.ko to avoid collision. Kernel parameters, all under the sm750hdmidrm. prefix and set through GRUB_CMDLINE_LINUX_DEFAULT plus update-grub, control behavior: edid_only=0 exposes the real 2048-wide hardware modes, softscale_wide=1 adds the two wider logical desktops, sharpen=1 applies an 8% contrast sharpen, scanout_format=rgb565-bbdither selects KodeMunkie's custom dither, and enable_dma toggles DMA uploads. The project is GPL-2.0-only, with DDK-derived code drawn from the Linux kernel's own GPL-2.0 staging sm750fb driver and no proprietary Silicon Motion binaries included.

How solid is it

The driver currently builds and passes its full test suite against Linux 6.17 and 7.0 on Ubuntu, and a manual CI workflow also builds it against Ubuntu 24.04's 6.17 kernel headers; the source carries compatibility paths across the 6.17-to-6.x series and into the 7.0-plus line, though the author notes there is no fixed upper kernel cap and a future kernel could still force a source update. It has been tested and photographed working at 2560x1080, 75 Hz on real hardware. The author is direct about the limits of that testing: he says he specified and physically tested the behavior and designed the custom dither himself, but does not claim enough Linux DRM, KMS, DKMS, or kernel-framework expertise to independently guarantee every implementation detail, and is publishing the source for outside review rather than as finished, expert-audited kernel code.

Risks and caveats

This is experimental software scoped to one narrowly defined board; other SM750 cards are unsupported even with a matching PCI ID. Non-EDID or above-specification modes, including the documented all-features test profile (edid_only=0, softscale_wide=1, sharpen=1, scanout_format=rgb565-bbdither, double_shadow=1, enable_dma=1), can exceed published GPU, transmitter, or monitor clock limits and may produce no signal, distortion, or an unstable display; the project recommends keeping SSH or another recovery route available before trying them, and describes recovering by booting an older kernel entry or removing the added GRUB options. The project's own documentation discloses it was built through extensive AI-assisted or vibe coding, which is the stated reason the author frames the source as open for review and improvement rather than a guarantee of correctness.

“This project was created through extensive AI-assisted or "vibe coding". I have specified and physically tested the behaviour and designed the custom dither, but do not claim enough Linux DRM, KMS, DKMS, or kernel-framework expertise to independently guarantee every implementation detail.”

— KodeMunkie, sm750hdmifb project documentation