Cómo hice funcionar mi segundo monitor en Linux sin drivers

Fecha: 1 de octubre de 2026

El día que mi segundo monitor quiso jubilarse antes que yo (y cómo lo convencí para volver al trabajo)

Te juro que no exagero: pasé tres semanas peleándome con un monitor portátil que, en Windows, funcionaba como un reloj suizo. Lo enchufabas y aparecía la imagen. Magia. Pero en cuanto arrancaba mi distro de Linux, el muy desgraciado se quedaba negro, con esa carita de "yo aquí no pinto nada". Un ladrillo caro con marco fino.

Y no, no era cosa de mi portátil. Era cosa de un señor llamado DisplayLink.

Si estás leyendo esto porque tienes un monitor portátil barato tirado en un cajón porque "en Linux no va", respira. Te cuento exactamente qué pasó, por qué pasó y cómo acabé programando con dos pantallas sin instalar un solo driver propietario. Spoiler: el problema no era Linux. Era el monitor. Bueno, casi siempre.

El caso: un segundo display que solo quería funcionar a su manera

Todo empezó cuando decidí que mi espalda merecía un segundo monitor para programar. Ya sabes: la terminal a un lado, el editor al otro, y ese navegador con 47 pestañas abiertas que nunca cierro. Compré un monitor portátil de esos baratos, de 15 pulgadas, USB-C, delgado como una carpeta. El vendedor me dijo "es plug and play". Mentira podrida.

En Windows, efectivamente, era plug and play. En Linux, era plug and pray.

El monitor aparecía en lsusb como un dispositivo USB más, pero no generaba ninguna salida de vídeo. xrandr no lo detectaba. dmesg escupía mensajes sobre un chip que no reconocía. Y ahí estaba yo, un sábado por la mañana, con café frío y cara de tonto, buscando en foros de 2014 respuestas que ya nadie recordaba.

La pista clave llegó cuando leí que ese modelo usaba DisplayLink. Y ahí se me encendió la bombilla: DisplayLink no es un estándar de vídeo. Es una tecnología que comprime la imagen, la manda por USB y necesita un driver propietario en el sistema operativo para descomprimirla y mostrarla. En Windows y macOS, ese driver viene o se instala fácil. En Linux, es un dolor de muelas histórico.

Paso 1: entender por qué fallaba (y no era culpa de Linux)

Aquí va la primera lección, y quiero que la subrayes mentalmente: no todo USB-C es igual. Que un monitor tenga conector USB-C no significa que use vídeo nativo. Hay dos mundos:

1. USB-C con DisplayPort Alt Mode: el puerto del portátil manda directamente una señal de vídeo por el cable. Es como un HDMI disfrazado de USB-C. Cero drivers. Cero dramas. El sistema operativo lo ve como un monitor normal.
2. USB-C con DisplayLink: el monitor usa un chip que comprime la imagen y la envía como datos USB. Necesita driver propietario. En Linux, eso significa instalar software cerrado, rezar para que compile con tu kernel y aceptar que cada actualización puede romperlo todo.

Mi monitor barato era del segundo tipo. Y ahí estaba el problema.

Paso 2: la criba de modelos (y por qué descarté casi todos)

Me puse a investigar. Y descubrí que muchos monitores portátiles económicos de marcas que no voy a nombrar (porque no merecen ni el espacio) directamente no han sido probados en Linux de forma seria. Son apuestas. Puede que funcionen, puede que no. Y yo no tengo tiempo para apostar con mi setup de trabajo.

El caso paradigmático es un modelo muy popular de una marca conocida, con panel TN y resolución 1366x768. Históricamente ha requerido DisplayLink en algunos modos, lo que lo convierte en un compañero tóxico para Linux. Lo descarté sin piedad.

Así que hice una lista de requisitos no negociables:

• USB-C con DisplayPort Alt Mode o HDMI. Punto.
• Sin DisplayLink. Ni de broma.
• Panel IPS. Que los ángulos de visión importan cuando giras la cabeza para mirar el segundo monitor.
• Full HD. Para 15 pulgadas, 1920x1080 es el punto dulce.
• Menos de 1 kg. Si pesa más que mi portátil, no es portátil.
• 60 Hz. No necesito 144 Hz para leer código.

Paso 3: verificar que mi portátil podía con todo

Antes de comprar nada, comprobé que el USB-C de mi portátil soportara salida de vídeo. No todos lo hacen. Algunos puertos USB-C solo sirven para datos y carga. Es una trampa cruel que los fabricantes esconden en la letra pequeña.

¿Cómo lo verifiqué? Fácil: miré las especificaciones del puerto y busqué "DisplayPort Alt Mode" o "DP Alt Mode". Si no aparece, ese puerto no te va a dar imagen. Punto.

También comprobé que el portátil pudiera alimentar el monitor por ese mismo cable. Algunos monitores portátiles consumen más de lo que el puerto puede dar, y necesitan alimentación externa. Otros, más listos, tienen batería integrada o pasan la carga al portátil.

Paso 4: la elección (y el momento "esto funciona")

Después de descartar media tienda, me quedé con un modelo de una marca que sí se toma en serio Linux. Panel IPS, 15.6 pulgadas, Full HD, USB-C nativo con DP Alt Mode, y peso contenido. Lo enchufé.

Y funcionó.

Sin drivers. Sin configuraciones raras. Sin reiniciar. El sistema lo detectó como un monitor externo, lo puse a la derecha de la pantalla principal, ajusté la escala y me puse a programar. La terminal a la izquierda, el editor a la derecha, y yo con una sonrisa de niño con zapatos nuevos.

Paso 5: el ajuste fino (porque siempre hay algo)

No todo fue perfecto. Tuve que ajustar algunas cosas:

• Escalado: el segundo monitor tenía una densidad de píxeles distinta, así que configuré escalas diferentes para cada pantalla. Si no, las fuentes se veían gigantes en una y diminutas en la otra.
• Posición: lo puse a la derecha y alineé los bordes superiores. Suena trivial, pero cuando mueves el ratón entre pantallas, la continuidad importa.
• Brillo: los monitores portátiles baratos suelen tener un brillo justito. Si programas de noche, baja el brillo del principal para que no te deslumbre el segundo.
• Rotación: algunos modelos permiten pivotar a vertical. Para leer código largo, es una maravilla. Para ver vídeos, un desastre. Tú decides.

La reflexión: no era Linux, era el monitor

Terminé el proyecto con dos pantallas, cero drivers propietarios y una lección aprendida que me gustaría tatuarme: el problema no era Linux. Era elegir mal el hardware.

Durante años hemos aceptado que "Linux no soporta X" cuando en realidad X estaba diseñado para depender de software cerrado. DisplayLink es el ejemplo perfecto. No es que Linux no pueda con él; es que el fabricante decidió no facilitar la vida a quien no usa Windows o macOS.

La solución no fue parchear. Fue elegir mejor. Y eso, amigo mío, es una metáfora de la vida: a veces no hay que arreglar el problema, hay que cambiar de problema.

Si estás pensando en montarte un segundo monitor para programar en Linux, no te compliques. Busca USB-C con DisplayPort Alt Mode o HDMI. Huye de DisplayLink como de la peste. Y verifica tu puerto antes de comprar, no después.

Ahora te pregunto: ¿cuántos monitores tienes tirados en un cajón porque "en Linux no van"? ¿Y si el problema nunca fue Linux?