El controlador HDMI SM750 de Silicon Motion llegó a Hacker News y dejó al descubierto la verdadera ventaja del código abierto

El SM750 de Silicon Motion recibió un nuevo controlador HDMI experimental, que atrajo 59 puntos y 30 comentarios en Hacker News pese a estar dirigido a una tarjeta gráfica poco conocida. El proyecto hace más que permitir que un adaptador antiguo muestre un escritorio Linux. Demuestra cómo el código abierto puede recuperar capacidades de hardware que el soporte del proveedor, las especificaciones incompletas y un antiguo controlador del kernel habían dejado inaccesibles.

El desarrollador, que utiliza el nombre KodeMunkie, creó el controlador para la tarjeta PCIe SE-DP750A-HDMI. Esa placa combina un chip gráfico SM750G10 con un transmisor HDMI SiI9024A independiente. El software resultante sustituye la antigua ruta de framebuffer de Linux por una implementación moderna de Direct Rendering Manager y Kernel Mode Setting.

El contraste es la verdadera historia. Un modelo de soporte propietario normalmente dejaría esta inusual tarjeta limitada a las capacidades elegidas por su fabricante. Un repositorio abierto permite a un propietario probar el hardware, publicar los resultados, exponer los riesgos e invitar a especialistas a cuestionar cada supuesto.

Qué cambia realmente el nuevo controlador HDMI SM750

El proyecto convierte un adaptador de pantalla con soporte muy limitado en un dispositivo Linux moderno y utilizable, al tiempo que documenta con precisión dónde termina ese soporte.

El controlador HDMI SM750 es un controlador Linux experimental exclusivo bajo GPL-2.0. Está dirigido a la tarjeta SE-DP750A-HDMI, no a todos los productos que incorporan un chip SM750. Esta distinción importa porque distintas placas SM750 pueden utilizar otros transmisores, conectores o cableado GPIO.

La tarjeta probada contiene una revisión A1 del SM750G10-AC, identificada por el ID PCI 126f:0750. Tiene 16 MiB de memoria de pantalla, una salida HDMI y un transmisor SiI9024ACNU. El transmisor convierte la salida digital paralela de la GPU en una señal HDMI porque el SM750 no incorpora una interfaz física HDMI nativa.

Este conocimiento específico del hardware es fundamental para el proyecto. Que coincida únicamente el ID PCI no demuestra la compatibilidad. Una tarjeta con la misma GPU podría ofrecer VGA, usar otro puente HDMI o conectar sus señales de control de forma distinta.

El nuevo controlador utiliza la arquitectura DRM/KMS de Linux. DRM gestiona los dispositivos y búferes de pantalla, mientras que Kernel Mode Setting permite al kernel configurar resoluciones, frecuencias de actualización, conectores y canalizaciones de pantalla. La canalización de pantalla KMS oficial conecta framebuffers, planos, controladores de pantalla, codificadores y conectores mediante una interfaz estándar del kernel.

Esa estructura ofrece a los escritorios Linux contemporáneos una base mejor que el antiguo controlador de framebuffer sm750fb. El paquete incluye deliberadamente ese módulo heredado en una lista negra antes de cargar su propio módulo de kernel sm750hdmidrm. También utiliza DKMS, que recompila un módulo de kernel externo con los encabezados instalados en la máquina del usuario.

El proyecto se dirige actualmente a Linux 6.17 y versiones posteriores. Su documentación indica que el código fuente incluye rutas de compatibilidad para Linux 6.17 hasta la serie 6.x, y Linux 7.0 en adelante. Sin embargo, sigue siendo un controlador fuera del árbol, por lo que futuros cambios en la API de DRM todavía pueden requerir actualizaciones.

El funcionamiento normal se mantiene relativamente conservador. El controlador lee los datos de identificación extendida de pantalla, o EDID, que enumeran los modos de visualización que un monitor declara compatibles. Utiliza esos modos de forma predeterminada, en lugar de habilitar de inmediato temporizaciones experimentales.

Las aplicaciones siguen renderizando en color XRGB8888 de 32 bits. Antes de transferir las regiones modificadas a la tarjeta, el controlador convierte esos píxeles a un formato RGB565 de 16 bits con dithering. RGB565 almacena los valores de rojo, verde y azul en dos bytes, en vez de los cuatro bytes utilizados por XRGB8888.

