asusctl y supergfxctl en Linux: guía completa para portátiles ASUS

Inicio » Windows » asusctl y supergfxctl en Linux: guía completa para portátiles ASUS

Si tienes un portátil ASUS ROG o TUF y usas Linux, tarde o temprano vas a oír hablar de asusctl, asusd y supergfxctl. Son las herramientas que permiten acercarse en Linux a lo que en Windows hace Armoury Crate: controlar ventiladores, perfiles de energía, teclado RGB, límite de carga de la batería, pantalla AniMe y el famoso MUX de la GPU.

El problema es que, aunque el ecosistema ASUS Linux ha madurado muchísimo, la cosa sigue teniendo truco: hay diferencias entre distribuciones como Arch, Fedora, Debian, Ubuntu o Linux Mint, hace falta un kernel relativamente moderno y en algunos casos hay que compilar o usar scripts de instalación específicos. Aquí vas a encontrar una explicación detallada y con un lenguaje lo más llano posible de qué es cada componente, qué hace y cómo se está usando en distintas distros, con ejemplos reales y advertencias importantes para no liarla.

Qué son asusd, asusctl y supergfxctl y para qué sirven

El corazón de todo el tinglado es asusd, el daemon del sistema. Es un servicio que se ejecuta en segundo plano y se encarga de hablar con el firmware y el EC (controlador embebido) de los portátiles ASUS para exponer funciones avanzadas de una forma segura, normalmente a través de una interfaz D-Bus. No es una simple colección de scripts: centraliza ajustes, guarda configuraciones y evita que el usuario haga cambios peligrosos directamente sobre el hardware.

Encima de ese daemon se sitúa asusctl, que es la interfaz CLI. Es el comando que tú lanzas en la terminal para cambiar la iluminación, los perfiles de potencia, los límites de carga de batería, las curvas de ventilador (si el portátil lo soporta) y varios parámetros de BIOS/efivars accesibles desde Linux. Piensa en asusctl como el “mando a distancia” de asusd.

Junto a ellos aparece otro protagonista clave para la parte gráfica: supergfxctl. Este demonio y su CLI asociada se encargan de gestionar los modos de GPU en portátiles con gráfica integrada (iGPU) y dedicada (dGPU): modos híbridos, solo integrada, solo dGPU, así como el comportamiento del MUX en los modelos que lo tienen. Su objetivo es ofrecer un cambio de GPU coherente y compatible con el resto de la pila gráfica de Linux, incluyendo Wayland.

El ecosistema lo completan dos piezas más orientadas al usuario: asusd-user, un daemon en espacio de usuario pensado para efectos personalizados (AniMe, per-key RGB, perfiles propios sin tocar la configuración base del sistema), y rog-control-center, una interfaz gráfica (GUI) empaquetada en algunos repositorios, sobre todo en Arch/AUR y repos personalizados.

Principales funciones que aporta asusd en un portátil ASUS

La funcionalidad de asusd no es trivial, cubre muchas áreas del hardware del portátil. Todas ellas se exponen a través de controladores especializados o “controllers” internos que se coordinan desde el daemon y se configuran mediante ficheros en /etc/asusd y archivos de usuario.

Una de las funciones más llamativas es el control de la pantalla AniMe Matrix, presente en algunos modelos ROG. asusd gestiona secuencias de arranque, apagado, suspensión y reanudación mediante el archivo /etc/asusd/anime.conf. Ahí se pueden definir animaciones para eventos como boot, wake o shutdown, así como la brillo global de la matriz con un valor flotante entre 0.0 y 1.0.

El siguiente bloque importante es el control del teclado y la iluminación RGB (Aura). asusd permite seleccionar modos de fábrica (Static, Breathe, Pulse, etc.), definir efectos por tecla o por zonas y manejar combinaciones complejas. Internamente se apoya en el crate rog-aura, que es el que define los modelos soportados (listados en /usr/share/asusd/aura_support.ron) y cómo se mapea cada layout físico a los efectos.

Prácticamente todos los portátiles modernos de la marca incluyen también algún tipo de limitación de carga de la batería. Desde asusd se puede fijar un porcentaje máximo de carga (por ejemplo, 60, 75 u 80 %) mediante la opción bat_charge_limit en /etc/asusd/asusd.conf. Esto ayuda a alargar la vida útil de la batería si el portátil se pasa la mayor parte del tiempo enchufado.

