Controladores Linux: guía completa para entender e instalar drivers

Portada » General » Controladores Linux: guía completa para entender e instalar drivers

Si vienes de Windows es muy fácil liarse con el tema de los drivers en Linux. Allí estás acostumbrado a abrir el navegador, buscar “drivers”, bajar el ejecutable del fabricante y rezar para que no venga con bloatware. En Linux el enfoque es totalmente distinto: casi todo se gestiona desde el propio sistema, mediante el kernel y los repositorios de la distribución, y eso hace que muchos usuarios nuevos se pregunten si de verdad necesitan “instalar controladores”.

A día de hoy, en 2025, el ecosistema ha cambiado una barbaridad respecto a hace años. La época en la que para instalar un driver en Linux tenías que ser medio ingeniero y pasarte tardes enteras buceando en foros está prácticamente superada en equipos modernos. Aun así, merece la pena entender bien cómo funciona todo: qué tipos de controladores hay, cuándo conviene usar los privativos, cómo se instalan en las principales distribuciones y qué hacer en casos especiales, como compilar tu propio módulo para un dispositivo muy específico.

Cómo funciona la gestión de controladores en Linux

Lo primero que hay que tener claro es que en Linux no se plantea la instalación de drivers como en Windows. En lugar de descargar ejecutables sueltos de la web de cada fabricante, la mayoría de controladores se integran en el kernel o se distribuyen como paquetes a través de los repositorios oficiales de la distribución (Ubuntu, Debian, Fedora, Arch, etc.).

Esto tiene una consecuencia clave: en la inmensa mayoría de casos, al instalar una distro actual, el propio sistema ya trae todo lo necesario para que el hardware básico funcione sin que tengas que hacer absolutamente nada. Tarjeta de red, controladora SATA o NVMe, sonido integrado, USB, gráficos integrados… todo suele ir “de fábrica”.

En Linux encontramos dos grandes familias de controladores: por un lado los drivers de código abierto, que pueden ser auditados, mejorados y mantenidos por la comunidad; y por otro los drivers propietarios o privativos, creados y mantenidos únicamente por la empresa fabricante, cuyo código no se puede revisar ni modificar.

Además, muchas distribuciones diferencian entre repositorios “libres” y repositorios que incluyen software propietario. En algunas (como Fedora) los controladores no libres no vienen activados por defecto; en otras, como Ubuntu o Linux Mint, se facilitan mediante herramientas gráficas como “Controladores adicionales”, que hacen muy sencillo activar un driver privativo cuando realmente aporta ventajas.

Tipos de controladores en Linux: kernel, abiertos y privativos

En el corazón de cualquier sistema Linux está el kernel, que no es más que el núcleo del sistema operativo. Es la pieza que se encarga de hablar con el hardware, gestionar la memoria, repartir tiempo de CPU entre procesos, manejar las llamadas al sistema y coordinar los controladores de los distintos dispositivos.

Una parte enorme de ese kernel está formada precisamente por módulos de driver. Ahí encontramos soporte para una cantidad abrumadora de hardware: desde dispositivos muy actuales hasta componentes antiguos que siguen siendo útiles. El objetivo es que, cuando instalas una distro moderna en un equipo estándar, el sistema arranque y detecte prácticamente todo a la primera.

Estos drivers “del kernel” suelen ser de código abierto y se actualizan simplemente instalando una nueva versión del kernel desde los repositorios de tu distro. No los “instalas a mano” como tal: se activan automáticamente cuando el kernel detecta el dispositivo correspondiente (por ejemplo, al conectar un USB o durante el arranque).

Junto a ellos están los controladores de código abierto desarrollados o mantenidos por la comunidad o por el propio fabricante, que también se distribuyen como paquetes de la distro. En la práctica, para el usuario es lo mismo: se instalan desde el repositorio con el gestor de paquetes y se integran en el sistema como cualquier otro software.

Por último, encontramos los drivers privativos, donde el código sólo lo controla la empresa. Se dan sobre todo en sectores donde el fabricante quiere exprimir al máximo sus productos o proteger su propiedad intelectual: tarjetas gráficas (NVIDIA, algunos modelos AMD), determinados chipsets WiFi, controladores de audio avanzados, impresoras con funcionalidades especiales, o hardware industrial y de instrumentación (como equipos de medida de National Instruments, por ejemplo).