Esa conversión aborda un cuello de botella físico. La tarjeta se conecta mediante un enlace PCIe 1.1 x1 observado, lo que limita la velocidad a la que los nuevos píxeles llegan a su memoria de pantalla. Enviar dos bytes por píxel de salida reduce a la mitad el tráfico hacia el dispositivo frente a un formato de cuatro bytes.

El controlador también agrupa las cargas en bloques de ocho filas y utiliza acceso directo a memoria cuando está disponible. DMA permite que el dispositivo mueva datos sin que la CPU tenga que realizar directamente cada transferencia. Sigue disponible una alternativa basada en CPU si DMA falla.

Un cursor de hardware evita redibujar repetidamente el puntero dentro de la imagen principal del escritorio. Un trabajador de actualización asíncrona conserva la actualización pendiente más reciente en lugar de procesar una cola creciente de cambios obsoletos de pantalla. Son respuestas prácticas a un hardware limitado, no intentos de convertir el SM750 en una GPU moderna para juegos.

El resultado es un controlador de pantalla centrado en la salida de escritorio. No expone el antiguo motor 2D del chip como renderizado Xorg acelerado. Utiliza búferes sombra, que son imágenes en memoria del sistema que el controlador convierte y carga en la tarjeta.

Ese alcance limitado explica por qué el proyecto importa. El desarrollador no necesitó recrear todas las funciones históricas. El código abierto permitió concentrar el esfuerzo en las capacidades necesarias para que un sistema real resultara útil.

Por qué importa la atención de Hacker News

La respuesta de Hacker News refleja una preocupación recurrente entre desarrolladores: el hardware funcional suele sobrevivir a las suposiciones de software que lo rodean.

Un proyecto para una única tarjeta HDMI de bajo perfil rara vez se consideraría noticia tecnológica generalista. Sin embargo, el debate sobre código abierto acumuló 59 puntos y 30 comentarios en la instantánea suministrada de la portada. Esa atención surgió de lo que representa el proyecto, no del tamaño de su probable base de usuarios.

Los controladores gráficos se sitúan en una frontera incómoda. Deben coordinar interfaces del kernel, transferencias de memoria, formatos de píxel, temporizaciones de pantalla, cableado de placas y comportamiento de monitores. Un detalle de implementación ausente puede provocar desde un rendimiento deficiente hasta una pantalla en negro.

Los fabricantes de hardware tienen pocos incentivos comerciales para volver a ocuparse de cada placa antigua o especializada. Dar soporte a un kernel lanzado años después del principal período de ventas de un producto exige ingeniería, pruebas y mantenimiento continuo. Los adaptadores de bajo volumen son especialmente vulnerables cuando se asignan esos recursos.

El código abierto cambia la economía sin eliminar el trabajo. Un usuario con el hardware afectado puede investigar un problema concreto sin esperar a que exista un caso de negocio amplio. El código resultante se convierte entonces en evidencia examinable, en lugar de una solución privada.

Esa apertura es visible en todo el proyecto SM750. El repositorio identifica la tarjeta exacta probada, la configuración de memoria, el transmisor HDMI, el enlace PCI y los límites conocidos. Advierte que otras placas con el mismo ID PCI no son necesariamente compatibles.

El autor también revela el método de desarrollo del proyecto. Según el repositorio, el controlador fue creado con amplia asistencia de IA, a veces descrita como vibe coding. El desarrollador afirma que especificó y probó físicamente el comportamiento, pero que no puede garantizar de forma independiente cada detalle de implementación de DRM o del kernel.

Esa admisión refuerza la necesidad de revisión, al tiempo que debilita cualquier afirmación de preparación para producción. La IA puede ayudar a producir código y documentación, pero no puede sustituir una revisión experta, una cobertura de hardware más amplia ni el mantenimiento upstream. Publicar el código fuente crea la posibilidad de esas comprobaciones.

El diseño del controlador puede ahora examinarse en varios niveles. Los desarrolladores del kernel pueden evaluar el bloqueo y la seguridad de memoria. Los especialistas en pantallas pueden revisar la validación de modos. Otros propietarios de SM750 pueden probar si el comportamiento observado se extiende a sus placas.

Los investigadores de seguridad pueden inspeccionar el módulo en lugar de confiar en un binario opaco. Los mantenedores de distribuciones pueden estudiar su empaquetado y sus supuestos de compatibilidad. Los usuarios pueden decidir si los riesgos documentados encajan con sus propias opciones de recuperación.

