Monitor externo no detectado: El único controlador que te falta

febrero 14, 2026 • febrero 14, 2026 • Lectura: 26 min • Views: 0

¿Te fue útil?

Conectas un monitor externo. El ventilador del portátil cambia de tono como si se preparara para despegar. La estación de acoplamiento se enciende. El monitor se despierta y luego vuelve a apagarse. En Configuración no aparece nada. Tu “segunda pantalla” ha sido degradada a “pantalla teórica”.

La mayoría de las veces no es magia negra. Es un controlador ausente o mal emparejado en la pila de visualización; y la pila es más larga de lo que la gente cree. Este texto es una guía de campo: cómo identificar rápidamente el verdadero cuello de botella, qué comandos ejecutar, qué significan las salidas y qué decisión tomar a continuación.

Qué es realmente “el único controlador” (y por qué varía)

Cuando alguien dice “instala el controlador”, implica que existe un interruptor único que activa “monitor externo”. En la realidad, tienes una cadena. La detección de pantallas externas falla cuando un eslabón no coincide con la ruta de hardware que realmente estás usando.

Hay cuatro rutas comunes para monitores externos en portátiles/escritorios modernos:

Salidas nativas de la GPU (HDMI/DP) cableadas directamente a la GPU (integrada o dedicada). Controladores: Intel i915, AMD amdgpu, NVIDIA propietario nvidia (y su pila modeset) o abierto nouveau.
USB-C DisplayPort Alt Mode donde el puerto USB-C realmente transporta señales DisplayPort. Los controladores son los mismos que arriba, pero también necesitas que el controlador Type-C, los retimers y a veces la pila Thunderbolt cooperen.
Docks Thunderbolt que presentan salidas DP, muchas veces siguen siendo DP “nativo” tunelizado sobre Thunderbolt. Los controladores incluyen DRM/KMS de la GPU además de Thunderbolt (thunderbolt) y a veces ajustes de firmware.
Docks/adaptadores DisplayLink que comprimen vídeo sobre USB y usan un módulo kernel más un servicio espacio de usuario para crear una GPU virtual. Controlador: DisplayLink (comúnmente el módulo kernel evdi + un demonio en espacio de usuario). Es otra bestia. Modos de fallo distintos.

Entonces, ¿cuál es “el único controlador que te falta”? Depende de la ruta en la que estés:

Si tu dock es DisplayLink y lo tratas como si fuera DP Alt Mode, te falta la pila DisplayLink/EVDI.
Si estás en NVIDIA y instalaste “un controlador” pero no habilitaste nvidia-drm modeset o emparejaste mal el módulo del kernel con las bibliotecas de espacio de usuario, te falta el par kernel+userspace de NVIDIA funcionando.
Si estás en Intel/AMD y los conectores externos aparecen siempre como “disconectado”, puede que te falte el soporte de kernel modesetting o que estés usando un kernel antiguo que no tiene las correcciones USB-C/DP MST adecuadas para tu plataforma.
Si el monitor está presente pero nunca se ilumina, puede que te falte firmware (controlador Type-C, blobs de firmware de la GPU) o que estés frente a problemas de negociación EDID: menos “controlador faltante” y más “el controlador no puede aprender con qué está hablando”.

Operativamente, trata esto como un grafo de dependencias. Tu trabajo es identificar en qué rama estás y validar cada componente con evidencia, no con intuiciones.

Una cita que se ha parafraseado tanto en operaciones que es prácticamente un protocolo: “La esperanza no es una estrategia.” (idea parafraseada comúnmente atribuida a ingenieros y planificación militar; de uso amplio en cultura de fiabilidad)

Broma #1: Los monitores externos son como las guardias de turno: el segundo solo aparece cuando ya vas tarde.

Guion de diagnóstico rápido

Esta es la secuencia “no te compliques”. Estás cazando el cuello de botella. Empieza amplio y luego afina. Si te saltas pasos, arreglarás lo equivocado y te sentirás productivo mientras sigues roto.

Primero: identifica el transporte (HDMI/DP nativo vs USB-C alt mode vs DisplayLink)

Busca firmas de DisplayLink en los ID de dispositivos USB y en los registros del kernel.
Revisa los conectores DRM para el estado “connected/disconnected”.
Confirma qué GPU está conduciendo las salidas (especialmente en portátiles con gráficos híbridos).

Segundo: confirma que el controlador está cargado y coincide con el kernel