Otra parte que suele interesar mucho es el control de BIOS/efivars accesibles desde Linux. asusd expone, por ejemplo, la activación o desactivación del sonido de POST o la configuración del MUX para forzar la dGPU como GPU principal, replicando algunas de las opciones que normalmente solo verías en Armoury Crate o en la propia BIOS.

Por último, pero fundamental, está el módulo de perfiles de energía (platform_profile). Con el soporte adecuado en el kernel y con power-profiles-daemon actualizado (mínimo la versión 0.10.0), asusctl puede conmutar entre perfiles tipo Quiet, Balanced y Performance, integrándose con el driver de plataforma del kernel. Esto permite ajustar consumo, rendimiento y ruidos del ventilador de forma centralizada (guía avanzada de ryzenadj).

Curvas de ventilador, perfiles y fan keys

Una de las cosas más buscadas por usuarios avanzados es la posibilidad de definir curvas de ventilador personalizadas. asusd puede hacerlo en portátiles que lo soportan, siempre que el kernel incluya los parches adecuados (a partir de la serie 5.17 el soporte está integrado en el árbol principal). El fichero de configuración /etc/asusd/profile.conf se autocompleta la primera vez con los valores por defecto del EC.

El formato de las curvas es relativamente flexible, pero siempre sigue el mismo patrón: parejas de temperatura y porcentaje de ventilador ordenadas de menor a mayor temperatura. Se admiten varias sintaxis, desde 30c:0%,40c:5%… hasta formatos sin el sufijo c o con separación por espacios. Lo importante es mantener el orden y cubrir bien el rango de funcionamiento para evitar saltos bruscos. Muchos usuarios complementan esto con herramientas externas, por ejemplo usar fan control para dominar los ventiladores, cuando necesitan ajustes más finos.

Una vez definidas las curvas, muchos usuarios asocian la clásica tecla Fn+F5 (la de los ventiladores) al comando asusctl profile -n, que pasa cíclicamente por los tres perfiles disponibles (Quiet, Balanced, Performance). También se pueden crear atajos para cambiar de curva en función del perfil, o combinarlo con scripts de ahorro de energía cuando se está en batería.

En la parte de la iluminación, asusctl permite conmutar entre modos RGB predefinidos o personalizados mediante órdenes como asusctl led-mode -n (siguiente modo) o asusctl led-mode -p (modo anterior), que muchos usuarios vinculan a las teclas específicas de Aura si el teclado las incluye.

asusd-user, efectos personalizados y configuración de usuario

Mientras que asusd gestiona la configuración global del sistema, asusd-user se centra en el ámbito del usuario. Es un daemon que corre en el espacio de usuario y que está pensado para que cada persona pueda definir sus propios efectos de teclado y AniMe, sin reescribir ni interferir con la configuración base del sistema ubicada en /etc/asusd.

La configuración de asusd-user se guarda en ~/.config/rog/rog-user.cfg. La primera vez que se lanza el daemon, se generan archivos de ejemplo que sirven como plantilla. Uno de los campos clave es «active_aura», que indica qué fichero de configuración de efectos RGB se está usando, y otro es «active_anime», que señala el perfil de AniMe activo.

Los efectos Aura se describen normalmente en archivos en formato RON, donde se define un nombre y una lista de efectos aplicados a teclas o zonas concretas, con parámetros como colores de inicio, velocidad del efecto, si el teclado es per-key o por zonas, etc. Para teclados multizona se pueden usar descriptores como SingleZone, ZonedKbLeft, ZonedKbLeftMid, ZonedKbRight, así como zonas de lightbar ubicadas en los laterales del portátil.

En el caso de AniMe, la configuración típica es un archivo en formato JSON donde se define un nombre y un array llamado «anime». Cada elemento de este array puede ser un AsusAnimation, AsusImage, ImageAnimation, Image o Pause. Con esto se consiguen secuencias encadenadas que muestran GIFs oficiales de ASUS, PNGs personalizados adaptados a la matriz, GIFs de cualquier tamaño, imágenes estáticas o pausas temporales entre efectos.

