Driver open source revive GPU SM750 de Silicon Motion

Una tarjeta barata y olvidada vuelve a tener driver nativo en Linux

El desarrollador KodeMunkie publicó el 30 de agosto de 2026 un driver DRM open source para una tarjeta gráfica PCIe basada en el chip Silicon Motion SM750, un chipset integrado de gama baja pensado originalmente para terminales punto de venta, displays industriales y thin clients. El driver, llamado sm750hdmifb (con el módulo de kernel sm750hdmidrm.ko), permite que esta tarjeta vuelva a dar salida HDMI en Linux 6.17 y versiones posteriores, incluida la rama 7.x.

El proyecto está licenciado GPL-2.0-only y reutiliza archivos DDK del antiguo driver sm750fb que Linux mantenía en staging, pero sin incluir binarios propietarios ni blobs de firmware de Silicon Motion. La auditoría de procedencia está documentada en el propio repositorio.

La placa específica que sí funciona

El driver no es universal: solo está validado para una placa en concreto, la SE-DP750A-HDMI, que combina:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Silicon Motion SM750G10-AC, revisión A1
PCI ID 126f:0750
Transmisor HDMI Silicon Image/Lattice SiI9024ACNU
16 MiB de memoria de vídeo
Una única salida HDMI

El propio README advierte que el PCI ID no basta: otras tarjetas SM750 pueden usar VGA, un transmisor distinto o un cableado GPIO diferente, y no están soportadas. Quien tenga una tarjeta dudosa puede verificar el binding con lspci -nnk -d 126f:0750.

El truco técnico: RGB565 con dither ordenado

La tarjeta se conecta por PCIe 1.1 x1, un enlace muy estrecho para los estándares actuales. A resoluciones altas, un framebuffer XRGB8888 (4 bytes por píxel) no da abasto y la pantalla se vuelve perezosa. El driver aplica por defecto una conversión a RGB565 con dither ordenado de 8×8 diseñado por KodeMunkie, con corrección del canal verde al 94%, anclado a coordenadas de pantalla para que las actualizaciones pequeñas no produzcan parpadeo.

El resultado: el tráfico de subida hacia la GPU se reduce a la mitad, manteniendo suficiente detalle visual para un escritorio. Quien quiera 32 bits reales puede forzarlo con scanout_format=xrgb8888, asumiendo una caída de rendimiento notable en resoluciones altas.

DMA de ocho filas está verificado, con fallback automático a CPU si falla. Las opciones relevantes —dither_green_gain, enable_dma, disable_hardware_cursor, async_updates— están documentadas en la sección Module parameters del repositorio y se aplican vía GRUB_CMDLINE_LINUX_DEFAULT.

Modos 2048 nativos y ultrawide por software

El hardware tiene un límite físico claro: el plano primario del SM750 usa un campo de 11 bits para el borde derecho, así que su scanout nunca supera los 2048 píxeles horizontales. Eso es independiente de la altura.

Con edid_only=0 el driver expone modos reales 2048×864, 2048×1024, 2048×1080 y 2048×1152, fuera de las restricciones EDID. Combinando softscale_wide=1 se obtienen dos escritorios lógicos más anchos, 2464×1080 y 2560×1080, pensados para un monitor ultrawide 2K con la opción FULL WIDESCREEN STRETCH activada en su menú OSD.

La cadena completa es: escritorio lógico → compresión por software → 2048×1080 vía HDMI → estirado por el monitor hasta los 2560 píxeles físicos del panel. El driver recomienda 2464×1080 como modo por defecto: solo un 16,9% de compresión horizontal y un 3,75% menos de píxeles fuente, con la nitidez activable vía sharpen=1. El modo 2560×1080 ofrece un escritorio más ancho real pero aplica una reducción 5:4 (20% de compresión) y, según el autor, menos detalle y peor rendimiento.

