Le Dell Latitude 7320 Detachable est sorti en 2021 avec une puce Intel Tiger Lake et une caméra avant de 5 mégapixels qui n'a jamais fonctionné sous Linux. Des correctifs publiés cette semaine sur la liste linux-media la réparent, et la raison des cinq ans d'attente est la partie intéressante : le capteur porte la référence OV5678, une pièce sans documentation Linux publique, et personne n'avait vérifié s'il s'agissait en réalité d'autre chose. Sahan Nissanka l'a fait, a constaté qu'il renvoie l'identifiant d'un OV5675, et a écrit trois petits correctifs autour de cette découverte. Nous avons repris la méthode, car elle se transpose à d'autres portables IPU6.
The short answer
Le Dell Latitude 7320 Detachable, machine Intel Tiger Lake de 2021, a une caméra avant inerte sous Linux depuis sa sortie, parce que son capteur porte la référence OV5678 et qu'aucune documentation Linux n'existe pour cette pièce. Sahan Nissanka a lu le registre d'identification de la puce et a constaté qu'elle renvoie 0x005675, l'identifiant de l'OV5675 déjà pris en charge. Le SSDB ACPI a confirmé la correspondance électrique : deux voies de données CSI-2 et une horloge externe à 19,2 MHz. Trois correctifs sur la liste linux-media ajoutent les données de carte TPS68470, l'identifiant du capteur et la configuration ipu-bridge. La caméra avant de 5 mégapixels fonctionne. La couleur reste imprécise en attendant la prise en charge RGB-IR dans V4L2, et la caméra arrière demeure inerte.
Il existe une catégorie de bogue open source dont la difficulté n'a jamais été technique. Celui-ci est resté ouvert cinq ans parce que tout le monde a cru l'étiquette collée sur la pièce.
Cinq ans d'hypothèse
Le Latitude 7320 Detachable est arrivé en 2021 avec un processeur Tiger Lake de onzième génération et une caméra avant de 5 mégapixels en 2592 par 1944. Sous Windows elle fonctionnait. Sous Linux elle ne produisait rien, et elle n'a rien produit depuis. Les demandes de prise en charge remontent à 2022, et le suivi de bogues des pilotes IPU6 d'Intel porte depuis longtemps un ticket ouvert demandant simplement l'ajout du capteur OV5678.
Le raisonnement derrière ce blocage était solide, et c'est ce qui le rend instructif. Le capteur est référencé OV5678. Il n'existe aucune documentation de pilote Linux publique pour un OV5678. Écrire un pilote de capteur à partir de rien, pour une pièce non documentée, représente un vrai travail que personne n'a proposé de faire. Le bogue est donc resté ouvert.
Ce que personne n'a fait, c'est se demander si l'OV5678 était bien un capteur distinct.
Lire la pièce plutôt que l'étiquette
Sahan Nissanka, travaillant seul sur le sujet, a vérifié. Les capteurs s'annoncent : il existe un registre d'identification de puce, et sur cette famille il se trouve à l'adresse 0x300a. La pièce du Latitude 7320 renvoie 0x005675.
C'est l'OV5675. Linux dispose d'un pilote pour l'OV5675 depuis des années, présent dans l'arbre depuis le début.
Un identifiant qui correspond reste un indice plutôt qu'une preuve, car un pilote doit aussi obtenir la bonne configuration électrique. Deux paramètres comptent avant tout : le nombre de voies de données CSI-2 qui relient le capteur à l'unité de traitement d'image, et la fréquence d'horloge externe du capteur. Une erreur sur l'un ou l'autre donne une image noire ou corrompue.
Les deux étaient disponibles sans toucher au matériel. Les tables ACPI de la machine portent un tampon SSDB décrivant la liaison du capteur, et sa lecture avant toute mise sous tension a donné deux voies de données CSI-2 et une horloge externe à 19,2 MHz. Ce sont exactement les valeurs qu'attend le pilote ov5675 existant.
Ce que changent les correctifs
La série compte trois correctifs et aucun n'est un nouveau pilote, ce qui est tout l'intérêt.
Le premier ajoute les données de carte du TPS68470, le circuit de gestion d'alimentation qui fournit les tensions et l'horloge du capteur. C'est la pièce qui doit être juste en premier, car un capteur mal alimenté et mal cadencé ne peut répondre à rien.
Le deuxième ajoute l'identifiant du capteur au pilote ov5675 existant, afin qu'il s'attache à une pièce livrée sous un autre nom.
Le troisième configure ipu-bridge, le composant du noyau qui construit les liens média logiciels entre la caméra décrite par l'ACPI et l'unité de traitement d'image Intel IPU6.
Ensemble, ils raccordent un pilote existant à un matériel qu'il a toujours été capable de piloter.
Deux choses manquent encore
La caméra tournée vers l'utilisateur fonctionne désormais. Deux réserves doivent accompagner cette phrase.
La couleur n'est pas juste. Le capteur utilise une matrice de filtres colorés RGB-IR, réservant certains pixels à l'infrarouge plutôt qu'à la couleur visible. Traiter cela correctement demande que V4L2 prenne en charge les codes de bus média RGB-IR concernés, et tant que ce n'est pas fait la restitution des couleurs restera décalée. Pour un appel visio, l'image est utilisable. Pour tout usage où la couleur compte, elle ne l'est pas.
La caméra arrière reste éteinte. L'activer dépend de la résolution de sa configuration GPIO, problème distinct que cette série ne touche pas.
La méthode est la partie transposable
Si vous gérez un parc de portables de l'ère IPU6 aux caméras mortes, ou si une seule machine vous agace, l'approche employée ici mérite d'être copiée car elle ne coûte presque rien à tenter.
Partez des tables ACPI plutôt que de la référence sur la fiche technique. Extrayez-les, trouvez le périphérique caméra, et lisez son tampon SSDB pour obtenir le nombre de voies CSI-2 et la fréquence d'horloge externe. Ce sont les valeurs auxquelles un pilote de capteur est le plus sensible, et vous les obtenez sans alimenter le capteur ni écrire une ligne de code.
Lisez ensuite le registre d'identification de la puce et comparez la réponse aux pilotes déjà présents dans drivers/media/i2c. Les fabricants de capteurs rebaptisent et reclassent des pièces par habitude. Une référence sans documentation Linux vous apprend que personne n'a écrit de documentation sous ce nom, et rien de plus.
Cinq ans de caméra morte, réglés en lisant un registre et en comparant la réponse à un pilote déjà présent dans l'arbre. Cela vaut la peine de vérifier l'hypothèse avant d'accepter le travail.
Sources et pour aller plus loin
- Dell Latitude 7320 2-in-1 Seeing Web Camera Support On Linux After Five Years, Phoronix, 9 août 2026
- Add support for OV5678 sensor, ticket 24 du dépôt intel/ipu6-drivers sur GitHub
- TPS68470 missing board-data for MSI Prestige 14 AI+ Evo, ticket 414 du dépôt intel/ipu6-drivers sur GitHub
- PATCH v4 0/3 TPS68470 PMIC drivers, liste de diffusion du noyau Linux
- Working OV5670 front-camera support on the Dell Latitude 5290 2-in-1 under Linux
Questions fréquentes
Qu'est-ce qui n'allait pas, si le matériel était bon ?
Rien n'allait mal côté matériel. Le problème était un défaut d'identification. Le Latitude 7320 Detachable embarque un capteur référencé OV5678, et aucune documentation de pilote Linux publique n'existe pour cette référence, si bien que l'hypothèse pendant cinq ans a été que le prendre en charge supposait de rétro-concevoir un capteur non documenté. Cette hypothèse n'a jamais été testée. Sahan Nissanka a lu le registre d'identification de la puce à l'adresse 0x300a et a constaté qu'elle renvoie 0x005675, l'identifiant de l'OV5675, un capteur pour lequel Linux dispose d'un pilote depuis longtemps. Restaient deux questions : la configuration électrique correspondait-elle à ce qu'attend le pilote existant. Les tables ACPI ont répondu aussi : deux voies de données CSI-2 et une horloge externe à 19,2 MHz, lues dans le SSDB de la machine avant même toute mise sous tension, et conformes à ce que suppose ov5675.c.
Que font réellement les trois correctifs ?
Ils sont courts, et chacun comble un maillon différent de la chaîne entre le capteur et l'espace utilisateur. Le premier ajoute les données de carte pour le circuit de gestion d'alimentation TPS68470, la puce qui fournit les tensions et l'horloge du capteur. Sans données de carte correctes, le capteur n'est jamais alimenté ni cadencé correctement, et rien en aval ne peut fonctionner quel que soit le pilote disponible. Le deuxième ajoute l'identifiant du capteur au pilote ov5675 existant afin que celui-ci s'attache à une pièce qui s'annonce sous un autre nom commercial. Le troisième configure ipu-bridge, le composant du noyau qui construit les liens logiciels entre la caméra décrite par l'ACPI et l'unité de traitement d'image Intel IPU6, pour que la chaîne soit correctement câblée. Aucun n'est un nouveau pilote. Les trois sont de la plomberie autour d'un pilote déjà présent.
La caméra fonctionne-t-elle parfaitement désormais ?
La caméra tournée vers l'utilisateur fonctionne, ce qui change vraiment par rapport à rien du tout, mais deux réserves méritent d'être connues avant de se réjouir. La première concerne la couleur. Le capteur utilise une matrice de filtres colorés RGB-IR, c'est-à-dire que certains pixels sont dédiés à l'infrarouge plutôt qu'au rouge, au vert ou au bleu. Traiter cela correctement suppose que V4L2 prenne en charge les codes de bus média RGB-IR appropriés, et tant que ce n'est pas le cas la restitution des couleurs restera imprécise. L'image convient à un appel visio, elle n'est pas fidèle en couleur. La seconde réserve est que tout ceci ne couvre que la caméra avant. La caméra arrière de la tablette détachable reste non prise en charge, en attente d'un travail sur sa configuration GPIO, problème distinct de celui qui vient d'être résolu.
Comment vérifier si mon propre portable est dans le même cas ?
La méthode se transpose et ne coûte rien à tenter. Partez des tables ACPI plutôt que du nom commercial, car c'est précisément ce nom qui a égaré tout le monde ici. Extrayez vos tables ACPI et cherchez le périphérique capteur et son tampon SSDB, qui porte les paramètres électriques : le nombre de voies de données CSI-2 et la fréquence de l'horloge externe. Ces deux valeurs sont celles auxquelles un pilote de capteur est le plus sensible, et vous pouvez les lire sans rien alimenter. Comparez ensuite l'identification de puce renvoyée avec les pilotes déjà présents dans drivers/media/i2c. Les fabricants de capteurs rebaptisent et reclassent des pièces couramment, et une référence sans documentation Linux ne prouve pas qu'il s'agit d'un nouveau capteur, seulement que personne n'a vérifié. C'est toute la leçon de cette série de correctifs.
Pourquoi Intel IPU6 rend-il les caméras Linux si difficiles en général ?
Parce que l'IPU6 répartit le travail d'une manière qui suppose une pile en espace utilisateur dont Linux a longtemps été dépourvu. Sur les conceptions plus anciennes, une webcam UVC se présentait comme un périphérique vidéo USB ordinaire et le noyau remettait à l'espace utilisateur une image finie. Les portables IPU6 exposent au contraire un capteur brut relié en CSI-2 à une unité de traitement d'image, et la conversion de la sortie brute en image exploitable se fait en partie dans le micrologiciel et en partie en espace utilisateur. Une caméra fonctionnelle exige donc plusieurs pièces alignées en même temps : un pilote de capteur, des données correctes pour la puce de gestion d'alimentation, une description ACPI de la liaison, ipu-bridge pour construire les liens, la pile de pilotes IPU6 elle même, et un consommateur en espace utilisateur qui comprend la chaîne. La moindre pièce manquante produit le même symptôme, une image noire, d'où la lenteur du diagnostic.