¿Módulo del kernel presente? (lsmod)
¿Errores en dmesg del kernel? (firmware faltante, falló la inicialización, módulo tainted)
Pila en espacio de usuario consistente? (coincidencia de versiones de NVIDIA; demonio DisplayLink corriendo)

Tercero: confirma el conector y los handshakes EDID

¿EDID legible? (sysfs DRM) Si EDID está vacío o con errores, “no detectarás nada”.
¿Topología DP MST? Para docks con múltiples puertos, MST es un culpable frecuente.
¿Negociación de potencia/alt-mode? Las rarezas de USB-C aparecen en los logs como mensajes typec/ucsi.

Regla de decisión

Si el monitor nunca aparece en el estado de conector DRM, deja de ajustar la configuración del escritorio. Arregla la capa transporte/controlador/kernel. Si aparece como connected pero ningún modo funciona, estás en territorio EDID/modos/MST.

Hechos y contexto: por qué las pantallas externas siguen siendo frágiles

La fiabilidad de pantallas externas parece algo que debería haberse resuelto en 2006. Sin embargo, aquí estamos. Unos puntos concretos de contexto hacen el caos menos misterioso:

EDID viene de décadas atrás (originalmente la forma de VESA para que los monitores se describieran). Sigue siendo el handshake del que depende tu SO, y sigue corrompiéndose por cables y docks malos.
DisplayPort introdujo MST (Multi-Stream Transport) para que un enlace DP pueda llevar múltiples pantallas. Genial en teoría; en la práctica, los hubs y docks MST son una fuente constante de “monitores fantasma” y enumeración inestable.
USB-C hizo ambigua la “identidad del puerto”: el mismo conector puede hacer solo USB, USB + DP Alt Mode, o Thunderbolt. Tu cable puede soportar carga pero no carriles DP. No es un modelo de fallos amigable para el usuario.
Thunderbolt tuneliza protocolos (PCIe, DisplayPort). Es potente, y también significa que el firmware, los niveles de seguridad y el soporte del kernel pueden bloquear lo que “debería funcionar”.
Los gráficos híbridos (iGPU + dGPU) cambiaron la historia de cableado. Muchos portátiles enrutan puertos externos al iGPU incluso cuando el renderizado usa la dGPU, o viceversa. Las suposiciones aquí causan reuniones largas y costosas de depuración.
Wayland vs Xorg importa: algunas herramientas de proveedor y flujos de trabajo antiguos (como el uso intensivo de xrandr) se comportan diferente, y los controladores maduraron a ritmos distintos entre compositores.
La historia del controlador NVIDIA en Linux incluye transiciones: legado vs moderno, integración modesetting y comportamiento distinto entre versiones de kernel. Las discordancias pueden “funcionar” internamente pero fallar externamente.
DisplayLink no es un “protocolo de monitor”; es vídeo sobre USB con compresión y un dispositivo de pantalla virtual. Puede ser excelente, pero es una ruta gráfica separada que necesita controladores y servicios distintos.

Un mapa práctico de fallos: dónde se rompe la detección

Cuando un monitor externo no se detecta, solo hay tantos lugares donde se puede esconder la verdad. Aquí está el mapa que uso en soporte de producción:

Capa física: cable, direccionalidad del adaptador, alimentación, daño del puerto, soporte de carriles DP en el cable.
Negociación de enlace: negociación de alt mode USB-C, autorización Thunderbolt, entrenamiento de enlace DP.
Enumeración de dispositivos del kernel: ¿el SO ve un nuevo conector/dispositivo? ¿Aparece el conector DRM? ¿Aparece el dispositivo USB?
Adjunto del controlador: el módulo kernel correcto se carga y se enlaza al dispositivo; el firmware se carga.
Modesetting: KMS crea un framebuffer y lista de modos. Se parsea EDID.
Compositor/sesión: Wayland/Xorg lo detecta, aplica políticas y habilita la salida.
Política de usuario: tapa cerrada, DPMS, pantalla deshabilitada, conflictos de modo espejo, errores de escalado fraccionario.

Si tratas el problema como “mi monitor es invisible”, perseguirás la UI. Trátalo como una canalización: “¿dónde se detuvo la señal?”

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas tareas asumen Linux porque es donde “controlador faltante” es más literal y más solucionable con evidencia. Si estás en Windows/macOS, los pasos conceptuales siguen aplicando, pero las herramientas son distintas.

Task 1: Check what the kernel thinks about DRM connectors

cr0x@server:~$ for s in /sys/class/drm/card*-*/status; do echo "$s: $(cat $s)"; done
/sys/class/drm/card0-DP-1/status: disconnected
/sys/class/drm/card0-DP-2/status: connected
/sys/class/drm/card0-HDMI-A-1/status: disconnected

