Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir

Posté par . Modéré par Florent Zara.
Tags :
86
14
oct.
2009
Serveurs d'affichage
La dernière dépêche sur LinuxFr.org concernant le serveur X date d'au moins un an et, malgré les nombreux journaux, il est parfois utile de faire un rappel des faits. Xorg est une partie vitale de l'infrastructure libre, et il est intéressant de noter toutes ses évolutions, parfois moins visibles que celles du noyau, mais tout aussi capitales.

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 conclut que les 3 points sont intimement liés et propose que le projet X.org adopte un emploi du temps fixe, avec des livraisons planifiées à l'avance et des fenêtres de synchronisation fixe pour l'ajout de fonctionnalités, de corrections de bugs et de test finaux.

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.
XvMC,(X-Video Motion Compensation) intégré dans les pilotes Intel et AMD, c'est la possibilité d'accélérer matériellement le décodage des vidéos de manière générique.
  • # patrick_g ?

    Posté par . Évalué à  -10 .

    C'est toi ?
  • # Aurait-tu un lien de parenté...

    Posté par (page perso) . Évalué à  -4 .

    ... avec un certain patrick_g? \o/


    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 (page perso) . Évalué à  10 .

    Merci pour cette belle dépêche !

    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 (page perso) . Évalué à  3 .

      Tiens, Wayland est dispo sur AUR pour ArchLinux, certains ont déjà testé la bête ?
      • [^] # Re: Xorg 7.5, xserver 1.7, xdc2009, passé, présent et avenir

        Posté par (page perso) . Évalué à  10 .

        Je ne suis pas un expert et je ne suis pas de très prêt le dévellopement de Wayland, mais il me semble avoir compris que ce n'est pas vraiment un remplaçant pour Xserver (et non pas de Xorg en entier).

        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 . Évalué à  10 .

      Oui, en effet, une petite coquille, c'est bien 2009 qu'il fallait lire (Au moins, comme ça, je suis sur qu'une personne a bien lu l'article)

      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 . Évalué à  2 .

      Wayland n'est pas destiné à être un remplaçant pour xorg, mais plutôt un serveur X léger et utilisable par exemple pour de l'embarquée ou pendant le boot d'un système.

      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 . Évalué à  10 .

        Euh non, c'est pas un serveur X, ca n'a rien a voir avec X (le protocole).

        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 (page perso) . Évalué à  3 .

          C'est presque hors sujet et uniquement pour ma culture personnelle mais, il est pas tout le mec derrière Phoronix plutôt ? Michael Larrabel je crois.

          (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 . Évalué à  -5 .

            Peut être, mais je suis bien content de les avoir découvert : Les news sont bien structurées avec un paquet de liens sur les articles/news précédent(e)s.
            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 . Évalué à  2 .

          Merci d'avoir rectifié, cela me hérisse à chaque fois que quelqu'un clame que Wayland est un remplacant d'X ou d'Xserver alors qu'il n'en remplace qu'une petite partie des fonctionnalités..

          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 . Évalué à  3 .

        s/Wayland n'est pas destiné à être un remplaçant pour xorg/Wayland n'est pas -pour l'instant, et de toute façon pour tout les matos- destiné à être un remplaçant de xorg.

        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 . Évalué à  4 .

      Mais bien sûr, tout les projets qui passent à un cycle de 6 mois le font parce que Shuttleworth l'a dit et c'est lui l'inventeur du concept ! Enfin, peut-être dans le monde de bisounours des fanboys.
      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 (page perso) . Évalué à  3 .

      C'est normal que Xorg 7.5 ne soit pas mentionné sur le site web, il n'est tout simplement pas encore sorti.

      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 . Évalué à  3 .

    La gestion de la disposition du clavier se fait à quel moment dans cette histoire de périphérique maître et esclave ?

    Ce que j'aimerais, c'est pouvoir laisser branché 2 claviers et pouvoir utiliser le premier en bépo et l'autre en azerty...
  • # Merci pour la dépêche

    Posté par (page perso) . Évalué à  2 .

    ... et surtout pour les infos côté AMD, je garde le blog que tu as cité sous le coude.
    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 (page perso) . Évalué à  1 .

    Si j'ai bien compris, par défaut, XI2 met tous les périphériques dans un seul maître. Et n'apporte donc rien par rapport à ce qui se faisait avant.

    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 (page perso) . Évalué à  1 .

      AMHA, via l'outil xinput

      quelques données là (recherche rapide, ya surement plus complet )
      https://fedoraproject.org/wiki/Features/XI2
      • [^] # Re: Configuration d'XI2

        Posté par (page perso) . Évalué à  2 .

        Je crois pas que pour l'instant il y ait quoi que ce soit de plus complet.

        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 . Évalué à  4 .

    Heu XvMC c'est dépassé. C'est VAAPI qui le remplace : http://linuxplumbersconf.org/2009/slides/Bian-Jonathan-VAAPI(...)
  • # debian

    Posté par . Évalué à  4 .

    En tout cas les nouvelles versions du serveur X dans debian apporte tout un tas de dépendance sur des trucs horrible comme :
    - 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 . Évalué à  5 .

      Je note avec amusement que tout les projets que tu viens de citer ont le même mainteneur upstream (David Zeuthen). :o)
    • [^] # Re: debian

      Posté par . Évalué à  5 .

      Deux faux problèmes :
      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 . Évalué à  5 .

        Pour les flemmards (j'en fait partie aussi, donc pas de traduction en francais :P):

        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 . Évalué à  4 .

      Tout ces outils *kit semblent vouloir remplacer HAL à terme.

      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 .

    Je profite de l'occasion : est-ce que quelqu'un saurait où en est le support de plusieurs cartes vidéos ?
    • [^] # Re: Plusieurs carte vidéos

      Posté par (page perso) . Évalué à  3 .

      Le module VGA arbiter est revenue dans le noyau (2.6.31 je crois, mais faudrait vérifier) donc à priori il y a un début de support propre (mieux gérer moins prise de tête à configurer etc...). J'ai pas plus de détail que ça au niveau de X, mais c'est possible c'est sûr.
    • [^] # Re: Plusieurs carte vidéos

      Posté par . Évalué à  0 .

      Heu je suis peut être a coté de la plaque mais tu peut déjà avoir un pc avec plusieurs carte graphique lié 1 à 1 avec plusieurs serveur X ... tu voudrais avoir 1 seul serveur X pour plusieurs cartes graphiques ? Dans quel but ?
      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 (page perso) . Évalué à  3 .

        Par exemple pour avoir un bureau qui s'étend sur deux écrans. Avoir plus de place quoi.
        • [^] # Re: Plusieurs carte vidéos

          Posté par . Évalué à  2 .

          En général pour plus que 2 écrans : même les cartes mères avec GPU intégré ont plusieurs sorties maintenant.

          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 . Évalué à  2 .

            "En général pour plus que 2 écrans : même les cartes mères avec GPU intégré ont plusieurs sorties maintenant."
            Et ils n'ont rien à faire du matos qui a été construit avant ?
            • [^] # Re: Plusieurs carte vidéos

              Posté par . Évalué à  2 .

              Où est-ce que j’ai dit qu’il ne fallait pas ou que l’on ne gérait plus le vieux matériel ?

              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 . Évalué à  1 .

          Si un serveur X ne peut pas gérer plus d'un carte graphique (j'en ai aucune idée), il est par contre possible de lancer un serveur pour chaque carte, et d'utiliser par exemple xdmx (Distributed Multihead X) pour créer un unique serveur (où lancer ton bureau), utilisant les précédents.

          Par contre, aucun idée de la stabilité de cette solution.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.