Un controlador experimental propietario podría contener los mismos errores sin exponerlos. La diferencia no es que el código abierto comience siendo perfecto. La diferencia es que sus afirmaciones, atajos, procedencia y modos de fallo están disponibles para ser cuestionados.

Esa distinción adquiere más importancia cuando la IA contribuye código. Las implementaciones generadas pueden parecer plausibles mientras malinterpretan un contrato del kernel. La revisión pública proporciona una vía para detectar esos errores, aunque no garantiza que alguien lleve a cabo la revisión.

El pequeño repositorio sigue teniendo una validación limitada. En la instantánea observada, GitHub mostraba 35 commits, 26 estrellas, un fork, ninguna issue abierta y ninguna pull request abierta. Esas cifras describen interés inicial, no madurez.

Por tanto, la atención de Hacker News genera presión sobre dos grupos. Los fabricantes de hardware se enfrentan a nuevas preguntas sobre productos abandonados por los canales oficiales de software. Los desarrolladores de código abierto se enfrentan a la pregunta más difícil de cómo el código experimental se convierte en infraestructura mantenible.

La visibilidad puede atraer revisores técnicos, probadores y colaboradores. También puede animar a usuarios sin experiencia a instalar un módulo de kernel arriesgado porque un proyecto se ha popularizado. Las advertencias del repositorio deben seguir siendo más influyentes que su posición en la portada.

Por eso el acontecimiento es más significativo que sus cifras de adopción. Expone la brecha entre la capacidad del hardware y la capacidad admitida. El código abierto puede reducir esa brecha cuando alguien tiene el dispositivo, la paciencia y la libertad para publicar lo que descubre.

Documentación abierta frente a soporte limitado por el proveedor

El conflicto principal no es código comunitario contra código comercial; es conocimiento examinable y adaptable frente a un soporte que termina en el límite elegido por un proveedor.

Silicon Motion documentó el SM750 como un controlador gráfico de pantalla de bajo consumo con conectividad PCI Express, opciones de memoria integrada y varias rutas de visualización. La documentación del producto ofrece un punto de partida necesario, pero no describe cada implementación de placa ni todos los casos límite observados.

Los hallazgos de hardware del nuevo controlador comparan las capacidades publicadas con el comportamiento medido en la tarjeta de desarrollo. La documentación indica que la placa ofrece un enlace PCIe x1 de 2.5 GT/s y 16 MiB de memoria integrada utilizable.

El autor del controlador también informa de una discrepancia relacionada con actualizaciones parciales estrechas. Según el proyecto, algunas actualizaciones requieren un píxel de salida adicional más allá del cálculo de cobertura ideal o documentado. Sin esa solución alternativa, el píxel situado más a la derecha puede permanecer desactualizado.

Es una ilustración útil del papel del código abierto. Una especificación ofrece un modelo general, mientras que el hardware real revela cómo se comporta una implementación concreta. Publicar la solución alternativa permite a otros reproducir, refutar o perfeccionar el hallazgo.

El proyecto también supera de forma controlada la resolución horizontal indicada en la ficha del producto. Su documentación afirma que el SM750 puede realizar físicamente el escaneo de hasta 2,048 píxeles de ancho en la placa probada. El plano gráfico principal utiliza una coordenada de borde derecho de 11 bits, lo que crea un límite estricto de 2,048 píxeles de ancho.

Eso no significa que el chip genere de pronto una señal nativa de 2,560 píxeles. En cambio, el controlador ofrece escritorios ultrapanorámicos lógicos y los comprime antes de la salida. Un escritorio de 2,560 por 1,080 se convierte en una señal HDMI real de 2,048 por 1,080, que un monitor compatible estira después sobre su panel.

El modo de 2,560 píxeles utiliza una reducción exacta de 5:4. El software comprime el ancho en un 20 por ciento y el monitor expande la señal de 2,048 píxeles en un 25 por ciento. Esto restaura la cobertura de pantalla prevista, pero no puede recuperar el detalle descartado durante la compresión.

El modo alternativo de 2.464 por 1.080 adopta una solución de compromiso distinta. Renderiza 103.680 píxeles menos por fotograma que el modo de 2.560 de ancho, una reducción del 3,75 por ciento. A continuación, comprime la imagen un 16,9 por ciento antes de transmitirla.