Qué significa: La capa DRM del kernel ve los conectores y su estado actual. Si todo está disconnected mientras hay un monitor enchufado, estás por debajo del compositor: cable/puerto/alt-mode/controlador/firmware.

Decisión: Si ningún conector cambia a connected, ve a los logs de USB-C/Thunderbolt/typec y verifica controladores. Si un conector está connected, procede a EDID y modos.

Task 2: Identify GPU(s) and which driver is active

cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D|Display"
00:02.0 VGA compatible controller [0300]: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49]
	Subsystem: Lenovo Device [17aa:XXXX]
	Kernel driver in use: i915
	Kernel modules: i915
01:00.0 3D controller [0302]: NVIDIA Corporation TU117M [GeForce GTX] [10de:1f99]
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Qué significa: Ves los dispositivos y qué controlador del kernel está realmente vinculado a ellos. Aquí es donde “instalé el controlador” se convierte en “el kernel está usando el controlador”.

Decisión: Si esperas NVIDIA pero ves nouveau, o viceversa, corrige el enlace primero. Si tienes gráficos híbridos, averigua qué GPU posee los puertos externos (a menudo iGPU).

Task 3: Confirm kernel modules are loaded (and not half-loaded)

cr0x@server:~$ lsmod | egrep 'i915|amdgpu|nvidia|nouveau|evdi|drm_kms_helper|typec|ucsi'
nvidia_drm             73728  2
nvidia_modeset       1236992  3 nvidia_drm
nvidia              62410752  89 nvidia_modeset
i915                 4128768  4
drm_kms_helper        315392  2 i915,nvidia_drm
ucsi_acpi             16384  0
typec_ucsi            49152  1 ucsi_acpi

Qué significa: Una pila sana suele mostrar DRM helpers más tu módulo GPU. Para DisplayLink esperarías evdi. Para USB-C alt mode a menudo verás módulos UCSI/typec.

Decisión: ¿Módulo ausente? Instala/habilita el paquete controlador correcto, o corrige Secure Boot/firmado de módulos. ¿Módulo presente pero con errores en logs? Pasa a dmesg.

Task 4: Look at kernel logs for display-related failures

cr0x@server:~$ sudo dmesg -T | egrep -i "drm|edid|dp|hdmi|typec|ucsi|thunderbolt|nvidia|evdi" | tail -n 30
[Mon Feb  3 10:11:24 2026] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[Mon Feb  3 10:12:01 2026] i915 0000:00:02.0: [drm] DP-2: EDID is invalid
[Mon Feb  3 10:12:01 2026] i915 0000:00:02.0: [drm] DP-2: DPCD: 001 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[Mon Feb  3 10:12:05 2026] ucsi_acpi USBC000:00: PPM init failed (-110)

Qué significa: Aquí el sistema confiesa. EDID inválido apunta a handshake por cable/dock/monitor. Timeouts UCSI pueden significar problemas del controlador USB-C/firmware.

Decisión: Errores EDID → prueba otro cable/puerto/dock y luego considera forzar EDID (más adelante). Fallos UCSI → actualizar BIOS/firmware o kernel suele vencer mil ajustes de espacio de usuario.

Task 5: Determine if you’re dealing with DisplayLink (USB graphics) vs Alt Mode

cr0x@server:~$ lsusb
Bus 002 Device 002: ID 2109:0817 VIA Labs, Inc. USB3.0 Hub
Bus 002 Device 003: ID 17e9:6012 DisplayLink USB3.0 to HDMI Adapter
Bus 001 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver

Qué significa: Un dispositivo DisplayLink aparece explícito. Si lo ves, tu ruta de monitor externo probablemente no sea DP Alt Mode: es pantalla USB.

Decisión: Si DisplayLink está presente, deja de depurar MST primero. Instala/verifica DisplayLink/EVDI y su servicio. Si no aparece DisplayLink, probablemente estés en salidas GPU nativas o alt mode.

Task 6: Verify the DisplayLink/EVDI kernel module (if applicable)

cr0x@server:~$ modinfo evdi | head
filename:       /lib/modules/6.5.0-21-generic/updates/dkms/evdi.ko
version:        1.14.4
license:        GPL
description:    Extensible Virtual Display Interface
author:         DisplayLink (UK) Ltd.

Qué significa: El módulo existe para tu kernel en ejecución. Si modinfo falla, no tienes el componente kernel compilado/instalado.