Cada objeto de animación acepta parámetros como archivo, escala, ángulo, traslación, tiempo (que puede ser un valor fijo, un número de ciclos, infinito o un patrón de fade in/out) y brillo. Con estos ajustes se pueden crear configuraciones muy elaboradas que reaccionen a eventos del sistema o simplemente decoren la tapa del portátil con animaciones personalizadas.

Uso básico de asusctl desde la terminal

En el día a día, la interacción directa del usuario suele ser a través del comando asusctl. Ejecutarlo sin argumentos muestra las opciones principales soportadas por el portátil, filtradas en función del nivel de soporte detectado por el daemon (no todos los modelos tienen AniMe, ni todos soportan curvas custom, etc.).

asusctl organiza sus funciones en categorías y subcomandos. Por ejemplo, asusctl bios lista las opciones relacionadas con la BIOS accesibles desde Linux; asusctl profile se centra en los perfiles de energía; asusctl battery en el control de carga, y así sucesivamente. Cada comando y subcomando ofrece su propio –help para detallar argumentos y ejemplos.

Una particularidad interesante de la interfaz es el uso de banderas en mayúsculas y minúsculas para distinguir entre consulta y cambio de estado. Por ejemplo, asusctl bios -o devuelve el estado actual del overdrive de panel, mientras que asusctl bios -O true lo habilita. Este patrón se repite en varias secciones y ahorra tener que recordar comandos distintos para leer o escribir.

Para ver qué es lo que realmente soporta tu equipo, el comando clave es asusctl info –show-supported. Esto te mostrará si hay soporte de AniMe, tipos de iluminación, perfiles de ventilador, MUX, etc. y evitará que pierdas tiempo intentando activar funciones que tu modelo simplemente no incluye o para las que el soporte aún no se ha implementado en Linux.

Control de batería, RGB y perfiles de energía con asusctl

En el apartado de batería, asusctl ofrece un subcomando específico para establecer el límite de carga en porcentaje. La sintaxis típica es algo como asusctl battery limit 80, donde el valor ha de estar entre 20 y 100. Valores intermedios como 60 o 75 suelen recomendarse para quienes dejan el portátil enchufado gran parte del tiempo.

La parte de iluminación se maneja mediante el subcomando aura. Con asusctl aura –next-mode y asusctl aura –prev-mode se puede rotar entre los distintos modos disponibles sin tener que abrir una GUI, lo que es perfecto para atajos de teclado. En portátiles con soporte de per-key RGB, estos modos pueden ser tanto efectos predefinidos como configuraciones personalizadas definidas en los archivos de rog-user.cfg y perfiles Aura.

Los perfiles de energía se gestionan con asusctl profile. Existen tres modos estándar: Quiet, Balanced y Performance. Se puede seleccionar uno concreto con asusctl profile set perfil, o ir ciclando entre ellos con asusctl profile next. Además, es posible fijar un perfil predeterminado en el archivo /etc/asusd/asusd.ron para que se aplique automáticamente en cada arranque.

En la parte de BIOS/Armoury, para quien tenga panel con overdrive compatible, se ofrece la posibilidad de controlar el parámetro panel_overdrive mediante el subcomando armoury, con una sintaxis del estilo asusctl armoury set panel_overdrive 1 para activarlo y 0 para desactivarlo, siempre que el soporte esté implementado para tu modelo.

Gestión de la GPU y MUX con supergfxctl

supergfxctl es la pieza pensada para manejar los modos de GPU en portátiles híbridos y la conmutación de MUX en los modelos que lo incluyen. La idea es ofrecer un cambio de modo lo más seguro posible, sin romper el gestor de pantalla incluso cuando hay MUX de por medio.

El modo de uso típico pasa por comandos como supergfxctl -m AsusMuxDgpu para forzar la GPU dedicada (modo MUX dGPU only) y posteriormente reiniciar, o supergfxctl -m hybrid para volver al modo híbrido tipo Optimus. Estos comandos coordinan el cambio de GPUs y el comportamiento de la salida de vídeo para que el sistema no se quede sin pantalla al arrancar.