Cuándo necesitas realmente instalar drivers en Linux

En equipos relativamente modernos, con distros actuales, lo normal es que en más del 95% de las ocasiones no tengas que instalar manualmente nada. El kernel ya trae soporte para la mayoría de controladoras, tarjetas de red, audio integrado, puertos USB, almacenamiento y mucha parte del hardware gráfico.

Ahora bien, hay varios tipos de dispositivos donde sí suele haber diferencia notable entre usar el driver abierto de serie y instalar el controlador propietario del fabricante:

• Tarjetas gráficas dedicadas: especialmente en el caso de NVIDIA, si quieres jugar en serio, usar aplicaciones 3D exigentes, CUDA, IA o render, el driver privativo suele ofrecer hasta un 70-80 % más de rendimiento respecto al controlador abierto.
• Tarjetas de red (Ethernet y, sobre todo, WiFi): muchas funcionan perfectamente con los drivers del kernel, pero ciertos chipsets concretos (Broadcom, algunos Realtek, etc.) cuentan con controladores propietarios que mejoran estabilidad, velocidad o compatibilidad.
• Tarjetas de sonido de alta gama: si usas interfaces de audio profesionales o tarjetas dedicadas de alta fidelidad, a veces el driver específico del fabricante permite aprovechar funciones que con el driver genérico no están disponibles.
• Impresoras y escáneres: gracias a CUPS, Linux trae un montón de drivers genéricos que cubren la mayoría de modelos, pero puede ocurrir que una impresora concreta requiera el paquete oficial del fabricante para funcionar al 100%.
• Periféricos “gaming” (ratones y teclados avanzados): suelen funcionar como dispositivos estándar, pero las funciones extra (iluminación RGB, macros complejas, perfiles DPI, etc.) a menudo dependen de software específico que en Linux no siempre existe o está muy limitado.

En resumen, en un PC moderno de uso general el sistema ya lo deja todo casi listo. Sólo tiene sentido complicarse con drivers externos cuando necesitas rendimiento máximo o funcionalidades avanzadas de un hardware concreto.

Instalar drivers en Linux mediante interfaz gráfica

Las distribuciones han mejorado muchísimo en ofrecer un método sencillo y visual para gestionar controladores. En Ubuntu y derivadas (Linux Mint, Zorin OS, etc.) existe una herramienta integrada que cumple un papel parecido al “Administrador de dispositivos” de Windows, aunque con filosofía distinta: en lugar de buscar manualmente ejecutables, el sistema te propone drivers empaquetados y probados.

En Ubuntu, por ejemplo, puedes abrir el menú de aplicaciones, buscar “Software y actualizaciones” y entrar en la pestaña “Controladores adicionales”. Ahí verás los componentes detectados que disponen de drivers privativos opcionales (gráfica NVIDIA, ciertos adaptadores WiFi, etc.) y podrás elegir entre el controlador de código abierto o uno o varios controladores propietarios recomendados.

La gracia de este sistema es que los drivers se instalan desde los repositorios oficiales, con actualizaciones gestionadas por el gestor de paquetes. No hay que ir a la web del fabricante, ni pelearse con instaladores dudosos ni cargar tu sistema de software de terceros que se queda en segundo plano ocupando recursos.

En otras distros sucede algo similar: GNOME Software, KDE Discover u otros centros de aplicaciones integran secciones para instalar controladores adicionales cuando están disponibles, siempre tomando como base los repositorios de la distribución o repositorios complementarios confiables.

En el caso de impresoras, por ejemplo, muchas veces basta con conectarla por USB o ponerla en la red para que CUPS detecte el modelo y el sistema descargue e instale el driver apropiado sin intervención del usuario. Paradójicamente, en este sentido Linux suele ofrecer una experiencia más plug & play real que el propio Windows moderno.

Instalar y gestionar controladores desde la terminal

Para usuarios algo más avanzados, o cuando la interfaz gráfica no resuelve la situación, la línea de comandos sigue siendo la navaja suiza en Linux. Eso sí, si no tienes mucha experiencia conviene ir con cuidado, porque un comando mal ejecutado puede romper la interfaz gráfica o dejar el sistema inestable.