Decisión: Sin módulo → instala el paquete DisplayLink correcto o la cadena DKMS; verifica headers del kernel. Módulo existe → confirma que esté cargado y que el servicio de espacio de usuario corra.

Task 7: Check whether the DisplayLink service is running (if applicable)

cr0x@server:~$ systemctl status displaylink-driver.service --no-pager
● displaylink-driver.service - DisplayLink Driver Service
     Loaded: loaded (/lib/systemd/system/displaylink-driver.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2026-02-03 10:20:11 UTC; 3min ago
   Main PID: 1422 (DisplayLinkMana)
      Tasks: 18 (limit: 18912)
     Memory: 42.1M
        CPU: 1.202s

Qué significa: Para DisplayLink, un demonio en ejecución es parte del “controlador”. Sin él, puede que veas dispositivos USB pero ninguna salida de pantalla.

Decisión: Si está inactivo/fallido, inspecciona logs y reinstala/actualiza. Si está en ejecución, vuelve a las comprobaciones de conectores DRM: las salidas DisplayLink deberían aparecer como conectores adicionales.

Task 8: Check Wayland vs Xorg session (it matters for tooling and quirks)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Qué significa: Si estás en Wayland, xrandr puede no reflejar la realidad. Aun así puedes depurar el kernel/DRM con sysfs y logs.

Decisión: Si una herramienta de proveedor espera Xorg (algunos flujos antiguos de DisplayLink, ciertos casos límite de NVIDIA), considera cambiar temporalmente a Xorg para el diagnóstico—temporal, no para siempre.

Task 9: Under Xorg, enumerate outputs and modes with xrandr

cr0x@server:~$ xrandr --query
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
   1920x1080     60.01*+
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)

Qué significa: X ve el mismo estado de conectores. Si DRM dice connected pero xrandr dice disconnected, puedes tener un desajuste de sesión/permisos o múltiples GPUs con proveedores separados.

Decisión: Si xrandr muestra la salida conectada, intenta habilitarla. Si está desconectada, vuelve a bajar en la pila: estado del conector del kernel y logs.

Task 10: On hybrid graphics, check providers and offload configuration

cr0x@server:~$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x46 cap: 0x9, Source Output, Sink Offload crtcs: 3 outputs: 4 associated providers: 1 name:Intel
Provider 1: id: 0x1f9 cap: 0x2, Sink Output crtcs: 4 outputs: 0 associated providers: 1 name:NVIDIA-G0

Qué significa: Los providers te dicen si el dispositivo NVIDIA realmente provee salidas. En muchos portátiles es solo render y el iGPU posee los conectores.

Decisión: Si la dGPU tiene cero salidas, deja de esperar que conduzca directamente el monitor externo. Enfócate en el estado del conector iGPU y en el DP alt mode USB-C.

Task 11: Read EDID directly from sysfs when a connector is “connected” but no modes work

cr0x@server:~$ sudo hexdump -C /sys/class/drm/card0-DP-2/edid | head
00000000  00 ff ff ff ff ff ff 00  4c 2d fa 0a 35 31 30 30  |........L-..5100|
00000010  0c 1e 01 03 80 3c 22 78  2a ee 95 a3 54 4c 99 26  |.....<"x*...TL.&|
00000020  0f 50 54 a5 4b 00 71 4f  81 80 81 40 81 c0 95 00  |.PT.K.qO...@....|

Qué significa: Si obtienes bytes EDID reales, el monitor está hablando. Si el archivo está vacío o hay errores de lectura, el handshake está fallando.

Decisión: EDID legible → enfócate en modesetting/política del compositor. EDID ilegible → cambia cable/dock; considera deshabilitar MST; valora actualizar firmware/kernel.

Task 12: Check DP MST and connector topology hints

cr0x@server:~$ sudo cat /sys/kernel/debug/dri/0/i915_display_info | head -n 40
CRTC info
  CRTC 0: pipe A, active=yes
Connector info
  DP-2: status: connected
    link-status: GOOD
    max bpc: 12
    has audio: yes
    EDID: yes
    MST: yes

Qué significa: Debugfs puede confirmar que MST está en juego. MST + docks + múltiples monitores es una cuña clásica para fallos de detección.

Decisión: Si MST está involucrado y es inestable, prueba con un solo monitor, otro puerto del dock, o deshabilita MST si tu plataforma lo permite (específico del proveedor). Si un monitor individual funciona pero múltiples fallan, MST es tu sospechoso.

Task 13: Verify Thunderbolt device authorization and status (Thunderbolt path)