El proyecto recomienda esa menor anchura lógica porque conserva más detalle horizontal y reduce el procesamiento. Sin embargo, estirar 2.464 píxeles lógicos sobre un panel de 2.560 píxeles genera aproximadamente un 3,9 por ciento de distorsión en el ancho.

Ninguna de las dos opciones modifica el silicio subyacente. La mejora práctica procede de combinar escalado por software, actualizaciones de regiones modificadas, conversión de color, DMA y estiramiento del lado del monitor. El código abierto hace explícita cada solución de compromiso.

El tramado personalizado es otro ejemplo. RGB565 ofrece solo cinco bits de rojo, seis de verde y cinco de azul por píxel. Esa menor precisión puede producir bandas de color visibles al cuantificar degradados suaves.

El tramado ordenado de KodeMunkie utiliza un patrón de 8 por 8 anclado a las coordenadas de la pantalla. El anclaje evita que el patrón se desplace cuando solo cambia una parte de la pantalla. La implementación también aplica una corrección predeterminada del 94 por ciento para el canal verde, basada en la salida probada.

Este diseño conserva la ventaja de transferencia de dos bytes a la vez que mejora el detalle de color percibido. No recrea el color completo de 24 bits. El proyecto presenta correctamente la técnica como una solución de compromiso entre ancho de banda y percepción.

Un controlador cerrado podría emplear optimizaciones similares. La diferencia es que los usuarios rara vez verían por qué se tomaron esas decisiones ni hasta qué punto se ajustan al hardware. Aquí, el algoritmo, los parámetros predeterminados y las observaciones físicas están disponibles para su revisión.

La documentación abierta también ayuda a separar el conocimiento transferible de las suposiciones específicas de una placa. El comportamiento de los registros del SM750 podría orientar otro controlador, mientras que la ruta de control del SiI9024A o las asignaciones de GPIO quizá solo se apliquen a este adaptador.

Ese límite evita que una historia atractiva se convierta en una afirmación universal falsa. El proyecto demuestra que una configuración de SM750 puede hacer más en Linux. No demuestra que todas las tarjetas SM750 puedan usar HDMI ni reproducir los mismos modos.

Esta distinción es donde los roles de proveedores y comunidad pueden complementarse. Los fabricantes poseen conocimiento de diseño, límites eléctricos y recursos de validación. Los usuarios poseen hardware desplegado, configuraciones inusuales e incentivos para resolver problemas que ya no encajan en una hoja de ruta de producto.

El código abierto ofrece el punto de encuentro. Permite que la documentación de los proveedores, las interfaces del kernel upstream, los experimentos físicos y la revisión independiente converjan en una implementación auditable. Que esa convergencia ocurra depende de la participación, no solo de la licencia.

La mayor fortaleza del controlador también es su riesgo

La misma libertad que descubre capacidades ocultas también permite a los usuarios superar límites validados, lo que convierte la cautela en parte de la característica y no en una idea tardía.

El controlador HDMI para SM750 expone resoluciones y frecuencias de actualización experimentales solo cuando los usuarios desactivan la restricción EDID predeterminada. Esa decisión es intencional, porque EDID normalmente protege al sistema de enviar modos que el monitor conectado no anuncia.

Establecer edid_only=0 pone a disposición el catálogo de modos más amplio del controlador. Activar softscale_wide=1 añade escritorios lógicos de 2.464 por 1.080 y 2.560 por 1.080. El repositorio etiqueta ambas opciones como peligrosas y recomienda mantener disponible SSH u otra vía de recuperación.

Varios modos de alta frecuencia merecen un examen particular. La documentación de modos del proyecto enumera salidas de 2.048 por 1.080 a 70, 72 y 75 Hz. Sus relojes de píxel documentados alcanzan aproximadamente 166,239, 171,142 y 178,592 MHz.

Esos valores superan el límite de 165 MHz utilizado por el controlador upstream de Linux para el puente SiI902x. Según se informa, los modos funcionaron con la tarjeta y el monitor del autor, pero una configuración exitosa no demuestra seguridad eléctrica ni compatibilidad amplia.

Un cable, conmutador KVM, adaptador, transmisor, GPU o monitor puede fallar en un punto distinto. Los síntomas pueden incluir una pantalla en negro, parpadeos, bordes de texto coloreados, geometría distorsionada o el reinicio del gestor de pantalla.