Como primera herramienta de diagnóstico, suelen utilizarse comandos como lspci (para dispositivos PCI, como gráficas o tarjetas de red) y lsusb (para dispositivos USB). Con ellos identificas el hardware exacto que tienes instalado. Por ejemplo, puedes filtrar la salida con grep para localizar un fabricante: lspci | grep -i nvidia o lsusb | grep -i broadcom.

Otro clásico es dmesg, que muestra los mensajes del kernel. Sirve para comprobar si el sistema reconoce el dispositivo y qué módulo intenta usar. Combinado con grep puedes localizar mensajes relacionados con un componente concreto: dmesg | grep -i wifi o dmesg | grep firmware.

Para ver qué módulos de driver están cargados en el kernel se usa lsmod. Y si sabes el nombre del módulo que te interesa, se puede intentar cargarlo manualmente con modprobe, por ejemplo: sudo modprobe nombre_del_modulo. Si el módulo existe en /lib/modules/$(uname -r) y no hay conflictos, se añadirá al kernel en caliente.

Cuando necesitas añadir un repositorio específico de drivers (por ejemplo, el PPA de drivers gráficos en Ubuntu), se recurre a herramientas como add-apt-repository y después se actualiza la información de paquetes con apt update. Si necesitas una guía, consulta cómo agregar manualmente repositorios de software en Linux. A partir de ahí, se instala el paquete de driver igual que cualquier otro software del sistema.

Gestión de controladores por distribución: Debian/Ubuntu, Fedora y Arch

La lógica general de instalación es parecida en todas las distros (añadir repositorio si hace falta, actualizar, instalar paquete), pero cada familia utiliza su propio gestor de paquetes y repositorios. Conviene conocer las diferencias para no hacerse un lío.

En sistemas basados en Debian y Ubuntu se utiliza apt. Para añadir un repositorio extra de drivers (por ejemplo, para obtener versiones recientes de controladores gráficos), puedes usar algo como: sudo add-apt-repository ppa:graphics-drivers/ppa, seguido de sudo apt update. Después instalas el paquete concreto del controlador, por ejemplo: sudo apt install nvidia-driver-XXX, sustituyendo XXX por la versión adecuada.

En Fedora el gestor de paquetes es dnf y los drivers propietarios suelen distribuirse a través de los repositorios comunitarios RPM Fusion. Primero hay que activar estos repositorios (free y nonfree) con los paquetes correspondientes, y después ya puedes instalar, por ejemplo, los controladores de NVIDIA usando sudo dnf install akmod-nvidia y, si lo necesitas, los componentes CUDA con sudo dnf install xorg-x11-drv-nvidia-cuda.

Si lo que quieres es instalar controladores para impresoras HP en Fedora, puedes tirar del paquete hplip con sudo dnf install hplip, que integra soporte y herramientas para una amplia gama de dispositivos de la marca.

En Arch Linux y derivadas (Manjaro, EndeavourOS, etc.) la referencia es pacman para los paquetes oficiales y, en muchos casos, el repositorio comunitario AUR para drivers menos estándar. Por ejemplo, para instalar los controladores NVIDIA puedes usar sudo pacman -S nvidia nvidia-utils. Si tienes una tarjeta WiFi con un chipset Realtek poco común, quizá exista un paquete AUR como rtl8821ce-dkms-git, instalable con ayudantes de AUR tipo yay.

Actualizar los drivers en Linux

Otra diferencia importante respecto a Windows es la forma de mantener al día los controladores. En Linux, la mayoría de drivers abiertos se actualizan con el propio sistema: cuando instalas una versión nueva del kernel, suele venir con versiones mejoradas de los módulos de dispositivo.

Esto significa que, para “tener los drivers al día”, en muchos casos basta con mantener tu distro actualizada usando el gestor de paquetes correspondiente. En Debian/Ubuntu, por ejemplo, con un sudo apt update && sudo apt upgrade y, cuando proceda, instalando versiones nuevas del kernel marcadas como seguras en los repositorios oficiales.

Cuando has instalado un controlador propietario proporcionado como paquete de la distribución (por ejemplo, nvidia-driver desde el repositorio oficial), sus actualizaciones llegan también a través del sistema de paquetes. No hay que ir a la web de NVIDIA salvo que necesites una versión concreta muy reciente que aún no se haya empaquetado.