cr0x@server:~$ boltctl
 ● CalDigit TS3 Plus
   ├─ type:          peripheral
   ├─ name:          CalDigit TS3 Plus
   ├─ uuid:          00112233-4455-6677-8899-aabbccddeeff
   ├─ status:        authorized
   ├─ connected:     yes
   └─ stored:        yes

Qué significa: La seguridad Thunderbolt puede bloquear la función del dispositivo hasta que se autorice. Si no está autorizado, el tunelizado DP puede nunca ocurrir.

Decisión: Si el estado no está autorizado, autorízalo (si la política lo permite) o ajusta la política BIOS/bolt. Si está autorizado, continúa con las comprobaciones de conectores DRM.

Task 14: Check for firmware loading failures (common on Intel/AMD GPUs)

cr0x@server:~$ sudo dmesg -T | egrep -i "firmware|failed to load|ucode|amdgpu|i915" | tail -n 20
[Mon Feb  3 10:11:23 2026] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin
[Mon Feb  3 10:11:23 2026] i915 0000:00:00.0: [drm] GuC firmware i915/tgl_guc_70.1.1.bin version 70.1.1
[Mon Feb  3 10:11:23 2026] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9.3

Qué significa: El firmware se carga con éxito. Si ves “failed to load”, puedes obtener comportamientos extraños en pantallas externas incluso si el panel interno funciona.

Decisión: Firmware faltante → instala el paquete de firmware correcto para tu distro; considera actualizar el kernel si tu hardware es más nuevo que tu SO.

Task 15: NVIDIA sanity check (driver version consistency)

cr0x@server:~$ nvidia-smi
Tue Feb  3 10:25:12 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4   |
|-----------------------------------------+------------------------+----------------------|
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
|  0   NVIDIA GeForce GTX               Off| 00000000:01:00.0  Off  |                  N/A |
+---------------------------------------------------------------------------------------+

Qué significa: La herramienta de espacio de usuario NVIDIA puede hablar con el controlador del kernel. Eso no garantiza que las salidas externas funcionen, pero descarta una gran clase de desajustes.

Decisión: Si nvidia-smi falla, arregla la instalación del controlador antes que nada. Si funciona pero las pantallas externas fallan, revisa nvidia_drm modeset y compatibilidad con el compositor.

Task 16: Confirm NVIDIA DRM modesetting is enabled (common “missing driver” in disguise)

cr0x@server:~$ cat /sys/module/nvidia_drm/parameters/modeset
Y

Qué significa: Y indica que la integración DRM KMS de NVIDIA está habilitada. Sin ello, el comportamiento de monitores externos puede ser impredecible, especialmente con Wayland.

Decisión: Si N, habilita modesetting vía parámetros del módulo del kernel de la forma soportada por tu distro, luego reinicia y vuelve a comprobar el estado de los conectores DRM.

Broma #2: El “dock universal” es universal del mismo modo que el “mando universal” es universal: sobre todo sirve para iniciar conversaciones.

Tres microhistorias corporativas desde el terreno

Microhistoria #1: El incidente causado por una suposición incorrecta

En una empresa mediana con muchos portátiles Linux, el equipo de TI estandarizó en una buena estación USB-C. A compras le gustó. Quedaba bien en los escritorios. Dos semanas después empezaron los tickets: “monitor externo no detectado” en un modelo de portátil específico, pero solo en uno de los dos puertos de monitor.

Alguien hizo una suposición limpia y confiada: “USB-C es USB-C. El dock está bien; es la imagen del SO.” Revirtieron la actualización del entorno de escritorio. Sin cambios. Luego fijaron la versión del kernel. Aún sin cambios. El volumen de tickets creció y aquello se convirtió en un “problema de estabilidad de plataforma”, que en corporativo significa “ahora todos asistirán a reuniones”.

El problema real: el segundo puerto de ese dock dependía de DisplayPort MST, y la ruta USB-C del portátil pasaba por un retimer particular. Bajo carga, el entrenamiento del enlace se degradaba y las lecturas EDID fallaban intermitentemente. La pantalla interna siempre funcionaba, así que la gente persiguió el comportamiento del gestor de ventanas y la configuración de pantalla. Clásica distracción.

La solución no fue dramática. Probaron con un cable USB-C-a-DP directo (saltándose el dock) y el monitor se enumeró inmediatamente. Cambiaron docks y cables; la falla se reproducía solo con esa combinación dock+puerto. Luego actualizaron BIOS/firmware y pasaron a una versión del kernel con correcciones de estabilidad para la pila Type-C/DP de esa plataforma. El “único controlador que faltaba” resultó ser “el firmware+comportamiento del kernel que hace que el controlador sea fiable”.