En entornos Wayland, supergfxctl suele trabajar correctamente, pero en el caso concreto de NVIDIA hay que tener en cuenta que el soporte Wayland aún tiene aristas. Se recomienda revisar la documentación de NVIDIA sobre configuración en Wayland antes de hacer cambios radicales, especialmente si se está usando un compositor concreto o extensiones avanzadas.

Una advertencia importante de los desarrolladores es evitar mezclar supergfxctl con otros gestores de Optimus o scripts de MUX, porque estos pueden no entender bien el estado real del MUX de ASUS y provocar situaciones en las que el servidor gráfico no arranca o se queda en negro después de reiniciar.

Instalación en Arch Linux y derivadas

En el ecosistema Arch, la situación es bastante favorable porque asusctl y asusd están pensados originalmente con soporte oficial para Arch y Fedora. En Arch, la vía habitual es instalar el paquete asusctl desde AUR, ya sea de forma directa o a través de repositorios personalizados mantenidos por la comunidad ASUS Linux.

La instalación suele arrastrar también las dependencias necesarias y en muchos casos integra de serie rog-control-center como interfaz gráfica. Además, algunas funcionalidades avanzadas se apoyan en kernels personalizados para obtener soporte completo de perfiles de ventilador o MUX en modelos especialmente delicados, aunque muchas características ya están presentes en el kernel estándar de Arch.

La configuración resultante deja los archivos de asusd en /etc/asusd, los perfiles y recursos de Aura y AniMe en /usr/share/asusd y el archivo de usuario en ~/.config/rog/rog-user.cfg. A partir de ahí, se habilitan los servicios systemd asusd, supergfxd y, opcionalmente, asusd-user a nivel de usuario para activar los efectos personalizados.

Para quienes prefieran no compilar desde AUR, algunos repositorios externos proporcionan binarios ya construidos, junto con kernels personalizados, aunque siempre conviene revisar qué versión exacta de asusctl, asusd y supergfxctl incluyen y si se ajustan al hardware concreto del portátil.

Instalación manual en Debian, Ubuntu y derivadas (ejemplo KDE Neon)

En Debian suele existir un cierto nivel de soporte no oficial, pero el gran quebradero de cabeza históricamente ha sido Ubuntu y sus derivados (KDE Neon, ZorinOS, Linux Mint, etc.), donde durante mucho tiempo prácticamente se consideraba «no soportado» de forma oficial. Aun así, hay usuarios que han documentado procedimientos para compilar e instalar todo desde código fuente.

Un ejemplo práctico es el de un usuario con KDE Neon (basado en Ubuntu 22.04) que quería apagar o controlar los ventiladores cuando usaba el portátil en batería y cambiar de forma cómoda al modo Eco aprovechando supergfxctl y asusctl. El primer paso fue comprobar la versión del kernel con uname -r (en su caso 6.8.0-51-generic) y asegurarse de tener un kernel suficientemente moderno.

Luego instaló una lista bastante amplia de dependencias de compilación y librerías de sistema, incluyendo build-essential, git, cmake, pkg-config, libpci-dev, libsysfs-dev, libudev-dev, libboost-dev, libgtk-3-dev, libglib2.0-dev, libseat-dev, clang y cargo. Llegar al conjunto correcto le llevó tiempo porque muchas guías estaban incompletas, pero con esa combinación se cubrió prácticamente todo lo necesario para compilar supergfxctl y asusctl.

Como preparación general, se ejecutó un sudo apt update && sudo apt upgrade -y para tener el sistema y los drivers al día. En equipos con NVIDIA, el siguiente paso fue instalar los controladores recomendados mediante ubuntu-drivers devices para ver cuál se marcaba como recommended y luego instalar, por ejemplo, nvidia-driver-560 junto con nvidia-settings, reiniciando después para cargar el módulo propietario correctamente.

Para verificar que tanto la gráfica integrada (normalmente AMD o Intel) como la NVIDIA estaban operativas, se utilizó el comando lspci -k | grep -EA3 «VGA|3D» (ver comandos de Linux para obtener información del hardware), que listó dos entradas: una para ASUS/AMD y otra para NVIDIA. Esto confirmó que el entorno era apto para que supergfxctl gestionara los distintos modos de GPU.

Problemas típicos de compilación y libseat/PKG_CONFIG_PATH