En el caso de drivers que has instalado directamente desde la web del fabricante o compilando desde código fuente, la responsabilidad de comprobar nuevas versiones recae sobre ti. A veces el propio software instala un pequeño servicio que te avisa de actualizaciones, pero no es lo más habitual en Linux. En entornos profesionales (instrumentación, módulos especiales, etc.) suele ser buena idea suscribirse al boletín o zona de descargas del fabricante.

Para casos muy específicos, como hardware de medida de National Instruments, existen suites como NI Linux Device Drivers, que se integran con el gestor de paquetes de la distribución (por ejemplo, en entornos basados en Debian/Ubuntu) mediante un repositorio adicional. De esta forma puedes instalar y actualizar controladores como NI-DAQmx, NI-VISA, NI-488.2 o NI-Sync igual que cualquier otro paquete del sistema.

Compilar un driver propio y añadirlo al kernel

Hay ocasiones en las que, por muy moderno que sea tu sistema, necesitas ir un paso más allá e integrar un controlador que no viene de serie en el kernel o que requiere modificaciones específicas. Es lo que sucede con algunos módulos de comunicaciones, hardware industrial muy concreto o dispositivos recién salidos al mercado cuyo soporte todavía es preliminar.

Un caso típico es el de un módulo de comunicaciones LTE/4G en formato mini PCIe, como el MeiG SLM750, que se basa en un chipset de Qualcomm y ofrece distintas interfaces (datos, control, GPS, etc.) multiplexadas sobre un único enlace USB. Para que el sistema lo trate como un módem USB estándar y genere varios puertos serie virtuales, a veces hay que modificar el driver genérico de módems USB del kernel.

En este tipo de escenarios se suele trabajar en una máquina con Ubuntu (por ejemplo, 14.04 x64 en muchas guías clásicas, o una versión actual equivalente), idealmente dentro de una máquina virtual para aislar el entorno. El fabricante proporciona documentación, código y los identificadores necesarios (VID y PID) para integrar el soporte en el driver adecuado.

Para compilar un módulo del kernel hace falta instalar las fuentes del kernel (paquete linux-source o equivalente) y las herramientas de compilación esenciales: compilador GCC, make, utilidades de autoconfiguración, bibliotecas de desarrollo (ncurses para las interfaces de configuración del kernel, zlib, SSL, etc.). En Debian/Ubuntu esto se consigue con paquetes como build-essential, flex, bison, libtool y compañía.

Proceso de compilación: del código fuente al módulo .ko

Una vez instaladas las fuentes del kernel (normalmente en /usr/src/linux-) y las herramientas, el siguiente paso consiste en configurar el kernel. Esa configuración se guarda en el archivo .config del árbol de fuentes. Cada opción indica si un determinado subsistema o controlador se compila integrado en el núcleo (=y), como módulo (=m) o no se incluye (no).

Si no existe todavía un archivo .config apropiado, se puede generar utilizando make menuconfig, que abre una interfaz de menús en la terminal (basada en ncurses) donde se van marcando las opciones deseadas. Tras guardar, el archivo .config queda listo en el directorio raíz de las fuentes.

En el caso de un módem USB como el SLM750, suele ser necesario activar el soporte de puertos serie USB y de módems GSM dentro de la configuración del kernel. Esto implica localizar las secciones de drivers USB, habilitar sus módulos relevantes y asegurarse de que se compilarán al invocar make.

El siguiente paso clave es modificar el archivo de código fuente del driver que se va a ampliar, por ejemplo option.c en el árbol de drivers/usb/serial. Ahí se declaran los identificadores de dispositivo soportados. Para que el kernel reconozca el módem de MeiG, se añaden las correspondientes entradas con los VID (Vendor ID) y PID (Product ID) suministrados en la documentación del fabricante.

Además de la tabla de VID/PID, el driver puede requerir ciertas banderas de configuración para cada producto, indicando cuántos puertos se crean, qué interfaces se usan para datos o control, etc. Estas banderas se plasman en la estructura que se pasa al driver, de forma similar a: declarar las macros con los IDs y asociarlas a las estructuras USB_DEVICE con la información de driver_info.

Compilación del módulo y copia en el sistema