Toda la sección viene con una advertencia clara en mayúsculas: DANGER, EXPERIMENTAL, y el recordatorio de mantener una ruta de recuperación (SSH, kernel antiguo en GRUB) porque un modo mal elegido puede dejar la pantalla en negro o inestable.

Cómo se instala en Ubuntu 24.04 y Linux Mint 22

El repositorio incluye un script build-package.sh que produce un .deb con integración DKMS. El flujo resumido es:

sudo apt update
sudo apt install build-essential dkms linux-headers-$(uname -r) libdrm-dev git
git clone https://github.com/KodeMunkie/sm750hdmifb.git
cd sm750hdmifb
make check
./build-package.sh
sudo apt install ./dist/sm750hdmifb_0.5.5_all.deb
sudo reboot

El reinicio es importante: el paquete introduce un blacklist para que el viejo sm750fb.ko no se cargue antes que el nuevo driver. El módulo se llama sm750hdmidrm.ko precisamente para no confundirlos. Cuando hay paquetes precompilados se publican en GitHub Releases, pero el autor recomienda compilar localmente contra las cabeceras del kernel instalado.

DKMS rechaza deliberadamente kernels anteriores a 6.17 porque las interfaces DRM requeridas no están soportadas. No hay un tope superior fijo: kernels futuros pueden cambiar APIs internas y obligar a actualizar el código.

«Vibe coding» transparente y el debate en el kernel

KodeMunkie asume en el README que el proyecto fue creado con asistencia extensiva de IA y lo etiqueta como vibe coding —el término que popularizó Andrej Karpathy para describir código generado conversando con un modelo—. Dice textualmente que diseñó y probó físicamente el comportamiento y el dither, pero no se considera experto en Linux DRM, KMS, DKMS ni en frameworks de kernel, y publica el código para revisión y mejora, no como un reclamo de calidad upstream.

El contexto importa: en julio de 2026, Linus Torvalds zanjó el debate dentro del kernel Linux declarando que el proyecto no es anti-IA y que los mantenedores que usen herramientas de IA «no pueden ser impedidos de hacerlo». Las guidelines actuales del kernel permiten contribuciones asistidas por IA siempre que un humano revise, valide y firme con el Signed-off-by del DCO, y disclosures importantes se marquen con un tag Assisted-by.

A la vez, Gartner y Forrester advertían este mismo año que el vibe coding en empresas estaba introduciendo secretos hard-codeados subidos por error a GitHub y bugs latentes difíciles de revisar. El driver SM750 es un ejemplo honesto de ese trade-off: aporta valor funcional y está abierto a escrutinio, pero su autor mismo pide que expertos lo revisen antes de llevarlo a upstream.

Qué significa esto para tu startup

Aunque la tarjeta no es la prioridad de un founder SaaS, hay tres lecciones accionables:

El open source sigue rescatando hardware de la basura. Una tarjeta que costaba poco y ya nadie soportaba vuelve a servir para un escritorio ultrawide funcional con Linux moderno. Si tu empresa depende de hardware especializado, vale la pena auditar qué drivers críticos siguen vivos y quién los mantiene.
La IA ya está tocando el kernel. El propio Linus Torvalds validó el uso de IA como herramienta, pero dejó claro que un humano debe firmar cada contribución. Si tu equipo usa Copilot, Cursor o Claude Code para drivers, middleware o scripts críticos, exige el mismo estándar: revisión humana, tests, y标明 de Assisted-by.
Empieza por lo verificado y etiqueta el riesgo. El driver funciona sobre una placa concreta con un PCI ID concreto; todo lo demás está marcado como experimental. Cuando integres proyectos open source de un solo autor, replica ese modelo: separa el camino soportado del experimental con flags claras y rutas de recuperación.

Antes de probarlo en una máquina de producción, haz copia de seguridad, mantén un kernel anterior arrancable y reserva acceso SSH —el propio README lo exige, y por buenas razones.