Durante el proceso de compilación sobre Ubuntu/KDE Neon surgió un problema concreto con libseat y pkg-config. El sistema no encontraba el archivo libseat.pc, necesario para que pkg-config pueda localizar la librería y sus flags de compilación. La solución pasó por localizar primero el archivo con find /usr -name libseat.pc.

Una vez identificada la ruta, se ajustó la variable de entorno PKG_CONFIG_PATH para incluir el directorio correcto, algo parecido a export PKG_CONFIG_PATH=/usr/lib/x86_64-linux-gnu/pkgconfig:$PKG_CONFIG_PATH. Este paso fue fundamental para que la compilación de supergfxctl y asusctl detectara correctamente libseat y pudiera enlazar con las librerías adecuadas.

A partir de ahí, el usuario creó un directorio de trabajo ~/Asus, entró en él, clonó el repositorio supergfxctl desde GitLab, y lanzó la compilación con make seguida de sudo make install. El resultado fue la instalación del binario supergfxctl y su daemon asociado supergfxd en /usr/local/bin y los directorios estándar de servicios.

Para integrar supergfxctl con systemd, se habilitó y arrancó el servicio con sudo systemctl enable supergfxd y sudo systemctl start supergfxd, comprobando a continuación con systemctl status supergfxd que aparecía en estado activo (running). Este paso asegura que el demonio se inicia automáticamente en cada arranque y que siempre está disponible para procesar cambios de modo de GPU.

En algunos casos, además del servicio instalado por defecto, se creó manualmente un archivo de unidad systemd adicional supergfxctl.service en /etc/systemd/system, especificando la ruta a /usr/local/bin/supergfxctl, el usuario root y el directorio de trabajo. Después de recargar los daemons con systemctl daemon-reload, se volvió a habilitar y arrancar el servicio para garantizar que todo arrancara de forma persistente.

Compilación de asusctl y reglas udev personalizadas

Una vez resuelta la parte de supergfxctl, el siguiente paso fue clonar el repositorio de asusctl en el mismo directorio ~/Asus, compilar con make y completar la instalación con sudo make install. Con esto se instalaron el binario asusctl, el daemon asusd y el resto de componentes necesarios para controlar el hardware específico de ASUS.

Para que supergfxctl y asusctl pudieran acceder correctamente al hardware de la GPU y dispositivos ASUS, se configuraron reglas udev personalizadas en /etc/udev/rules.d. Primero se identificaron los IDs de proveedor y dispositivo mediante lspci -nn, anotando entradas del estilo para NVIDIA, AMD y ASUS.

Con esa información se creó un archivo de reglas 99-supergfxctl.rules con líneas que asignaban permisos MODE=»0666″ a los dispositivos PCI coincidentes con esos IDs, por ejemplo vendor 0x1043 para ASUS, 0x1002 para AMD y 0x10de para NVIDIA, sustituyendo los device_id por los específicos de cada portátil. El objetivo era que los daemons pudieran interactuar con los dispositivos sin bloquearse por falta de permisos.

Tras editar el archivo de reglas, se recargó la configuración de udev con sudo udevadm control –reload-rules y se comprobó, por ejemplo, con ls -l /dev | grep gfx si aparecían los dispositivos previstos. Esta parte es delicada, porque un error de escritura en los IDs puede llevar a que las reglas no se apliquen o a que se otorguen permisos donde no corresponde.

Una vez todo en su sitio, se pudo empezar a usar asusctl para controlar ventiladores, RGB y perfiles siguiendo las instrucciones recogidas en la documentación oficial del proyecto en GitLab: comandos como asusctl fan -s 3 para fijar la velocidad del ventilador en un nivel concreto o asusctl rgb -c 4 para establecer un color o modo de iluminación determinado.

Scripts de instalación automatizada en Linux Mint

Para quienes usan Linux Mint (por ejemplo, la versión 22.3) y no quieren pelearse con la compilación manual, la comunidad ha desarrollado scripts de instalación automatizados específicamente pensados para portátiles ASUS ROG/TUF en esta distro. Estos scripts se encargan de prácticamente todo el flujo: desde dependencias hasta servicios systemd.