Una vez se han hecho las modificaciones en el código fuente y el .config está preparado, no hace falta recompilar todo el kernel (lo que puede llevar horas). Se puede indicar al sistema de construcción que prepare únicamente los módulos necesarios.

En un entorno estándar se suelen ejecutar comandos como make scripts prepare modules_prepare y después make -C . M=drivers/usb/serial dentro del árbol de fuentes. Esto ordena a make que sólo compile los módulos situados en ese directorio, respetando la configuración vigente del kernel.

Finalizada la compilación, se generan varios tipos de fichero: los .c originales, los ficheros objeto .o resultantes de la compilación de cada unidad y, muy importante, los .ko (kernel object) que son los módulos cargables por el kernel. En este ejemplo, interesan ficheros como usbserial.ko, usb_wwan.ko y option.ko, que son los que implementan la lógica de los puertos serie USB y el soporte de módems.

El archivo .ko no es un simple objeto; incluye estructuras de datos adicionales generadas automáticamente por el sistema de compilación del kernel, que describen el módulo y sus símbolos exportados. El cargador de módulos del kernel espera encontrar esa información para poder insertar el driver en tiempo de ejecución; por eso no sirve con un .o plano.

Para instalar estos módulos en el sistema, se copian a la ruta estándar de módulos del kernel, normalmente bajo /lib/modules/$(uname -r)/kernel/drivers/usb/serial. Es importante respetar la estructura de directorios para que las herramientas del sistema los detecten correctamente.

Después de copiar los .ko se ejecuta depmod, que genera una base de datos de dependencias y símbolos disponibles para todos los módulos del directorio /lib/modules/versión. Una vez hecho esto y tras reiniciar la máquina, el kernel debería ser capaz de cargar automáticamente los nuevos módulos al detectar el dispositivo correspondiente.

Verificación y uso del nuevo driver compilado

Tras reiniciar el sistema con los nuevos módulos instalados, toca comprobar que el módem o dispositivo en cuestión es reconocido y gestionado por el driver modificado. Una buena forma de hacerlo es revisar la salida de dmesg filtrando por los dispositivos de serie virtual, por ejemplo: dmesg | grep ttyUSB.

Si todo ha ido bien, deberían aparecer mensajes indicando que el dispositivo USB ha sido reconocido como un “GSM modem” y que se han creado varios puertos, tipo ttyUSB0, ttyUSB1, etc. Esos puertos virtuales son los que luego utilizarán las aplicaciones para comunicarse con el módem mediante comandos AT o protocolos más avanzados.

Para gestionar este tipo de dispositivos en sistemas actuales es muy habitual usar herramientas como ModemManager, que centraliza el control de módems 2G/3G/4G/5G a través de distintos canales (USB, serie, Bluetooth, etc.) y usando protocolos como AT, QCDM, QMI o MBIM. Con comandos como mmcli -m 0 puedes listar la información detallada del módem conectado y comprobar que el driver y el sistema lo ven correctamente.

Este flujo de trabajo -modificar fuentes del kernel, compilar módulos, instalarlos y verificarlos- es representativo de lo que hay que hacer cuando se trata de dar soporte a hardware especializado que no cuenta con paquetes de driver listos en los repositorios. Aunque parezca complejo, siguiendo la documentación del fabricante paso a paso es bastante asumible.

Cuando trabajas con instrumentación y hardware profesional (como el que se integra con NI Linux Device Drivers), el enfoque es similar en espíritu, pero más cómodo: la suite de drivers de NI se instala desde un repositorio adicional y el gestor de paquetes se ocupa de desplegar controladores como NI-DAQmx, NI-VISA, NI-488.2 o NI-Sync, permitiendo su uso desde entornos como LabVIEW u otras aplicaciones de pruebas y medida sobre Linux.

Al final, el ecosistema de controladores en Linux combina lo mejor de dos mundos: por un lado, una base sólida de drivers abiertos integrados en el kernel que cubren casi todo el hardware corriente sin esfuerzo; por otro, la posibilidad de instalar controladores propietarios cuando realmente aportan valor, e incluso compilar y añadir módulos personalizados para dispositivos muy específicos o industriales. Entender estas piezas —repositorios, kernel, módulos, herramientas gráficas y de terminal— es lo que permite pasar de “no toco nada por si lo rompo” a manejar con soltura el tema de los controladores en cualquier distribución.