La lección operativa: no asumas el transporte. Demuéstralo. “Dock” no es un transporte; es una lotería hecha de silicio.

Microhistoria #2: La optimización que salió mal

Otra organización tenía una flota de estaciones de trabajo con GPUs NVIDIA. Querían tiempos de arranque más rápidos y menos piezas móviles, así que “optimizaron” eliminando “servicios innecesarios” y recortando módulos del kernel. Un ingeniero bienintencionado quitó todo lo que parecía opcional, incluyendo partes relacionadas con hooks del gestor de pantalla y el comportamiento de modesetting de la GPU.

Durante semanas, todo pareció bien—con monitores individuales. Entonces un equipo llevó una remesa de pantallas 4K y un par de docks Thunderbolt. De repente: pantallas externas “no detectadas” o que aparecían y luego caían. La gente culpó a los docks. La gente culpó a los monitores. La gente culpó al proveedor de GPU, lo cual es un hobby para algunos.

La causa raíz fue sutil. Su sistema ya no cargaba consistentemente la ruta de modesetting correcta temprano en el arranque. El controlador NVIDIA se cargaba, pero la integración DRM/KMS no se habilitó de forma que jugara bien con el compositor y los eventos hotplug. Podías seguir renderizando. Podías seguir usando cómputo. Pero la canalización de pantallas externas era frágil y dependiente del tiempo.

La reversión fue fea: reintroducir los módulos y la configuración esperada, y dejar de tratar los gráficos como plomería opcional. El tiempo de arranque aumentó un poco. Los incidentes disminuyeron mucho. La “optimización” ahorró segundos y costó días.

La lección operativa: optimizaciones de rendimiento que eliminan plomería kernel “no usada” son indistinguibles de sabotaje cuando cambia la topología de hardware. Mantén las piezas de compatibilidad aburridas a menos que tengas una razón medida para no hacerlo.

Microhistoria #3: La práctica aburrida pero correcta que salvó el día

Una empresa financiera ejecutaba una imagen Linux estandarizada para miles de usuarios. Las pantallas externas eran críticas porque muchos escritorios tenían doble pantalla para herramientas de trading. Tenían una política que sonaba aburrida: pruebas de certificación de hardware para cada combinación portátil+dock+monitor, con una lista de comprobación pequeña y un conjunto almacenado de logs.

Cuando llegó un nuevo modelo de portátil, no solo lo imáginaron y esperaron. Ejecutaron la lista: capturar dmesg, capturar el estado de conectores DRM, capturar lspci -nnk, verificar lecturas EDID y comprobar sesiones Wayland y Xorg si se soportaban. Si algo fallaba, abrían un caso con el proveedor con evidencia concreta, no “está roto”.

Meses después, una actualización del kernel introdujo una regresión que afectó el hotplug USB-C en ese modelo. Los usuarios lo notaron rápido. Pero la remediación fue rápida porque tenían líneas base: “así era el estado del conector antes; así es ahora; aquí está el snippet exacto del log del kernel donde UCSI empieza a timeoutear”.

Fijaron el kernel solo para ese modelo, desplegaron una solución temporal dirigida y planificaron una actualización controlada cuando llegó la corrección. Sin drama. Sin rollback masivo. Sin llamada general.

La lección operativa: capturar líneas base aburridas convierte el dolor subjetivo en un diff accionable. No es glamoroso, pero tampoco lo es un outage de pantallas en 2.000 puestos.

Errores comunes: síntoma → causa raíz → solución

Esta es la parte donde dejamos de fingir que todos los problemas “monitor no detectado” son idénticos. Aquí están los patrones que repito, mapeados a soluciones específicas.

1) Síntoma: No aparece nada en configuración de pantalla; conectores DRM todos desconectados

Causa raíz: suposición errónea sobre el transporte (DisplayLink vs Alt Mode), cable muerto o negociación USB-C alt mode fallando.
Solución: ejecuta lsusb para detectar DisplayLink; comprueba estado de conectores DRM; revisa dmesg por errores UCSI/typec; prueba un cable conocido que soporte explícitamente DP Alt Mode; intenta otro puerto USB-C si hay.

2) Síntoma: Monitor detectado a veces, luego desaparece tras suspensión/reanudación