Entre sus funciones destacan la instalación de las últimas versiones de asusctl y supergfxctl, la configuración de actualizaciones de firmware mediante fwupd para garantizar la máxima compatibilidad con el hardware, la comprobación de compatibilidad de kernel, incluyendo la posibilidad de instalar kernels mainline como opción avanzada, y la preparación de controladores NVIDIA bloqueando nouveau cuando es necesario.

Los requisitos que suelen pedir son sencillos: tener Linux Mint 22.3 (en cualquiera de sus sabores Cinnamon, MATE o Xfce), un portátil ASUS ROG/TUF compatible, conexión a Internet para descargar dependencias y privilegios sudo para modificar la configuración del sistema. El propio script se encarga de revisar si el kernel cumple una versión mínima recomendada (por defecto 6.14 HWE en Mint) y ofrece la instalación de uno más nuevo si hace falta.

Dentro del paquete de instalación, además de asusctl y supergfxctl, se incluyen el rog-control-center como GUI, el toolchain de Rust mediante rustup cuando se requiere compilar alguna parte, un conjunto amplio de dependencias de desarrollo y actualizaciones de linux-firmware para cubrir la mayor cantidad de hardware posible.

La integración con el sistema abarca servicios systemd (asusd, supergfxd y asusd-user), reglas udev para detección de hardware y permisos, configuración de D-Bus para la comunicación entre procesos, y, si se elige, la desactivación de nouveau para favorecer el correcto funcionamiento de la GPU NVIDIA con los drivers propietarios en escenarios de conmutación de GPU.

El propio script suele incluir también una rutina de desinstalación segura que elimina binarios, servicios, reglas udev, directorios de compilación y configuraciones opcionales (como el blacklist de nouveau), sin tocar datos personales ni configuraciones de usuario fuera del ámbito de las herramientas ASUS.

Dudas frecuentes de usuarios novatos (por ejemplo en ZorinOS)

No todos los usuarios se sienten cómodos compilando desde cero o ejecutando scripts complejos de instalación. En distribuciones como ZorinOS, que se basan en Ubuntu pero están orientadas a usuarios nuevos, es bastante habitual que alguien intente seguir las instrucciones oficiales de GitHub para asusctl, instale paquetes pensados para Debian y termine con un «comando no encontrado» o sin aplicaciones visibles.

En varios hilos de la comunidad se ha desaconsejado forzar este tipo de instalación en ZorinOS cuando no se tiene experiencia, porque el margen de error es alto y, si algo sale mal, se puede acabar con el subsistema gráfico tocado, servicios que no inician o conflictos con los drivers existentes. Para alguien que apenas está dando sus primeros pasos con la terminal, lo más prudente suele ser esperar a soporte mejor integrado o usar distribuciones donde asusctl tenga soporte oficial o al menos bien documentado.

La recomendación general para principiantes en este tipo de distros es optar por soluciones simples como comprobar primero en los repositorios de ZorinOS si existe algún paquete oficial o PPA confiable, y, en caso contrario, valorar seriamente si merece la pena el riesgo de compilar y manipular servicios de bajo nivel solo por tener funciones avanzadas de RGB o ventilador.

En cualquier caso, la experiencia de otros usuarios muestra que, aunque se pueda llegar a hacer funcionar asusctl y supergfxctl en sistemas basados en Ubuntu sin soporte directo, el proceso requiere paciencia, lectura atenta de la documentación y capacidad para diagnosticar fallos, especialmente en lo que se refiere a servicios systemd, permisos de dispositivos y compatibilidad de kernel.

A medida que el ecosistema ASUS Linux sigue madurando, la tendencia es a ver un soporte cada vez más pulido en más distribuciones, con paquetes oficiales o scripts bien mantenidos que faciliten la vida al usuario medio sin renunciar a las funciones avanzadas que estos portátiles pueden ofrecer bajo Linux.

Todo este conjunto de herramientas (asusd, asusctl, asusd-user, supergfxctl y rog-control-center) forma ya un ecosistema bastante sólido que permite, con algo de trabajo inicial, acercar la experiencia en Linux a la de Windows en portátiles ASUS ROG/TUF, desde los ventiladores y el consumo hasta la iluminación más vistosa y las animaciones de la tapa, siempre y cuando se respeten las limitaciones de cada distro y se mantenga el sistema actualizado y bien configurado.