Depuis la sortie de Xorg 7.4, un chemin considérable a été parcouru. Entre l'intégration de XRandR 1.3 et ses déformations de projection, en passant par MPX pour le multi-pointage, sans parler des évolutions diverses, remaniement de code et autre intégration, le travail effectué est considérable. Il est surtout intéressant de noter, pour les plus courageux et curieux d'entre vous, qu'on nous promet enfin des versions à date fixe et un cycle de développement bien encadré, permettant au plus grand nombre de tester et stabiliser les fonctionnalités de cette partie vitale de votre système libre.
Avec un peu de retard, mais en français, voici des informations sur la nouvelle version de Xorg (7.5) et du xorg-server (1.7), ainsi que quelques nouvelles sur l'avancement des pilotes et ce que l'on peut attendre, dans un futur plus ou moins proche. La dernière version 7.4 de Xorg datait de septembre 2008 et était principalement consacrée à la stabilisation, malgré l'ajout de quelques fonctionnalités et surtout un travail de fond et de nettoyage par le remplacement de certains éléments par d'autres plus récents. Elle introduisait la version 1.5 du xorg-xserver, xtrans et un travail sur la manière de scanner et accéder au bus PCI. Un an et un mois plus tard, c'est-à-dire fin septembre 2009, à peu près en même temps que la X Developper's Conference 2009 (XDC2009) à Portland, Xorg 7.5 pointait le bout de son nez, suivi du xorg-xserver 1.7 (1er octobre 2008, suivi du 1.7.1 prévu pour le 22 octobre).
Le passé récent
Entre-temps, de nombreuses évolutions intégrées dans la version 1.6 du xorg-xserver (février 2009) furent rendues accessibles. Je pense notamment à la plus visible, XRandR 1.3, XInput 1.5 qui a introduit les propriétés des périphériques (IDP) et DRI2, une extension légère, mais nécessaire à DRI (Direct Rendering Infrastructure), qui permet l'accélération des fenêtres de redirections. On notera surtout la disparition (non regrettée) de Xgl et Xptr qui n'auront plus de prise en charge de la part de la fondation. xorgconfig, xorgcfg, ioport, kbd_mode font également leurs valises, surtout dû au fait qu'ils sont désormais inutiles.
XRandR 1.3
XRandR (X Resize and Rotate) est un utilitaire qui est venu pallier un gros manque lors de la conception de X, qui demandait alors un redémarrage du serveur pour modifier la résolution de l'écran. Au fil des versions, cet utilitaire s'est enrichi de nombreuses options, le rendant indispensable pour la gestion de plusieurs écrans. Il est surtout très utilisé lors de l'utilisation de vidéoprojecteur, qui sont souvent branchés de manière dynamique et avec des résolutions pas forcément connues à l'avance. La version 1.3 propose deux nouvelles options, les transformations de projection et la prise en charge du panoramique. Alors que RandR, pour Resize (redimension) and Rotate (rotation), était spécialisé dans ces deux opérations à l'origine de son nom, les développeurs ont décidé d'aller plus loin. Avec les transformations de projections, on modifie directement le tampon d'image à afficher. Cela permettra d'avoir une correction plus fine des distorsions qui peuvent par exemple, être provoquées par un rétro-projecteur, comme une mauvaise mise à l'échelle ou une déformation de l'image.
La gestion du panoramique (Panning), quant à lui, permet à l'écran de suivre le curseur si l'affichage est plus petit que la taille de l'écran virtuel sélectionné. Pour plus de détails, il est possible de visionner la vidéo disponible sur Phoronix (voir lien).
xorg-server 1.7
XInput 2: Intégration de MPX
Avant de parler de XInput 2 (XI2), il faut voir son intérêt et le premier, c'est d'intégrer MPX (déjà présent depuis XInput 1.5) directement dans le serveur et plus comme simple extension. Certes, cela semble bien, mais au fait, c'est quoi MPX ? MPX, pour MultiPointeur X, c'est ce qui va permettre à Xorg de prendre en charge de manière optimale de multiples entrées identiques (plusieurs souris, plusieurs claviers, etc.). Certes, il était déjà possible de brancher un deuxième clavier sur son ordinateur ou une deuxième souris, et Xorg le gérait parfaitement. La différence, c'est le focus, ou plus exactement, le flux de sortie. Avant, les applications n'avaient droit qu'à un unique flux par périphérique d'entrée. Si on tape avec deux claviers, le résultat est un unique flux de données. Maintenant, grâce à MPX, nous avons deux flux séparés que l'on peut traiter indépendamment. Vous comprendrez immédiatement l'intérêt pour le tactile multi-points ou tout simplement avec des souris multiples. Au lieu d'avoir un unique pointeur contrôlé par deux souris, nous avons deux pointeurs indépendants.
Problème – mais pas des moindres – cela oblige bon nombre d'applications, voire des boîtes à outils logicielles (toolkits), d'être réécrites pour tirer parti de cette spécificité.
Au niveau implémentation, XI2 utilise une notion hiérarchique de maître/esclave pour les périphériques. Il existe les périphériques maîtres qui représentent ce qui se passe à l'écran (pointeur, flux clavier) et les périphériques esclaves, qui représentent les périphériques physiques (clavier et souris). Un esclave s'attache ainsi à un périphérique maître. Lorsqu'un périphérique physique transmet une information, elle est donnée au périphérique maître qui retransmet au client. Les périphériques maîtres vont toujours par paire, avec un périphérique dédié au pointage et un autre aux flux de caractères. Il est possible d'attacher plusieurs esclaves au même maître. C'est même la configuration par défaut dans XI2. De fait, par défaut, nous n'avons qu'un couple de périphériques maîtres auxquels sont attachés les périphériques esclaves. Pour ceux qui suivent ce qui est écrit, cela veut juste dire que, par défaut, XI2 a le même comportement concernant les entrées multiples que l'ancien serveur et que l'ensemble est invisible, aussi bien pour les applications que pour les utilisateurs. Magique ! De ce fait, XI2 reste extrêmement conservateur et n'ajoute que quelques requêtes et événements, mais il est construit et déjà prévu dans une optique d'extensibilité.
En sus, XI2 profite du travail déjà présent dans xorg-xserver 1.7 en ce qui concerne les propriétés des périphériques. Ainsi, il est possible pour le serveur d'avoir accès à ces propriétés et d'avoir une meilleure compréhension du matériel attaché, et des possibilités de ce dernier. [http://who-t.blogspot.com/2008/07/input-device-properties.html]
Parmi les autres nouveautés, on notera la prise en charge des keycodes (identifiants des touches) de 32 bits. Avec les claviers actuels, il arrive que certaines touches renvoient un identifiant sur 32 bits, en particulier dans le cas des touches multimédia. L'ancien serveur ne pouvait ainsi pas les gérer de manière correcte.
Enfin, depuis le xserver 1.6, nous avons une toute nouvelle méthode d'accélération du pointeur, palliant les nombreuses déficiences du précédent modèle. Parmi les problèmes corrigés, une accélération constante selon l'angle (actuellement, l'accélération est plus rapide en diagonale par exemple), et la gestion des sous-pixels pour le placement des pointeurs.
Configuration de l'écran, introduction de l'E-EDID
Une autre nouveauté, c'est la gestion de l'E-EDID, pour Extended-Extended display identification data, utilisé par un grand nombre de périphériques. L'E-EDID est une extension du format EDID qui permet au moniteur de donner des informations à la carte graphique sur ses propres possibilités. Datant de 2006, ce format est disponible dans un très grand nombre d'équipements grand public et est utilisé par le HDMI (1.0 au 1.3c). Malgré le remplacement, dans un futur plus ou moins proche de ce standard par le DisplayID, plus complet et permettant de couvrir l'ensemble de l'électronique grand public et des moniteurs PC, il faut noter que son inclusion permet de tirer parti des équipements actuels de manière optimale. Mieux vaut une implémentation pour gérer des éléments existants qu'une implémentation pour des éléments qui vont exister.
Petites retouches...
D'autres modifications ont été apportées dans certains sous-systèmes spécifiques, comme la suppression de la dépendance envers MESA pour la construction du xorg-server, ainsi que l'ajout d'un module de sécurité hérité de SELinux avec XACE. De plus, certains modules et autres extensions non maintenus et obsolètes ont été marqués comme dépréciés.
Et le futur ?
Imiter Linux avec des versions à date fixe
Peter Hutterer a proposé de revoir le processus de livraison de xorg pour la prochaine version. Il cite trois problèmes récurrents actuellement :
- Une planification imprévisible,
- trop de développement en cours dans le dépôt Git principal, ce qui laisse fréquemment l'ensemble cassé et inutilisable,
- ainsi qu'un cycle de test trop court qui arrive souvent trop tard dans le processus de livraison.
Il propose ainsi de revoir le processus actuel, et de travailler les nouvelles fonctionnalités dans des branches séparées (au lieu de patchs qui peuvent casser le serveur, comme c'est le cas actuellement). Pour chaque nouvelle version, il propose un cycle de trois mois pour l'inclusion de nouvelles fonctionnalités dans la branche principale, puis deux mois de chasses aux bugs, suivi d'un mois de tests pour la stabilisation en vue de la livraison et durant lequel seulement les changements et corrections de bugs cruciaux seront admis. Ainsi, il y aura une livraison tous les 6 mois, et un environnement plus simple pour les testeurs.
Le résultat sera dans tous les cas une base plus mûre, plus stable, plus prévisible et de ce fait, plus simple à tester, ce que réclament depuis longtemps les testeurs, peu nombreux du fait des risques (dans le fonctionnement actuel) de tester l'ensemble.
Enfin, il est étudié le fait d'introduire les sources des pilotes directement dans le tronc commun.
Tour rapide de la XDC2009
- Explication du travail en cours sur la compression du framebuffer, la modification de fréquence du processeur graphique et de la mémoire pour gagner en autonomie, avec un gain pouvant aller jusqu'à 15W ;
- La question des brevets sur certaines fonctionnalités de l'OpenGL3 et donc du problème d'intégration dans MESA a été posée. Elle touche certains formats de compression en particulier. L'utilisation d'une option de compilation comme pour freetype a été évoquée ;
- Les shaders dans MESA sont un problème, NVidia ayant une gestion complète – mais propriétaire – des shaders et dont la pérennité n'est pas assurée. Il faut une manière plus générique d'y avoir accès ;
- Intel : XvMC géré pour les nouveaux chipset. Ainsi qu'un travail important sur l'OpenGL.
- AMD : Les pilotes 3D pour R600 et R700 arrivent. Compiz est entièrement fonctionnel. La prise en charge des R800 arrive aussi. XvMC est déjà présent et actif pour les R300 à R500 et en cours de finition pour les R600 et R700. Pas mal de travail sur KMS a aussi été fait. [http://www.botchco.com/agd5f/] ;
- Wayland avance lentement mais sûrement. Ce nouveau serveur d'affichage, concurrent de Xorg, est aussi beaucoup plus simple, tout en restant très puissant.
Aller plus loin
- Annonce d'origine (2 clics)
- XRandR 1.3 sur phoronix (4 clics)
- E-EDID (2 clics)
- Information sur MPX (2 clics)
- Programmation XI2 (3 clics)
- Accélération du pointeur (2 clics)
# patrick_g ?
Posté par Joël . Évalué à -10.
[^] # Re: patrick_g ?
Posté par logik . Évalué à -7.
[^] # Re: patrick_g ?
Posté par Victor STINNER (site web personnel) . Évalué à 7.
http://lwn.net/Articles/355821/
# Aurait-tu un lien de parenté...
Posté par logik . Évalué à -4.
Tellement il est agréable de lire des dépêches sur les "pilier" telles que le kernel, xorg, etc.. avec une description sur chaque nouveautés.
Merci de cette excellente dépêche en tout cas!
# Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par Skunnyk (site web personnel) . Évalué à 10.
Par contre sur le site de x.org, il n'y a pas mention de la sortie de xorg 7.5, c'est dommage ... Je trouve qu'il manque un peu de communication sur le site ! (la dernière news datant de fevrier :/).
On peut noter la sortie de mesa 7.6 (http://www.mesa3d.org/relnotes-7.6.html) il y a environ 2 semaines, qui commence à implementer Gallium (je crois que c'est depuis la 7.5).
Ah, et un Xorg qui sort tout les 6mois ? Tout le monde gueule sur le fait que M.Shuttleworth veut synchroniser les sorties, et hop, tout les 6mois pour X ! Encore un complot !!
Je ne connaissais pas du tout Wayland, qui d'après wikipedia est un remplaçant à X11 (carrement !), et n'est pas vraiment concurrent vu qu'il est aussi chez freedesktop. Affaire à suivre !
Au passage, pour les interessés, un article sur les 25ans de X sur l'excellent lwn : http://lwn.net/Articles/354408/ , qui fait un résumé de toutes les erreurs et les évolutions du protocole
J'y ai découvert une résurrection de W (avant X pour ceux qui suivent), il y a même des gens qui l'utilisent encore (enfin, pour s'amuser je pense ;)): http://koti.mbnet.fi/tammat/open.shtml#wws (paquets debian toussa)
Petite boulette dans la dépêche: 'suivi du xorg-xserver 1.7 (1er octobre 2008, suivi du 1.7.1 prévu pour le 22 octobre' => Octobre 2009 non ? :-)
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par Skunnyk (site web personnel) . Évalué à 3.
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par monde_de_merde . Évalué à 10.
Wayland est fonctionnellement destiné à être un remplaçant de Xserver, mais s'en est surtout une énorme simplification.
Le premier point c'est qu'il s'agit d'un serveur graphique qui devrait accomplir certaines choses en recourant directement aux dernières technologies introduites récement (GEM, TTM-GEMisé, DRM etc...). Sur cet aspect la pile Xorg supporte aussi d'anciennes méthodes de rendu.
Le second point, c'est que Wayland ne prend pas en charge à l'heure actuelle certains aspects du protocole X11 (qui est véritablement monstrueux) alors que la pile Xorg le prend plus moins en charge intégralement. En se concentrant sur l'essentiel Wayland est encore uen fois plus simple et plus rapide.
Enfin, Wayland redéfinit une API différente de notre Xorg, et comme incidemment il se trouve que l'on a fait des progrès en conception d'api et que l'on a appris des erreurs commises par le passé il est aussi plus simple à cet égard là.
L'un des désavantages de cette approche c'est qu'il est nécessaire de réécrire les back-ends des librairies graphiques actuelles pour qu'elle puisse être rendue par Wayland plutôt que par Xserver. Actuellement QT, GTK+, Clutter etc... usent de Xlib pour l'affichage. Le travail est en cours pour Clutter (d'aucun y verront un effet de mode, openGL tout ça...) et il était prévu de le faire aussi pour GTK+, peut être même que cela a commencé.
Je ne sais donc pas s'il est possible de vraiment essayer Wayland, mis à part lui faire héberger un Xserver ou un terminal.
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par bubar🦥 (Mastodon) . Évalué à 7.
http://linuxfr.org//comments/982935.html#982935
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par Tiwaz . Évalué à 10.
Merci pour le lien de l'article sur lwn.net (inscription trop récente) sur l'évolution de Xorg, je l'avais manqué. Il est en effet très intéressant.
Je n'ai pas voulu trop en faire sur le 3d et gallium, mon temps n'est pas indéfini ;-) . Pourquoi pas pour une prochaine dépêche. Les projets, tels que Wayland sont également très intéressant.
Et merci pour tous vos commentaires.
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par dest . Évalué à 8.
Bref, j'en redemande !
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par FluffyHamster . Évalué à 2.
Comme çà on peut utilisé l'accélération matériel sans trop de problème, tout fonctionne en direct rendering et il me semble qu'il n'y a pas de mode de fonctionnement client/serveur.
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par Littleboy . Évalué à 10.
C'est "juste" un serveur d'affichage et un compositeur (sous forme de module charge par Wayland).
Il faut bien voir que c'est juste une toute petite partie de la pile d'affichage. Le developpeur a decide de se concentrer sur la partie gestion de l'affichage & composition et de le faire bien et en utilisant les outils/API modernes.
Si ca doit un jour remplacer X, il faudra de toute facon avoir une couche au dessus pour gerer la transparence reseau, etc...
FAQ (en anglais): https://groups.google.com/group/wayland-display-server/web/f(...)
Note: on voit "A new X-Server" partout dans les recherches Google sur Wayland parce que les types de phoronix ont decide de faire un article avec un titre sensationnel dessus, mais c'est du grand n'importe quoi...
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par monde_de_merde . Évalué à 3.
(et c'est vrai que parfois ça tire un peu sur le sensationnalisme et c'est bien dommage...)
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par Joël SCHAAL . Évalué à -5.
Le contenu contient souvent juste ce qu'il faut de technique pour bien comprendre le sujet et permet de se tenir informé grâce à une actualité traitée en continu (d'autant qu'elle est assez riche sur les pilotes graphiques, c'est peut être ce qui me fourvoie)
Et puis ceux qui n'aiment pas la mise en page ou alors l'incorporation des publicités, testez la version Premium (bon, c'est sûr faut avoir une 20aine d'€ à mettre...) ! J'y suis et je ne regrette pas du tout.
D'ailleurs je trouve que LinuxFR pourrait avoir un système équivalent : - De base, accès à tout mais avec Pub, sans possibilité de choisir sa feuille de style,
- et d'un autre coté, un accès 'VIP', avec une cotisation honnête (du genre quelques €/mois, avec un tarif dégressif sur 3,6 ou 12 mois) où l'on a accès à tout.
Je crois qu'il y avait déjà eu une news sur ce sujet (désolé pour le HS d'ailleurs...) mais je ne sais pas si ce point avait déjà été débattu.
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par reno . Évalué à 2.
Comme J'ai une question:
-Compiz est un gestionnaire de fenetre qui 'compose' les fenetres.
-Wayland est un serveur d'affichage qui 'compose' des buffers GEM.
Y a t'il un rapport (dans le concept) entre ces deux types de composition?
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par bubar🦥 (Mastodon) . Évalué à 3.
qui vivra verra ;)
moi je vois très bien wayland sur les "Clients" (et bien sûr sur le "gros" embarqué)
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par GeneralZod . Évalué à 4.
La vraie raison, c'est pour éviter les fiasco précédents (roadmap inconsistentes, git cassé, personne ne veut se mouiller pour releaser xserver 1.5 etc ...). Et c'est un développeur Fedora qui propose de passer à un cycle de 6 mois mais aussi d'apprendre à se servir d'un système de contrôle de versions distribués en utilisant cette fonctionnalité mystérieuse (et extrêmement compliqué d'utilisation, surtout dans Git) que sont les branches.
http://lists.freedesktop.org/archives/xorg-devel/2009-Septem(...)
[^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir
Posté par Mjules (site web personnel) . Évalué à 3.
Le serveur 1.7 a bien été publié mais les autres modules font encore l'objet de quelques corrections de dernières minutes.
# XInput - claviers avec dispositions différentes
Posté par Wawet76 . Évalué à 3.
Ce que j'aimerais, c'est pouvoir laisser branché 2 claviers et pouvoir utiliser le premier en bépo et l'autre en azerty...
[^] # Re: XInput - claviers avec dispositions différentes
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: XInput - claviers avec dispositions différentes
Posté par Yggdras . Évalué à 1.
J'ai la même configuration que Wawet76: un clavier bépo et un clavier azerty, et j'ai juste configuré HAL comme la page suivante l'indique: http://bepo.fr/wiki/Activation_X.Org#Disposition_diff.C3.A9r(...)
# Merci pour la dépêche
Posté par liberforce (site web personnel) . Évalué à 2.
Cela m'a permis de voir qu'il y avait enfin eu du boulot sur la gestion de l'économie d'énergie.
http://www.botchco.com/agd5f/?p=41
http://www.botchco.com/agd5f/?p=45
Une bonne nouvelle pour mon r350 :-)
# Configuration d'XI2
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Et pour lui faire séparer les périphériques en plusieurs maîtres, autrement dit pour tester du vrai multi-pointeurs (ou claviers), quelqu'un sait comment on fait ?
[^] # Re: Configuration d'XI2
Posté par Mjules (site web personnel) . Évalué à 1.
quelques données là (recherche rapide, ya surement plus complet )
https://fedoraproject.org/wiki/Features/XI2
[^] # Re: Configuration d'XI2
Posté par monde_de_merde . Évalué à 2.
Par ailleurs il n'est *pas* conseillé d'activé cette fonctionnalité, à moins de disposé d'un toolkit qui la prend en charge. En effet, si par malheur, ton clavier et ta souris réel ne sont pas raccordé au bon "maître", le toolkit (et par extension le bureau) ne recevra plus le flux d'entrée.
Par ailleurs, je ne sais pas comment se comporte un terminal face à plusieurs clavier, il y a aussi des risques à ce niveau et c'est autrement plus embêtant qu'un gnome cassé.
# XvMC
Posté par M . Évalué à 4.
# debian
Posté par M . Évalué à 4.
- consolekit (qui crée tout un tas de thread) [1]
- hal qui me reveille mes disques en standy entre autre.
- devicekit-disks
- policykit [2]
Du coup pour le moment j'ai mis le serveur X en "hold"...
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526499
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526854
PS : pour couronner le tout le paquet nvidia-glx-legacy-96xx de debian n'est plus maintenu
[^] # Re: debian
Posté par GeneralZod . Évalué à 5.
[^] # Re: debian
Posté par Sylvain Sauvage . Évalué à 5.
1. le problème des 62 threads en trop de consolekit est en train d’être réglé et il n’y avait pas d’autre façon de faire (ce serait bien de lire les liens que l’on donne soi-même, jusqu’au bout…) ;
2. devicekit-disks, c’est apporté par Gnome (gvfs en particulier), pas par xorg-*, et puis c’est bloqué par dmsetup¹.
Pour l’utilisation de hal, ça date d’il y a un moment (ce qui ne règle pas le problème). Et l’utilisation de policykit (comme argumenté dans le bogue que tu donnes) peut se défendre (au moins autant que celle de hal).
¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550434
[^] # Re: debian
Posté par Littleboy . Évalué à 5.
A l'origine:
The issue that is reported in the initial report is actually not
a bug but a design decision. Once we improve or replace the VT subsystem we can do better than this. Until then we don't have another way.
Puis un patch (avec une partie noyau):
This patch adds an ioctl to the kernel which console-kit can use to wait on a terminal switch without creating 60 threads.
Et enfin:
Alan gave up maintainership of the console stuff a few weeks back. gregkh then took this up and one of the first things he did is merge Alan's patch into his tree. Two days ago this was then merged into mainline. So I guess that means the kernel infrstructure should now be able to cut down the threads to two (the ioctl is still blocking)
https://bugs.freedesktop.org/show_bug.cgi?id=17720
[^] # Re: debian
Posté par FluffyHamster . Évalué à 4.
Sur archlinux les discussions sont en cours pour tenter de supprimer HAL au profit de devicekit et séparer polkit de HAL (version '1' de policikit, qui s'installe pour l'instant au coté de policykit, avec tout les fichiers de config en doubles...) mais ca devrai prendre du temps.
Gnome semble ok uniquement avec les *kit, KDE pas encore, et il reste un certain nombre de logiciels qui ne peuvent pas ce passer de HAL. Bref encore un peu de boulot pour clarifier le boulot dans toutes ces librairies.
# Plusieurs carte vidéos
Posté par Anonyme . Évalué à 3.
[^] # Re: Plusieurs carte vidéos
Posté par monde_de_merde . Évalué à 3.
[^] # Re: Plusieurs carte vidéos
Posté par Mimoza . Évalué à 0.
Pourvoir afficher sur chaque prise des carte graphique une session différentes me semble tout aussi intéressant (c'est possible avec Xephyr mais ca rajoute une couche). Faire du multiseat avec un seul serveur X :-D
[^] # Re: Plusieurs carte vidéos
Posté par Mildred (site web personnel) . Évalué à 3.
[^] # Re: Plusieurs carte vidéos
Posté par Sylvain Sauvage . Évalué à 2.
Et pour les cas d’utilisation : multimédia « culturel » (mur d’écrans…), chambres de contrôle, simulations (6 écrans font un bon cockpit), se prendre pour un hacker hollywoodien…
[^] # Re: Plusieurs carte vidéos
Posté par Octabrain . Évalué à 2.
Et ils n'ont rien à faire du matos qui a été construit avant ?
[^] # Re: Plusieurs carte vidéos
Posté par Sylvain Sauvage . Évalué à 2.
J’ai simplement complété la réponse de Mildred, à laquelle un petit malin aurait pu répondre par un « pfft, t’as qu’à prendre une carte avec deux sorties, même les cartes avec GPU intégré ont deux sorties », en disant que, maintenant (et depuis un moment), l’utilisation de plusieurs cartes était en général dans l’optique d’utiliser plus de deux écrans puisque chaque carte peut déjà en gérer deux toute seule.
Ça n’empêche pas de pouvoir utiliser ses vieilles cartes PCI avec sa vieille carte mère pour gérer un vieil écran par vieille carte.
[^] # Re: Plusieurs carte vidéos
Posté par Jllc . Évalué à 1.
Par contre, aucun idée de la stabilité de cette solution.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.