Causa raíz: entrenamiento de enlace DP inestable vía dock, inestabilidad de hub MST o bugs de controlador en manejo de hotplug.
Solución: actualiza BIOS/firmware; actualiza el kernel; prueba con MST desactivado (o pantalla única); evita cables DP baratos; si es NVIDIA, asegura que DRM modeset esté habilitado y que estés en un controlador conocido por comportarse con tu compositor.

3) Síntoma: Dock DisplayLink aparece en lsusb, pero no aparecen monitores nuevos

Causa raíz: módulo EVDI faltante para el kernel actual, o servicio DisplayLink no corriendo, o Secure Boot bloqueando el módulo.
Solución: confirma modinfo evdi y lsmod | grep evdi; revisa systemctl status displaylink-driver.service; si Secure Boot está activado, firma el módulo o desactiva Secure Boot según la política.

4) Síntoma: DRM muestra conector “connected”, pero no hay modos disponibles / pantalla negra

Causa raíz: fallos de parseo EDID o EDID malo vía dock; a veces rarezas HDR/DSC; a veces confusión MST.
Solución: lee EDID desde sysfs; cambia cable/dock; prueba una conexión directa; intenta otra tasa de refresco; considera forzar un modo conocido en Xorg; actualiza firmware/kernel.

5) Síntoma: Sistema NVIDIA; la pantalla interna funciona; monitor externo nunca detectado en Wayland

Causa raíz: modesetting DRM de NVIDIA deshabilitado o componentes mal emparejados; limitaciones del compositor en stacks más antiguos.
Solución: revisa /sys/module/nvidia_drm/parameters/modeset; asegura que módulo kernel y espacio de usuario coincidan en versión; prueba temporalmente en Xorg para confirmar que la ruta hardware funciona, luego arregla la compatibilidad en Wayland correctamente.

6) Síntoma: El dock tiene dos salidas de monitor; solo una funciona de forma fiable

Causa raíz: topología MST y límites de ancho de banda, o un dock con hub MST sensible a la calidad del cable.
Solución: prueba cada puerto individualmente; baja la tasa de refresco o la resolución; usa DP en lugar de HDMI en el dock si está soportado; usa otro modelo de dock conocido por manejar mejor MST.

7) Síntoma: El monitor externo funciona solo después de reiniciar, no con hotplug

Causa raíz: eventos hotplug no entregados/manejados, o la máquina de estados Type-C atascada.
Solución: revisa logs alrededor del instante de conexión; actualiza kernel/firmware; evita políticas de gestión de energía agresivas; para depurar, reconecta el cable y prueba un ciclo de energía completo del dock y del monitor.

Listas de comprobación / plan paso a paso

Checklist A: Triagem de 10 minutos para “no detectado”

Confirma el transporte: ejecuta lsusb. Si aparece DisplayLink, sigue la ruta DisplayLink; de lo contrario sigue la ruta DP/HDMI/alt-mode.
Revisa estado de conectores DRM: si nada muestra connected, detente. Estás por debajo del entorno de escritorio.
Verifica enlace del controlador GPU: lspci -nnk. Confirma que el controlador correcto esté en uso.
Escanea logs: dmesg por errores EDID/typec/ucsi/thunderbolt.
Valida EDID si está conectado: hexdump del EDID en sysfs. Sin EDID, no hay modos estables.

Checklist B: Ruta de corrección para docks DisplayLink

Verifica dispositivo presente: lsusb muestra ID DisplayLink.
Verifica que el módulo kernel exista: modinfo evdi.
Verifica que el módulo esté cargado: lsmod | grep evdi.
Verifica que el servicio esté corriendo: systemctl status displaylink-driver.service.
Reinicia después de instalar el controlador (sí, en serio). Las pilas de pantalla no son corteses al intercambiar sus cimientos en caliente.

Checklist C: Ruta de corrección para USB-C DP Alt Mode / Thunderbolt

Prueba un cable conocido y certificado para vídeo. Muchos “cables USB-C de carga” son solo datos o están por debajo de lo especificado para carriles DP.
Confirma módulos typec/ucsi: lsmod | grep -E 'typec|ucsi'.
Revisa logs UCSI/typec en dmesg por timeouts.
Si es Thunderbolt: confirma la autorización con boltctl.
Actualiza BIOS/firmware si aparecen fallos UCSI. Suele ser la corrección menos dolorosa.

Checklist D: Ruta de corrección para problemas externos con NVIDIA