El monitor también debe admitir el estiramiento a ancho completo para que el enfoque ultrapanorámico se comporte como se espera. Sin ese ajuste, puede mostrar una imagen más estrecha o añadir bordes. Incluso con estiramiento, el detalle horizontal fino ya se ha combinado durante la compresión por software.

El rendimiento sigue limitado por el enlace PCIe. Convertir las actualizaciones a RGB565 reduce el tráfico, mientras que el seguimiento de regiones modificadas evita subir píxeles que permanecieron iguales. Ninguna técnica crea ancho de banda ilimitado.

El vídeo a pantalla completa, las interfaces animadas, el desplazamiento rápido y los grandes movimientos de ventanas pueden modificar la mayor parte del fotograma. Estas cargas de trabajo reducen la ventaja del seguimiento de actualizaciones parciales. Una GPU moderna con memoria y hardware de pantalla más rápidos seguirá estando mucho mejor preparada para ellas.

La política asíncrona del controlador crea otra solución de compromiso deliberada. Conserva la actualización pendiente más reciente en lugar de preservar todos los fotogramas obsoletos. Eso puede mejorar la capacidad de respuesta percibida porque la pantalla se pone al día en vez de reproducir estados intermedios ya obsoletos.

Sin embargo, esto no es el intercambio de páginas habitual entre búferes frontal y trasero. El controlador también ofrece una opción de doble sombra que compara instantáneas de la fuente y de la salida para omitir cargas redundantes. Ese ajuste consume memoria adicional del sistema y no debe confundirse con el intercambio por hardware.

La calidad del kernel es la incertidumbre más amplia. Un módulo externo interactúa con la gestión de memoria, las actualizaciones atómicas de pantalla, los conectores y los registros del dispositivo. Los errores en estas áreas pueden afectar a la estabilidad del sistema, no solo a la calidad visual.

El proyecto incluye pruebas, scripts de empaquetado y un flujo manual de integración continua. Sus indicaciones de prueba hacen hincapié en el acceso de recuperación y las recargas controladas de módulos. Estas prácticas reducen riesgos evitables, pero no sustituyen la revisión experta.

La inclusión upstream impondría un proceso más exigente. Los mantenedores de Linux examinarían la arquitectura, el estilo del código, las interfaces, la funcionalidad duplicada, el alcance del hardware y el mantenimiento a largo plazo. También podrían rechazar funciones que superen deliberadamente los límites de reloj documentados.

El proyecto no afirma actualmente tener calidad upstream. Esa moderación es importante. El entusiasmo de Hacker News no debería transformar un repositorio experimental en un respaldo implícito de Linux, Silicon Motion o el fabricante del transmisor HDMI.

La asistencia de IA añade otra capa de incertidumbre. La divulgación del autor hace visible la procedencia, pero la divulgación por sí sola no puede validar código generado. Los revisores aún deben inspeccionar cómo maneja el controlador los tamaños de búfer, la sincronización, las rutas de error y la retirada del dispositivo.

Las pruebas físicas son igualmente necesarias. Los emuladores y las pruebas de compilación pueden detectar algunos defectos, pero no pueden confirmar la calidad de la señal entre monitores y revisiones de placa. Un controlador diseñado en torno a un adaptador necesita más propietarios de hardware antes de ampliar sus afirmaciones de compatibilidad.

Por tanto, el estándar apropiado es la evidencia, no el origen. El código de kernel escrito por humanos puede contener errores graves. El código asistido por IA puede ser útil cuando se prueba su comportamiento, se puede revisar su fuente y sus afirmaciones siguen siendo limitadas.

Este proyecto cumple mejor que muchos experimentos privados la parte de transparencia de ese estándar. Su tarea pendiente es acumular validación independiente. Hasta entonces, debe seguir siendo una opción controlada para usuarios técnicamente preparados, no un controlador de sustitución general.

Lo que la historia de Hacker News debería hacer que los desarrolladores vigilen a continuación

Las tres señales siguientes son pruebas independientes de hardware, mantenimiento sostenido del kernel y evidencia de una vía upstream creíble.

La primera señal son las pruebas en tarjetas SE-DP750A-HDMI adicionales. Varios propietarios deben verificar el mismo transmisor, la configuración de memoria, el cableado GPIO, las resoluciones y el comportamiento de actualización. Resultados consistentes reforzarían la afirmación de que la implementación admite una familia de placas y no un único ejemplar.

