Ventilo à fond sous Linux :
l'enquête DisplayLink & dock USB-C
Deux écrans, un dock USB-C, un laptop sous Linux — et le CPU à 70°C dès le démarrage. Ce n'est pas un virus, pas un processus fou, pas un problème de configuration. C'est DisplayLink. Et derrière, un bug firmware qu'Acer ne corrigera jamais. Récit d'une enquête menée jusqu'à l'os.
// 01 — Le symptôme : 70°C et 66% de CPU pour de l'affichage
Tout fonctionne correctement. Les deux écrans sont allumés, le navigateur est ouvert, quelques onglets actifs. Et pourtant la soufflerie tourne à fond depuis le démarrage. Rien dans les logs. Pas de processus suspect. Juste le ventilo qui chante.
Premier réflexe :
DisplayLinkManager à 69%. Le coupable est immédiat.
DisplayLink, c'est la technologie derrière la grande majorité des docks multi-écrans connectés en USB. Son principe : puisqu'un port USB standard ne transporte pas de signal vidéo natif, DisplayLink compresse chaque frame en logiciel sur le CPU avant de l'envoyer sur le bus USB. C'est un encodeur vidéo permanent qui tourne en arrière-plan, tant qu'un écran est branché.
Ce n'est pas un bug. C'est le fonctionnement normal de DisplayLink. Deux écrans 1080p à 60 Hz représentent environ 4 Gbps de données brutes par seconde à comprimer. Le CPU fait le travail que le GPU ferait nativement. D'où les 66–69% de charge, les 70°C et le ventilo qui suit.
// 02 — xrandr : 100% DisplayLink, GPU inactif
La commande xrandr révèle exactement quelle sortie physique alimente quel écran.
Constat brutal : 100% de l'affichage passe par DisplayLink, alors que le GPU Intel dispose de trois sorties natives libres qui se tournent les pouces.
La solution logique serait d'activer le DP alt-mode sur le port USB-C du dock. En alt-mode, le connecteur USB-C négocie un canal DisplayPort natif — le GPU prend la main, DisplayLink sort de la boucle, charge CPU ≈ 0%. C'est exactement ce que feraient les sorties DP-1 et DP-2 si elles fonctionnaient.
// 03 — Le bug kernel : ucsi_acpi unknown error 0
Dans le journal de démarrage, une ligne discrète passe souvent inaperçue :
UCSI (USB Type-C System Interface) est le firmware de la puce qui gère
la négociation du port USB-C — c'est lui qui décide si le port fonctionne en data USB,
en Power Delivery, ou en DP alt-mode. L'erreur unknown error 0 indique
que ce firmware plante au démarrage, avant même que Linux puisse interroger les
capacités du port.
Conséquence directe : si l'UCSI est en erreur au boot, la négociation DP alt-mode ne peut pas aboutir. Le port USB-C transporte uniquement les données USB et le Power Delivery — jamais la vidéo. DisplayLink devient alors l'unique moyen d'afficher quoi que ce soit via le dock.
// 04 — Les cartouches tirées, une par une
Câble USB-C full-featured neuf
Un câble bas de gamme peut ne pas avoir les fils SBU (Sideband Use) et CC
(Configuration Channel) correctement câblés — lignes indispensables pour la
négociation DP alt-mode. Test effectué avec un câble certifié full-featured.
Résultat : DP-altmode: no, erreur UCSI toujours présente au boot.
Flip connecteur + power-cycle complet du dock
Débrancher, attendre 10 secondes, retourner le connecteur USB-C, rebrancher. Aucun effet sur le warning kernel.
Reset EC — bouton power 30 secondes
Shutdown complet, tout débranché (chargeur + dock), bouton power maintenu 30 secondes pour drainer les condensateurs et forcer l'Embedded Controller à repartir de zéro. Redémarrage avec le dock branché avant l'allumage. Même erreur au boot.
Reset EC — pinhole batterie
Sur les laptops à batterie intégrée, Acer prévoit un petit trou en dessous
du châssis (signalé par une icône batterie). Un trombone maintenu ~4 secondes
déconnecte électriquement la batterie — le reset EC le plus radical possible,
garantissant que la puce repart complètement de zéro.
Résultat identique : ucsi_acpi: unknown error 0 au prochain démarrage.
// 05 — La piste BIOS : fwupd et LVFS
La bonne pratique sous Linux pour les MAJ firmware, c'est fwupd et le dépôt LVFS (Linux Vendor Firmware Service). Lenovo, Dell, HP et d'autres y publient BIOS, firmware EC et firmware de dock — mise à jour propre en deux commandes, sans Windows.
Acer publie très peu sur LVFS pour ses gammes grand public. Et surtout : la version de BIOS installée est déjà la dernière disponible pour ce modèle. Le support firmware est terminé (gamme 2019-2020). L'erreur UCSI est dans la dernière version et n'a jamais été corrigée.
// 06 — Le downgrade BIOS : pourquoi c'est une impasse
L'idée vient naturellement : si la version actuelle est boguée, peut-être qu'une version antérieure était saine ? Réponse courte : non, pour trois raisons solides.
- Anti-rollback matériel. Acer bloque le downgrade sur ce modèle via des fusibles versionnés dans le firmware Insyde. L'updater renvoie Mismatch et refuse d'installer une version plus ancienne. Tenter de le forcer = flash hors-spec = risque de brique définitive.
- Aucune preuve que le bug soit une régression. Il n'apparaît dans aucun changelog Acer. Il a très probablement toujours été là — c'est un défaut de conception, pas quelque chose qui a été cassé lors d'une MAJ.
- Réouverture de CVE. Les BIOS de l'ère Ice Lake embarquent des patchs microcode Intel et Intel ME critiques. Un downgrade réouvre des vulnérabilités corrigées — inacceptable sur une machine de travail.
Règle absolue : ne jamais flasher un BIOS en downgrade sur un laptop à batterie intégrée sans support officiel du fabricant. Une brique après un flash = machine inutilisable, aucun recours.
// 07 — Bilan : toutes les pistes
| Tentative | Résultat |
|---|---|
| Câble USB-C full-featured neuf | ❌ DP alt-mode toujours inactif |
| Flip connecteur + power-cycle dock | ❌ |
| Reset EC — bouton power 30 s | ❌ |
| Reset EC — pinhole batterie (coupure franche) | ❌ |
| fwupd / LVFS | ❌ Acer absent de LVFS |
| MAJ BIOS Acer | ⚠ déjà en dernière version disponible |
| Downgrade BIOS | ❌ anti-rollback + risque brique + CVE |
| Forçage sysfs | ❌ lecture seule (UCSI) |
Conclusion : le bug est dans le firmware, il n'est pas corrigeable sur cette machine. Le DP alt-mode ne fonctionnera jamais entre ce laptop et ce dock. Ce n'est pas spécifique à Linux — c'est la puce UCSI qui ne négocie pas correctement, quel que soit l'OS.
// 08 — La solution : le port HDMI natif
La seule sortie vidéo native restante, c'est le port HDMI du laptop. Un câble HDMI, un écran branché en direct (pas via le dock) : le GPU Intel prend la main, DisplayLink sort complètement de la boucle pour cet écran.
Le bureau reste étendu sur les deux écrans. Le gestionnaire d'affichage (Cinnamon,
Gnome, KDE…) verra apparaître HDMI-1 comme nouvelle sortie — un tour dans
Paramètres → Affichage pour repositionner les écrans, mémorisé une fois pour toutes.
Règle d'usage : le contenu animé (navigateur, vidéo, terminal qui scrolle) sur l'écran HDMI natif. DisplayLink ne paie en CPU que les pixels qui changent — un écran statique (doc, mail, monitoring) sur le dock ne génère quasiment aucune charge.
// Ce qu'on retient
DisplayLink = CPU, toujours. Ce n'est pas un bug, c'est le protocole. Dès qu'on peut court-circuiter avec une sortie GPU native, on le fait — même un seul écran en natif divise la charge par deux.
xrandr avant tout diagnostic d'affichage. La commande
donne en 2 secondes la carte complète des sorties : lesquelles sont evdi
(DisplayLink, CPU), lesquelles sont natives (Intel/AMD/NVIDIA, GPU). C'est le
point de départ indispensable.
Les bugs UCSI firmware existent et peuvent être définitifs. Sur un laptop dont le support est terminé et qu'Acer n'a pas publié sur LVFS, les options s'épuisent vite. Mieux vaut le savoir proprement — toutes les pistes testées, documentées — plutôt que de tourner en rond pendant des mois.
Ne jamais tenter un downgrade BIOS sur un laptop à batterie intégrée sans support officiel du fabricant. Le risque de brique est réel et définitif, et les chances que ça règle un bug de conception sont proches de zéro.