La sortie de la version stable 2.6.39 du noyau Linux
Par Gisles le jeudi 19 mai 2011, 18:32 - - Actualité - - Lien permanent
La sortie de la version stable 2.6.39 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.
Le sous-system "Media controller" l'API de Video4Linux a été réécrit et il est complémentaire d’ALSA et de V4L2.
Media-controller
Le sous‐système « media controller », qui constitue un complément de l’API classique Video4Linux, a été ajouté dans le noyau 2.6.39.
Écrit par Laurent Pinchart, ce nouveau sous‐système ambitionne de simplifier le travail des applications qui utilisent les périphériques audio ou vidéo de la machine. En effet, il a été constaté ces dernières années que les puces devenaient de plus en plus complexes et qu’elles intégraient de plus en plus de fonctions. Ce sont maintenant de véritables SoC (Systems-on-a-Chip) qui sont embarqués dans les webcams ou dans les cartes d’acquisition et de sortie vidéo. L’API spécialisée Video4Linux (V4L) a déjà été réécrite au moment de la série des noyaux 2.5.x, afin de permettre de gérer — entre autres — la compression matérielle. Cette interface de programmation de seconde génération (V4L2) a fidèlement servi les auteurs de pilotes, mais elle commence — elle aussi — à montrer ses limites. L’article de LWN dédié au sous‐système « media controller » cite l’exemple de la puce OMAP 3430 qui est utilisée dans les téléphones Nokia N900. Cette puce est en effet représentative de la complexité ahurissante qui caractérise les périphériques vidéo modernes. Outre le classique processeur ARM et les blocs spécialisés dans le codage / décodage matériel de divers formats, on y trouve également un ISP (image signal processor) très sophistiqué. Divers formats vidéo sont acceptés en entrée, et la compression JPEG, ainsi que la balance des blancs, se font à la volée directement dans la puce. Pour pallier les défauts des lentilles, qui sont souvent minuscules, un processeur spécialisé corrige les distorsions géométriques de l’image, etc..
Chacun de ces composants spécialisés constitue pour le noyau un périphérique qui doit être géré spécifiquement. De plus, la gestion de ces périphériques doit souvent être partagée avec d’autres sous‐systèmes (pensons à ALSA pour le son d’une webcam, par exemple) ce qui ajoute de la complexité. Toutes ces fonctions présentes sur les SoC devraient pouvoir être facilement accessibles par les applications résidant en espace utilisateur. Pour cela, le noyau doit être capable de présenter simplement les caractéristiques de tous les périphériques média… Mais cette contrainte devient de plus en plus difficile à tenir par l’API V4L2 qui n’a pas vraiment été conçue pour ça.
Le sous‐système « media controller » va donc permettre aux applications en espace utilisateur de découvrir et de contrôler les divers périphériques spécialisés présents sur la machine. Pour cela, ces périphériques sont représentés dans un graphe orienté de tous les blocs média (nommés « entities ») et qui sont connectés par des relations (nommées « pads »). La nouvelle structure « media_device » accueille les diverses descriptions des « entities » qui peuvent prendre la forme de périphériques audio, de processeurs de mise au point pour les images, de blocs vidéo, de capteurs CCD ou CMOS, de blocs DMA, etc.. Ces « entities » vont être connectées entre elles par des relations « pads », et le flot de données transite simplement depuis un pad de type « source » vers un pad de type « sink ». On voit bien que cette architecture générale fait penser aux pipelines de GStreamer qui utilisent, eux aussi, ces notions de sources, pads et sink. La phase de découverte et de caractérisation de la topologie des périphériques se fait dynamiquement à chaud, et il est possible d’assigner un numéro de groupe à certaines des entités afin d’indiquer qu’elles fonctionnent ensemble. Par exemple, on peut indiquer que le capteur CMOS, la puce intégrée de correction d’image, ainsi que le microphone, qui sont tous les trois présents dans une webcam font partie d’un même groupe. Laurent Pinchart a indiqué dans ses e‐mails sur la LKML que les versions successives de ses patches avaient été scrutées de près par les divers responsables du noyau :
Le code a été passé en revue en profondeur par la communauté V4L. Cette nouvelle version est la première à incorporer des commentaires issus de la communauté ALSA.
Pilotes graphiques
Le noyau 2.6.39 intègre pour la première fois dans sa branche -staging un pilote psb_gfx dédié à la puce graphique GMA500 (plus connue sous le nom de Poulsbo). Le pilote est développé directement par Alan Cox et, même s'il ne dispose pas encore de la 3D accélérée et n'utilise pas les moteurs vidéos matériels de la puce, le code gère le framebuffer ainsi que la 2D. Comme l'explique Kristoffer Ericson le pilote est stable et, si vous n'avez pas besoin de l'accélération 3D, il constitue une alternative tout à fait réaliste à l'ignoble blob binaire d'Imagination Technologies.
Du côté d'AMD peu de nouveautés à noter hormis les patchs de prise en charge des puces HD 6900 (Cayman) et d'activation du tiling pour les puces R600 qui entrent dans le noyau.
Le pilote Nouveau offre maintenant la z-compression c'est-à-dire que les données sur la profondeur sont stockées en mode compressé dans un tampon mémoire spécifique (le z-buffer). Cela permet de savoir si il faut vraiment afficher le pixel ou si ce n'est pas nécessaire parce qu'il est masqué. La technique du « page flipping » est également ajoutée au pilote Nouveau du noyau 2.6.39. Avec cette technique on utilise deux tampons pour la vidéo, l'un qui est affiché sur l'écran (front buffer) tandis que l'autre se remplit (back buffer). Au moment opportun, on bascule d'un tampon à l'autre avec un pointeur ce qui évite de copier des données (qui a pensé aux sprites ?). Enfin la correction d'un problème de performances permet de gagner d'un seul coup entre 10 et 30% d'images par seconde en plus par rapport aux noyaux précédents.
Pour en terminer avec les pilotes graphiques, en ce qui concerne Intel, on relève plusieurs patchs améliorant la gestion de la puce graphique présente dans le processeur Sandy Bridge (20% de performances en plus dans Nexuiz). Le pilote i855 a également été complètement revu et nettoyé.
Il n’y a pas de concurrence, puisque « media controller » est complémentaire d’ALSA et de V4L2, et n’a pas du tout l’ambition de les remplacer. Pour l’instant — comme souvent avec l’introduction d’une nouvelle API — l’option de configuration « MEDIA_CONTROLLER » est encore marquée comme expérimentale.
Du côté des applications, il est bien sûr possible d’interroger finement le sous‐système « media controller » pour se renseigner sur les capacités matérielles de la machine. Cela se fait via des appels ioctl aux noms explicites comme « MEDIA_IOC_DEVICE_INFO » ou « MEDIA_IOC_ENUM_ENTITIES » ou encore « MEDIA_IOC_ENUM_LINKS ». Les applications peuvent changer les liens entre les « entities », via un appel à « MEDIA_IOC_SETUP_LINK ». Le premier pilote à utiliser ce sous‐système « media controller » est l’ISP OMAP3, mais il ne fait aucun doute que de nombreux pilotes vont bientôt utiliser cette nouvelle infrastructure moderne présente dans le noyau Linux.