Los fallos también serían valiosos. Una placa con la misma etiqueta comercial podría incluir una revisión o componente diferente. Registrar esas diferencias mejoraría la detección de dispositivos y evitaría suposiciones inseguras.

Los informes más útiles incluirán identificadores PCI exactos, marcas de los chips, modelos de monitor, versiones del kernel, modos y síntomas de fallo. Los comentarios generales de que el controlador “funciona” no pueden demostrar qué rutas recibieron pruebas significativas.

La segunda señal es el mantenimiento a lo largo de nuevas versiones de Linux. Las interfaces DRM evolucionan, y un módulo fuera del árbol puede dejar de compilar incluso cuando su lógica de hardware sigue siendo correcta. Las correcciones periódicas de compatibilidad demostrarían que el repositorio se ha convertido en un proyecto continuo y no en un experimento puntual.

El mantenimiento también incluye responder a informes de errores, revisar contribuciones y añadir pruebas de regresión. Un número creciente de estrellas no mide estas actividades. La calidad de los commits y la resolución de incidencias importan más que la visibilidad a corto plazo en Hacker News.

La tercera señal es el contacto con mantenedores DRM experimentados o una discusión upstream concreta. No es necesario que la integración upstream ocurra de inmediato, y el alcance actual, específico de una placa, puede complicar esa vía. Aun así, la revisión de especialistas revelaría debilidades arquitectónicas que las pruebas de hardware por sí solas no pueden detectar.

Una vía upstream probablemente requeriría separar el soporte conservador de los experimentos por encima de las especificaciones. Los modos EDID estándar, el control del transmisor HDMI, el seguimiento de daños y el scanout RGB565 seguro podrían ser más fáciles de evaluar que los modos opcionales de reloj elevado.

Incluso sin una propuesta para mainline, la revisión técnica puede mejorar el controlador externo. Los mantenedores podrían identificar ayudantes DRM existentes, suposiciones inseguras o mejores formas de modelar el puente y el conector. Esa retroalimentación fortalecería el código mientras preserva las funciones experimentales fuera de la ruta predeterminada.

Los desarrolladores también deberían vigilar si Silicon Motion o los proveedores de placas responden. Podrían publicar documentación aclaratoria, confirmar límites eléctricos o aportar detalles sobre diseños relacionados. El silencio dejaría las pruebas de la comunidad como la principal fuente de conocimiento operativo.

La lección más amplia va más allá de esta GPU. El hardware especializado suele llegar a un punto en el que la capacidad física permanece intacta, pero el software oficial ya no acompaña a los sistemas operativos actuales. El código comunitario puede reabrir esa capacidad cuando existen documentación y pruebas pacientes.

Sin embargo, la apertura no es un contrato automático de mantenimiento. Un repositorio público aún puede ser abandonado. Una licencia GPL permite a otros continuar el trabajo, pero solo si los colaboradores entienden el hardware y aceptan la responsabilidad de los cambios futuros.

El nuevo controlador GPU de código abierto triunfa en el primer paso más importante. Convierte la investigación de un usuario en código inspeccionable, configuración reproducible, mediciones documentadas y advertencias explícitas. Eso es sustancialmente más útil que un parche local sin documentar.

Su valor a largo plazo dependerá de que otras personas reproduzcan los resultados y mejoren la implementación. Si ocurre, el proyecto se convierte en un pequeño ejemplo de infraestructura compartida surgida de un problema de hardware personal.

Si no ocurre, el repositorio aún preserva conocimientos técnicos que de otro modo desaparecerían con una sola máquina. Los futuros propietarios pueden inspeccionar el código, comparar diseños de placas o reutilizar hallazgos individuales sin empezar desde cero.

Por eso esta historia de Hacker News merece atención incluso de desarrolladores que nunca tendrán un SM750. La pregunta relevante no es si este adaptador compite con el hardware gráfico actual. Claramente no lo hace.

La cuestión es si los dispositivos sin soporte deberían seguir limitados por el último software que sus proveedores distribuyeron. El código abierto ofrece otra respuesta, pero exige pruebas, revisión y límites claros por parte de todos los implicados.

Sigue los informes de hardware del repositorio, el trabajo de compatibilidad del kernel y la actividad de revisión durante los próximos meses. Esas señales mostrarán si el experimento con SM750 se convierte en un soporte duradero o sigue siendo un fascinante éxito en un único sistema. Cualquiera de los dos resultados revelará algo importante sobre cómo las comunidades abiertas preservan hardware útil.