Confirma que el controlador esté cargado: nvidia-smi funciona.
Confirma modeset DRM: cat /sys/module/nvidia_drm/parameters/modeset devuelve Y.
Confirma estado de conectores en sysfs DRM.
Si es híbrido: usa xrandr --listproviders (bajo Xorg) para confirmar qué GPU posee las salidas.
Si Wayland es problemático: prueba en Xorg para aislar “controlador vs compositor”. Luego arregla la capa correcta.

Preguntas frecuentes (FAQ)

1) ¿Cuál es “el único controlador” que más gente realmente está perdiendo?

En Linux, suele ser uno de estos: el controlador propietario NVIDIA (correctamente instalado y emparejado), la pila DisplayLink/EVDI para docks USB, o un kernel/firmware más nuevo que soporte tu ruta USB-C/DP de forma fiable.

2) ¿Cómo sé si mi dock es DisplayLink?

Ejecuta lsusb. Si ves un dispositivo etiquetado DisplayLink o un ID de proveedor conocido de DisplayLink, estás en la ruta de gráficos USB y necesitas DisplayLink/EVDI más su servicio.

3) Mi monitor está conectado pero muestra “Sin señal”. ¿Sigue siendo un problema de controlador?

A menudo es EDID/modesetting o entrenamiento de enlace. Si DRM dice connected, lee el EDID desde sysfs. Si EDID es inválido o falta, el SO no puede elegir un modo con confianza.

4) ¿Por qué cambiar cables HDMI a veces “arregla el controlador”?

Porque nunca fue el controlador. Cables malos o que no cumplen especificación causan corrupción EDID, fallos en el entrenamiento del enlace y detección hotplug inestable. El controlador es el mensajero que se lleva la culpa.

5) ¿Necesito Xorg para que las pantallas externas funcionen?

No. Pero las herramientas de Xorg pueden ser útiles para diagnóstico, y algunos stacks de proveedores históricamente se comportaron mejor allí. Úsalo como arnés de prueba, no como estilo de vida.

6) ¿Por qué funciona tras reiniciar pero no al hotplug?

El hotplug depende de que los eventos lleguen desde hardware hasta kernel y compositor. Docks, hubs MST y controladores Type-C pueden quedar atascados. Los logs alrededor del instante de conexión suelen decir qué capa falló.

7) Tengo Intel + NVIDIA. ¿Cuál controla el puerto externo?

Depende del cableado del portátil. Muchos modelos enrutan salidas externas a través del iGPU aunque la dGPU haga el render. Usa lspci -nnk y (bajo Xorg) xrandr --listproviders para confirmarlo.

8) ¿Una actualización de BIOS es realmente parte del “troubleshooting” de controladores?

Sí. USB-C alt mode y Thunderbolt dependen del firmware. Si tus logs muestran fallos UCSI o timeouts de negociación repetidos, las actualizaciones BIOS/firmware suelen ser la vía más rápida hacia la estabilidad.

9) ¿Puedo “forzar” que un monitor externo funcione sin EDID?

A veces, bajo Xorg, puedes forzar un modeline o proporcionar una sobreescritura EDID. Es un parche, no una solución. En entornos gestionados puede ser aceptable para un modelo de monitor específico, pero es frágil con docks variados.

10) ¿Qué debo recopilar antes de escalar al soporte del proveedor?

Como mínimo: lspci -nnk, salida del estado de conectores DRM, extracto de dmesg alrededor del instante de conexión, si es DisplayLink (lsusb) y tus versiones de kernel/controlador.

Conclusión: pasos siguientes que no te morderán más tarde

Si tu monitor externo no se detecta, no empieces por reinstalar tu entorno de escritorio o alternar ajustes al azar. Demuestra el transporte. Demuestra el enlace del controlador. Luego demuestra el handshake. Arreglarás lo correcto más rápido y evitarás la regresión clásica donde “funciona en mi escritorio” se convierte en “falla para todos los demás”.

Pasos prácticos siguientes:

Ejecuta el Guion de diagnóstico rápido en orden y escribe lo que aprendes en cada capa.
Si es DisplayLink, instala/valida EVDI + servicio; no pierdas tiempo en tierra DP/MST.
Si es USB-C/Thunderbolt alt mode, confía en tus logs: fallos UCSI/typec suelen significar alineación firmware/kernel, no la UI.
Si es NVIDIA, asegura que el módulo del kernel, las bibliotecas de espacio de usuario y el DRM modeset sean consistentes.
Una vez arreglado, captura una línea base (estado de conectores, extracto dmesg, versiones de controladores). Tu yo futuro agradecerá al yo presente, en silencio, que es la forma más alta de elogio en operaciones.