# MSI Mystic Light en Linux, un driver que mide voltajes > Un desarrollador escribe el driver de MSI Mystic Light para Linux y descubre que el controlador de RGB también mide voltajes que nadie monitoriza. > Por José Maldonado · Tecnología · 2026-11-11 MSI vende sus placas AM5 más recientes con Mystic Light, un sistema de iluminación RGB que solo se controla desde Windows con MSI Center. Este fin de semana, un desarrollador independiente, Tomasz Bojanowski, envió a la lista del kernel una serie de parches para llevar ese controlador a Linux. Lo interesante no es el color de las luces: es que el microcontrolador USB que gestiona el RGB resulta ser también el único componente de la placa que mide tres raíles de voltaje que el chip Super I/O ignora. El hallazgo convierte un proyecto de aficionado en algo con utilidad real para cualquiera que diagnostique una placa MSI con AMD 800. Los raíles en cuestión son CPU 1P8, CHIP Core y VDD MISC, y en las placas probadas no están monitorizados por el Super I/O, que es el chip al que tradicionalmente se conectan los sensores de voltaje y temperatura del sistema. Si el driver entra en el kernel, \`lm-sensors\` y las herramientas de monitorización podrán leerlos por primera vez. La noticia tiene dos lecturas y conviene no mezclarlas. La primera es la de siempre, la del hardware de consumo que depende de software propietario para funciones básicas. La segunda es menos obvia: en placas modernas, parte de la telemetría se ha desplazado a microcontroladores que el sistema operativo no conoce, y recuperarla exige ingeniería inversa sobre protocolos que nadie documenta. El RGB fue la puerta de entrada, no el objetivo del trabajo. ## Un microcontrolador con más funciones de las que anuncia la caja El controlador de Mystic Light se comunica por USB y en Windows sirve para poco más que cambiar colores y efectos. En el envío al kernel, el foco está en exponer los sensores de voltaje que ese mismo chip recoge. Es una decisión de alcance razonable: un driver que empieza leyendo registros de telemetría es más fácil de revisar y de aceptar que uno que escribe comandos en el firmware de iluminación de cada placa. Los [parches de Bojanowski para MSI Mystic Light](https://lore.kernel.org/lkml/20261107082821.8257-1-tomasz@bojanowski.me/) se publicaron este fin de semana y todavía están en fase de revisión. La comunidad del kernel suele tardar meses en aceptar un driver nuevo, y más si toca hardware de consumo con documentación escasa. Nada garantiza que llegue al árbol principal, aunque el hecho de que el autor haya encontrado una función útil más allá del RGB mejora sus posibilidades. Hay un detalle que explica por qué esto importa en un servidor doméstico o en un puesto de trabajo técnico. Cuando un equipo arranca mal, con cuelgues aleatorios o reinicios, la primera pregunta es siempre la misma: ¿está la alimentación donde debe? Sin sensores, la respuesta exige un polímetro y tiempo. Con ellos, basta un comando. ## La ingeniería inversa como trabajo de fin de semana El camino hasta aquí no fue corto. Otro desarrollador, que firma con el alias Picachuchu69, publicó hace días un script en Python que controla el RGB de las placas B860 y X870 desde Linux sin pasar por Windows. Lo hizo capturando el tráfico USB real de MSI Center dentro de una máquina virtual con Windows y analizándolo con usbmon y Wireshark, y documentó el protocolo completo: informe HID de 290 bytes, modo en el desplazamiento 273, paleta de cuatro colores a continuación, un byte de parámetros empaquetados con velocidad, brillo, dirección y animación. Ese trabajo es el que hace posible el driver. La documentación del protocolo, publicada en un repositorio abierto, permite que otros escriban código en C para el kernel en lugar de repetir la captura. También revela un detalle de diseño que dice mucho de la industria: el modo de temperatura de MSI Center no es firmware, es software que envía comandos estáticos calculando el color a partir de la lectura de los sensores. La placa no piensa, la aplicación decora. La historia encaja con una tendencia que se repite en el hardware de consumo. El fabricante usa un microcontrolador barato para varias funciones, documenta solo la que vende y deja el resto en manos de la comunidad. Cuando alguien mira dentro, encuentra capacidades que nunca se anunciaron y que a veces son más valiosas que la función original. Hay un precedente que ayuda a calibrar el valor de lo conseguido. Los sensores de las placas suelen llegar al sistema operativo a través del chip Super I/O y de los controladores que la comunidad mantiene en el proyecto lm-sensors. ## ¿Qué falta para que sirva de algo? Un driver en revisión no es un driver disponible. Los usuarios de distribuciones estables tardarán en verlo, y quienes lo quieran antes tendrán que compilar el kernel o aplicar los parches a mano, algo que en una placa de trabajo no es una decisión trivial. Tampoco está claro qué modelos quedarán cubiertos: el trabajo se hizo sobre placas con chipset AMD 800 y el soporte del controlador puede variar entre revisiones del mismo modelo y de su circuitería de gestión. El mismo trabajo comunitario que llevó [ROCm a FreeBSD](https://observatorioblockchain.com/tecnologia/freebsd-integra-software-rocm-amd-hpc-ia/) se aplica aquí, solo que el premio es menor. La revisión del kernel es lenta por diseño. Cada envío pasa por mantenedores que leen el código, preguntan por los casos raros y exigen que el driver no rompa nada en placas parecidas. Un envío de hardware de consumo sin documentación del fabricante suele necesitar varias iteraciones antes de recibir el visto bueno. El RGB, curiosamente, es lo último que llegará. El envío actual se centra en los voltajes, y el control de iluminación necesitaría una segunda iteración de parches que todavía no existe. Quien esperaba apagar las luces de su torre desde Linux tendrá que seguir esperando o recurrir al script en Python, que ya funciona aunque escriba directamente en el dispositivo HID. Para el resto, la utilidad inmediata es más sobria. Un servidor casero con una placa MSI puede ganar tres sensores que hasta ahora no tenía, y eso mejora el diagnóstico de fallos de alimentación sin comprar hardware adicional. En un equipo que pasa años encendido, saber si el raíl de 1,8 voltios se está desviando es información que vale más que cualquier efecto de respiración. El camino hasta las herramientas de monitorización habituales todavía tiene pasos. Un driver en el árbol del kernel no expone los sensores por sí solo: hace falta que el proyecto lm-sensors añada la definición del chip y que las distribuciones actualicen el paquete para que un usuario pueda leer los valores con el comando sensors, algo que suele tardar una o dos versiones. Cuando un raíl no llega al sistema operativo por la vía habitual, la única forma de leerlo es encontrar el componente que sí lo mide y escribir código para hablar con él. ## El RGB como efecto secundario El episodio deja una lección sobre cómo se escribe el soporte de hardware libre. Los fabricantes no suelen documentar lo que no consideran una característica, y los desarrolladores encuentran valor donde no lo había. Un chip que existe para vender luces acaba siendo una fuente de telemetría porque alguien se tomó la molestia de capturar su tráfico y publicarlo. Son mejoras que llegan tarde y por la puerta de atrás, como [las columnas Miller de KDE Dolphin, que volvieron quince años después](https://observatorioblockchain.com/tecnologia/kde-dolphin-vista-columnas-15-anos/). Falta ver si el driver entra en el kernel y si MSI responde con documentación o con silencio. Las dos cosas han pasado antes en este sector, y la diferencia suele medirse en años. Mientras tanto, el trabajo está en la lista pública, revisable línea por línea, que es exactamente donde debe estar.