Le serveur X 1.6 est disponible

Posté par  (site web personnel) . Modéré par Mouns.
Étiquettes :
31
10
mar.
2009
Serveurs d’affichage
La version 1.6 du serveur X édité par X.org est disponible depuis ce 25 février 2009.

Au menu des nouveautés :
  • Le support du protocole DRI2 ;
  • RandR 1.3 ;
  • Xinput 1.5 avec le support des propriétés ;
  • Une meilleure gestion de l'accélération du pointeur de la souris ;
  • Une amélioration des performances de l'architecture d'accélération 2D EXA ;
  • Beaucoup de corrections de bogues divers et variés (et probablement quelques nouveaux ;) ).

Pour mémoire, un serveur X implémente la partie serveur du protocole X11, il est donc lancé sur une machine dite « cliente » (poste de travail). La version 1.5 (sortie avec la suite Xorg 7.4) avait notamment apporté une gestion du branchement à chaud des périphériques via HAL. DRI2 est le remplacement de l'ancien protocole DRI (Direct Rendering Interface). Je serais bien en peine de vous en décrire les arcanes mais cette évolution permet entre autre d'envisager de rediriger des fenêtres en rendu direct et ainsi de pouvoir réaliser de la composition avec. Il sera à terme possible d'avoir une application 3D composée avec une autre (par exemple glxgear sur les faces du cube de Compiz).
Pour mémoire, la composition est l'opération consistant à rediriger toutes les fenêtres dans un espace mémoire avant affichage afin de réaliser diverses opérations nécessitant de connaître l'ensemble, comme par exemple, les ombres portées, la vraie transparence, etc.
Description du protocole : http://wiki.x.org/wiki/DRI2

RandR 1.3 est une évolution de l'extension Resize and Rotate. La version 1.2 a permis l'introduction de fonctions comme la gestion du branchement à chaud des écrans doubles, de leurs relations, etc. Toutefois, des manques se sont rapidement fait sentir que les développeurs ont tenté de combler par cette version 1.3.
  • Ainsi, on peut maintenant connaître l'état des moniteurs sans sonder les sorties de la carte graphique, on évite ainsi les scintillements voire les flashs sur l'écran ;
  • Il est possible de définir un moniteur primaire ;
  • Le « panning » est maintenant possible, c'est à dire avoir une surface d'affichage supérieure à la taille de l'écran, la zone visible se déplaçant avec la souris ;
  • Des transformations (rotation, changement d'échelle) sont maintenant possibles.

Pour plus de détails, suivez cette présentation de Matthias Hopf, concepteur de la version 1.3 : http://www.vis.uni-stuttgart.de/~hopf/pub/Fosdem_2009_randr1(...) (PDF).

Xinput 1.5 est la dernière évolution de l'extension du même nom avant la très attendue version 2 qui amènera le support des entrées multiples tel le multitouches (comme sur l'iPhone par exemple). Cette version ajoute la gestion des propriétés aux entrées. Tout comme les écrans possèdent une résolution/fréquence/orientation qu'il est possible de faire varier via xrandr ; il est maintenant possible d'obtenir et de gérer un certain nombre de propriétés des périphériques d'entrées comme par exemple, l'attribution des boutons. Le tout grâce à l'utilitaire xinput ( http://www.manpagez.com/man/1/xinput/).
Plus de détails dans le mail de Peter Hutterer ainsi que sur son blog :
http://lists.freedesktop.org/archives/xorg/2008-September/03(...)
http://who-t.blogspot.com/

Predictable Pointer Acceleration est un travail qui remplace totalement l'ancien code d'accélération du pointeur de souris tout en restant compatible. En théorie, le résultat devrait être relativement invisible. Cependant pour ceux qui en ont besoin, il offre une souplesse bien supérieure dans la gestion des caractéristiques du mouvement (ex : accélération, vitesse) avec notamment la possibilité de les modifier à chaud via l'utilitaire xinput ou par le biais d'un fichier de configuration (xorg.conf ou les fichiers fdi de hal).
Description et spécifications : http://www.x.org/wiki/Development/Documentation/PointerAccel(...)

EXA est une architecture actuelle d'accélération des opérations 2D visant à remplacer XAA. Depuis la version 1.2 du serveur X, le code d'EXA a subit de profondes améliorations qui ont permis des gains substantiels de vitesse. La version 1.6 ne déroge pas à la règle puisqu'elle inclut différentes optimisations, en particulier sur le rendu des polices de caractères. Au lieu d'utiliser un pixmap par glyphe, on alloue un pixmap pour un ensemble de glyphes et on compose au moment du rendu (bien mieux expliqué ici : http://blog.fishsoup.net/2008/04/20/fast-text-use-a-single-c(...) ), ce qui permet des gains substantiels en vitesse puisque le moteur de la carte graphique peut traiter les glyphes tous ensemble au lieu de les traiter l'un après l'autre.

L'architecture UXA quant à elle n'est pas incluse dans cette version du serveur X et il n'est pas certain qu'elle apparaisse dans les prochaines versions. Pour mémoire, c'est un dérivé d'EXA développé par Intel et optimisé pour les cartes dépourvues de mémoire dédiée. Elle est très dépendante du gestionnaire de mémoire GEM (développé aussi par Intel), ceci expliquant peut être cela.

La prochaine version du serveur X (1.7) sera la base de X.org 7.5 et est prévu pour avril. Il y a néanmoins peu de chance qu'elle soit disponible avant août ou septembre 2009, les développeurs X étant notoirement connus pour dépasser les dates qu'ils se sont fixés ;).

Bien entendu, toute aide pour respecter ces délais est la bienvenue. Dixit les développeurs, le code du serveur X a beaucoup été remanié ces dernières années et il n'est plus aussi effrayant qu'il a pu l'être. N'ayez pas peur de contribuer si vous le pouvez et le voulez.

Aller plus loin

  • # drivers

    Posté par  . Évalué à 6.

    C'est bien beau toute ces nouveautés, mais est-ce que les drivers suivent [1] ?

    Ou alors ces nouveautés sont réservés que pour les dernières cartes graphique (ou pilote bien maintenue).


    [1] par exemple qui supporte à ce jour DRI2.
    • [^] # Re: drivers

      Posté par  . Évalué à 5.

      Pour le moment, mais je suis peut-être légèrement hors-sujet, le drivers "propriétaire" ATI (fglrx) semble ne pas fonctionner avec la version 1.6 (un problème d'ABI d'après ce que j'ai compris). Ce qui fait que depuis que je suis passé sous la version de développement d'Ubuntu, je suis obligé d'utiliser le driver radeon qui ne semble pas prendre trop aimer ma carte graphique (radeon 3500 il me semble).

      http://wiki.cchtml.com/index.php/Ubuntu_Jaunty_Installation_(...)
      • [^] # Re: drivers

        Posté par  . Évalué à 5.

        Même problème avec ma radeon 3450. La solution des pilotes radeonhd me plait à moitié, à la rigueur, je peux me passer de l'accélération 3d mais le suspend2ram n'est pas fonctionnel, la gestion de l'énergie non plus, le branchement d'écran à chaud ne me parait pas bien géré, etc.
        C'est prometteur pour un pilote en développement mais ça ne me convient pas (oui c'est libre, j'ai qu'à prendre mon emacs, toussa).

        Du côté des pilotes proprios, ils sont dépassés en 64bits, ça tourne, mais ils sont vieux, buggés et ne gèrent pas les dernières fonctionnalités de Xorg.

        Chez archlinux, les mainteneurs des package catalyst ont carrément laché l'affaire :
        http://blog.poiroud.fr/marc/index.php/post/2009/03/06/Cataly(...)
        http://www.phoronix.com/scan.php?page=news_item&px=NzEwM(...)
        http://www.archlinux.org/pipermail/arch-dev-public/2009-Febr(...)

        Bref encore une fois dans le petit monde fermé des os libres avec pilotes proprio, il faudra casser le support catalyst dans les distributions pour que ATI daigne sortir une mise à jour (encore que, c'est pas gagné).
        • [^] # Re: drivers

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          y'a le pilote libre ATI qui est dispo dans ubuntu à partir de 8.10 et qui marche très bien chez moi (mieux que le pilote proprio)

          Mes livres CC By-SA : https://ploum.net/livres.html

          • [^] # Re: drivers

            Posté par  . Évalué à 3.

            Je confirme. Quelques plantages ici et là, pas de compositing en même temps que Xv/OpenGL, mais dans l'ensemble ça marche très bien.
            • [^] # Re: drivers

              Posté par  . Évalué à 10.

              pas de compositing en même temps que Xv/OpenGL, mais dans l'ensemble ça marche très bien.
              Voilà une chose que je comprends pas. Avec les machines actuelles qu'on a, les interfaces qu'on a, comment peut-on aujourd'hui se satisfaire de ça ?

              Je suis bloqué avec un chipset intel 915GM moi, l'accélération 3D est bonne, la sortie d'écran, le dual screen à la volée avec XrandR est bon, compiz est fluide, le suspend to ram marche, mais je ne suis PAS satisfait de ces drivers car compositing avec xv/opengl ça donne des choses affreuses.

              Trop exigeant ? Peut être... Question de point de vue. Pour moi cette "imperfection" est très gênante.

              Je suis et je reste frustré de cette situation qui dure depuis des années alors qu'avant d'avoir ce chip intel je lisais partout sur le net que wow les chip intel sous linux c'est le bonheur parfait.

              Bref HEUREUSEMENT le DRI2 arrive et va combler ce retard énorme, combien de temps à attendre encore, le moins possible j'espère...
              • [^] # Re: drivers

                Posté par  (site web personnel) . Évalué à 10.

                C'est une question de point de vue. Personnellement je m'en tape du compositing, Xv je ne l'utilise qu'en plein écran et OpenGL marche à la perfection sur mon 955.

                Moi ce qui m'emerde c'est le branchement sur video projecteur. Globalement ça marche à peu près mais c'est toujours l'aventure. Quand je vois des potes qui branchent n'importe qu'el video projecteur sur leur portable sous Windows et qui ont juste à appuier sur une touche (enfin deux puisque c'est souvent une combinaison avec Fn) et "Magie, magie" ça marche direct.

                Moi c'est cette imperfection que je trouve génante car à chaque fois que je doit faire une présentation il faut soit que j'arrive plus tôt pour être sûr d'avoir le temps de faire marcher la connexion, soit que je sois sûr qu'il y a un portable sur place pré-configuré.

                Donc je partage ta frustration mais pour des raisons différentes...
          • [^] # Re: drivers

            Posté par  . Évalué à 2.

            Je connais pas ce pilote. D'après http://doc.ubuntu-fr.org/ati , c'est un wrapper qui charge le bon pilote ati (donc radeon ou radeonhd). Donc ça peut marcher mais ça doit dépendre grandement du chipset et du pilote correspondant.
            • [^] # Re: drivers

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              Je ne sais pas d'où vient l'info sur le wiki ubuntu-fr mais moi j'avais entendu qu'il s'agissait d'un nouveau pilote libre développé suivants les specs récemment libérées par ATI.

              Mes livres CC By-SA : https://ploum.net/livres.html

              • [^] # Re: drivers

                Posté par  . Évalué à 3.

                Pour moi, ce que tu décris, c'est radeonhd :
                http://www.x.org/wiki/radeonhd

                The radeonhd driver, or xf86-video-radeonhd, is an X.org video driver for R500 and newer ATI graphics devices. It is being developed by the X11 community, currently centered around Novell and AMD, with the free documentation provided by AMD.
                • [^] # Re: drivers

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  En effet, je me suis trompé :

                  "It provides the 'ati' driver wrapper which loads one of the 'mach64', 'r128' or 'radeon' sub-drivers depending on the hardware."

                  Mes livres CC By-SA : https://ploum.net/livres.html

                  • [^] # Re: drivers

                    Posté par  . Évalué à 3.

                    En fait, il y a deux drivers pour les R500 et plus(HDxxxx): radeon et radeonhd, les deux sont très proches mais si vous avez des problèmes avec l'un, tester l'autre ne fait pas de mal. La page sur le wiki d'ubuntu-fr mériterais d'être mise à jour.
              • [^] # Re: drivers

                Posté par  (site web personnel) . Évalué à 4.

                Tu parles du pilote radeonhd pour les cartes AMD de type R500 et +

                * http://www.x.org/wiki/radeonhd
                * http://fr.wikipedia.org/wiki/RadeonHD
      • [^] # Re: drivers

        Posté par  . Évalué à 4.

        tu n'es pas hors-sujet, mais étant donné que tu utilises une version alpha d'une distribution qui n'est guère stable en LTS....
        :)
    • [^] # Re: drivers

      Posté par  . Évalué à 5.

      Malheureusement, non. Par exemple une S3 Savage n'a plus d'accélération matérielle 3D avec Xorg 1.6 . Il manque des petites mimines pour adapter le code, qui de plus aurait besoin de beaucoup de correctifs. Mais comme ce matériel devient de moins en moins courant, ce n'est pas bien grave.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: drivers

      Posté par  (Mastodon) . Évalué à 2.

      Les drivers Intel de ce côté-là sont assez à la pointe. Un chipset i915 est excellemment bien supporté sous Xorg.

      Il devrait bien tot en etre de meme avec les versions suivantes (notamment le très courant i965) qui pour l'isntant tournent très bien (basé sur le i915) mais n'utilisent pas encore à fond leurs spécificités (que je ne connais pas exactement d'ailleurs).

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: drivers

        Posté par  . Évalué à 9.

        Un chipset i915 est excellemment bien supporté sous Xorg.

        Hum hum...

        En ce moment c'est quand même pas la joie ; entre tous les bouleversements qui secouent l'infrastructure graphique de Linux/Xorg en ce moment (GEM, DRI2, UXA, KMS...), il a récemment été très difficile d'avoir un couple noyau/espace utilisateur qui offre des performances 3D correctes avec, par exemple, un GMA950. Par « correctes », j'entends comparables aux performances atteintes avec les versions précédentes d'Xorg et du driver intel (< 2.5.x pour ce dernier, si je ne m'abuse). Cela a été documenté entre autres par Phoronix, cf. [0].

        Que les développeurs des couches graphiques de Linux bossent et chambardent tout afin qu'on dispose enfin d'une architecture propre et moderne, je trouve ça très bien. Maintenant, le boulot des distributions devrait justement de préserver l'utilisateur de ces phases de transition, autant que faire se peut ; en l'occurrence ça n'a pas du tout été le cas pour un certain nombre d'entre elles (citons en vrac Archlinux[1], Fedora 10[2], la prochaine Ubuntu[4] qui risque de sortir avec cette régression...).

        Le bug est connu chez fd.o[3] mais en l'état actuel des choses, virtuellement toutes les distributions Linux récentes sont quasiment infoutues d'offrir des performances 3D normales avec le GMA950, qui si on en croit[5] est quand même extrêmement répandu.

        Espérons qu'avec les corrections et nouvelles fonctionnalités dans le noyau 2.6.29, xorg-server 1.6 et les améliorations récentes apportées au driver DRI d'Intel, les choses retournent à la normale. En attendant... Qu'on ne me dise pas que les cartes Intel sont bien supportées en ce moment.

        [0] : http://www.phoronix.com/scan.php?page=article&item=intel(...)
        [1] : http://bbs.archlinux.org/viewtopic.php?id=62455
        [2] : https://bugzilla.redhat.com/show_bug.cgi?id=473179
        [3] : https://bugs.freedesktop.org/show_bug.cgi?id=19873
        [4] : https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/303(...)
        [5] : http://unity3d.com/webplayer/hwstats/pages/web-2009Q1-gfxcar(...)
        • [^] # Re: drivers

          Posté par  . Évalué à 9.

          [[ Maintenant, le boulot des distributions devrait justement de préserver l'utilisateur de ces phases de transition, autant que faire se peut ; en l'occurrence ça n'a pas du tout été le cas pour un certain nombre d'entre elles (citons en vrac Archlinux[1], Fedora 10[2], la prochaine Ubuntu[4] qui risque de sortir avec cette régression...). ]]

          Uniquement pour les distributions dont le but est de viser la stabilité!!
          Fedora liste dans l'ordre de ses priorités en numéro 1 l'avancement rapide du logiciel libre et seulement apres de fournir un environement stable.
          En conséquence de quoi ils choisissent souvent d'utiliser des techno 'alpha' (exemple KDE 4.0.3), donc se plaindre de la stabilité de Fedora c'est vouloir le beurre et l'argent du beurre, utilise une autre distribution si tu veux du stable..

          Ubuntu, la je suis d'accord que ce n'est pas normal car ils disent vouloir fournir une distribution utilisable par tout le monde.. Mais bon il y a plusieurs années deja, sur mon PC avec Kubuntu, X n'affichait qu'un écran gris alors que Mandriva lui fonctionnait bien, donc ce n'est pas nouveau.
        • [^] # Re: drivers

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          En attendant... Qu'on ne me dise pas que les cartes Intel sont bien supportées en ce moment.
          Justement, j'utilise depuis quelques temps la version testing (1.5.99) sous Archlinux sur un laptop avec un chipset Intel GM965 (dernier driver en date) et je dois dire que c'est le jour et la nuit. J'ai enfin une VRAIE accélération 3D. Je ne parle pas de pseudo-benchmark à la glxgears ou de burô 3D mais de trucs genre Assaultcube (enfin!), Enemy Territory, Google Earth (avec les bâtiments 3D, à moi New York DC!) ou même Celestia (qui ramait grave sur ma bécane). Maintenant ça tourne...
          X lui-même semble moins gourmand en mémoire (X lancé avec Awesome ne pompe que 160Mo).

          À noter qu'avec le driver Intel, DRI2 n'est activé qu'avec l'accélération UXA
          • [^] # Re: drivers

            Posté par  (site web personnel) . Évalué à 3.

            Google Earth (avec les bâtiments 3D, à moi New York DC!)
            T'es sûr que tu utilises Google EARTH ? Ou alors il manque un T à DC mais sinon je ne vois pas du tout où est cette ville.
          • [^] # Re: drivers

            Posté par  . Évalué à 2.

            Je suis en Debian Testing avec une CG Intel X3100 (GMA je ne sais plus quoi?) et j'ai des soucis d'affichage avec Firefox et GoogleEarth.
            Pour Firefox ça semble lié à l'EXA car si je force XAA ça s'affiche bien. Exemple de site qui pose problème (http://www.dpreview.com).
            Pour GoogleEarth ça concerne la météo. Les nuages s'affichent en une sorte de labyrinthe...
        • [^] # Re: drivers

          Posté par  (Mastodon) . Évalué à 1.

          "En attendant... Qu'on ne me dise pas que les cartes Intel sont bien supportées en ce moment."

          Si, elles le sont et depuis plusieurs mois. Une Ubuntu 8.04 en natif est capable de faire tourner un bureau 3D sur un eeePC701 et son "petit" i915 (je sais, je l'ai fait). Ca marche bien, pas de driver proprio à ajouter. J'appelle ça etre bien supporté.

          Ensuite depuis qques semaines je tourne avec un kernel 2.6.28.5, un xorg-server 1.5.3-r2 (sous Gentoo), les drivers intel de base, et j'ai constaté et mesuré des perfs en augmentation de l'ordre de 30%.

          Tout ça uniquement avec le GEM, sans encore parler de DRI2 !

          En témoigne tout ce thread sur le forum Gentoo : http://forums.gentoo.org/viewtopic-t-737102-postdays-0-posto(...)

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

          • [^] # Re: drivers

            Posté par  . Évalué à 1.

            Si, elles le sont et depuis plusieurs mois. Une Ubuntu 8.04 en natif est capable de faire tourner un bureau 3D sur un eeePC701 et son "petit" i915 (je sais, je l'ai fait).

            Je ne vois pas le rapport, cette distribution aura bientôt un an. Je te suggère de refaire l'expérience avec une Ubuntu 8.10 vanilla. Chez moi ça ne fonctionne absolument pas : les performances sont déplorables, j'atteins péniblement les cinq images par secondes dans OpenArena par exemple.

            Ensuite depuis qques semaines je tourne avec un kernel 2.6.28.5, un xorg-server 1.5.3-r2 (sous Gentoo), les drivers intel de base, et j'ai constaté et mesuré des perfs en augmentation de l'ordre de 30%.

            Déjà, « quelques semaines », ce n'est pas « quelques mois ». Ensuite, si je lis correctement le fil de discussion que tu cites, tu as un chipset i965. Il me semble que justement, ce sont plus les i915 (GMA950 en tête) qui posent problème depuis quelques temps.

            Accessoirement, une augmentation de 30% des performances ne veut rien dire par elle-même si ces dernières ont été divisées par trois il y a quelques mois. Je ne dis pas que c'est ton cas ; mais il s'agit bien de celui des possesseurs de GMA950.
    • [^] # Re: drivers

      Posté par  . Évalué à 5.

      Question subsidiaire, sur quelle(s) carte(s) graphique(s) sont développées toutes ces nouvelles fonctionnalités?

      J'imagine que les dev doivent avoir de bons pilotes si ils veulent pouvoir tester leur boulot.
      • [^] # Re: drivers

        Posté par  . Évalué à 3.

        Intel.
        • [^] # Re: drivers

          Posté par  (site web personnel) . Évalué à 1.

          Source ?
          • [^] # Re: drivers

            Posté par  . Évalué à 10.

            Kristian, qui a developé DRI2, est sur intel (macbook air 1) et les plus gros contributeurs à toutes ces technologies travaillent pour intel (naturellement ils utilisent du matérielle intel)(Anholt, Barnes, Packard). Pour randr 1.3 le plus gros du travail a été réalisé par Hopf qui lui est sous radeonhd. Pour le reste (input) le gpu a pas bcp d'importance.
  • # Synchro souris/écran lors de la rotation

    Posté par  . Évalué à 8.

    Est-ce que, lorsque l'on tourne l'écran, le stylet et la souris tourneront comme l'écran (je parle sans bidouille crade).
    Actuellement, sur les tabletPC, si on tourne l'écran, les mouvements de pointeurs se font à la perpendiculaire des mouvements, ce qui limite l'utilisabilité...
    • [^] # Re: Synchro souris/écran lors de la rotation

      Posté par  (Mastodon) . Évalué à 3.

      L' idéal est que la tablette dispose d' un accéléromètre (ce qui n' est le cas que sur certains modèles récents).

      Concernant le "hack crade" je vois pas trop ce dont il s' agit : sur un vieux Zaurus (distro d' origine + autre et ne disposant pas d' accéléromètre) un click fait basculer l' écran, la souris suit correctement. Dans le genre ancien, ai eu l' occasion de voir un "emperor linux" sur tabletpc : pareil, ça suit correctement.
      A moins que tu parles de ça : http://bazaar.launchpad.net/~karl.hegbloom/tabuntu/tablet-sc(...) comme "hack crade" ? (mais la personne précise qu' il est "student". il voit un truc, cherche à la corriger, et ensuite propose son truc, perso j' trouve ça vachement bien, mais bon)

      ps : je viens d' essayer sur mon netbook après avoir installé kmachin, tout les mouvements suivent correctement la nouvelle orientation de l' écran. (xrandr 1.2 sur xorg 1.4.2 avec kmachin sur une 2009.0 mnb)
      • [^] # Re: Synchro souris/écran lors de la rotation

        Posté par  (site web personnel) . Évalué à 3.

        J'ai aussi ce problème avec mon tablet pc.
        S'il est dans le même cas que moi, le hack crade est qu'il faut faire un script qui tourne l'écran avec xrandr et avec les wacomtools. Par exemple, pour tourner l'écran vers la droite :

        xrandr -o right
        xsetwacom set "stylus" Rotate 1


        Et comme ça, le pointeur de souris tourne aussi...
        • [^] # Re: Synchro souris/écran lors de la rotation

          Posté par  . Évalué à 5.

          Oui, c'est ça.

          Ce que j'appelle crade, c'est que le système de pointage n'est pas tenu informé de la rotation de l'écran, et qu'il faut lancer un script spécial pour que les deux opérations se fassent en même temps.
          • [^] # Re: Synchro souris/écran lors de la rotation

            Posté par  (site web personnel) . Évalué à 5.

            En même temps, à moins d'avoir un moyen de déterminer que le dispositif de pointage en question est attaché à l'écran, le faire tourner serait une connerie.

            Vous imaginez le résultat avec un ordinateur de bureau et un écran plat pivotant ? On tourne l'écran, et si la souris tourne aussi, là, pour le coup, ça fait des mouvements à 90 degrés.
            • [^] # Re: Synchro souris/écran lors de la rotation

              Posté par  . Évalué à 4.

              Xorg fait la distinction entre un pointeur relatif (souris, trackball/point, trackpad ... oui, le cas trackpad est bizarre) et pointeur absolu (touchscreen, tablette graphique ...)

              On peut supposer qu'il faut tourner que les dispositifs absolus, puisqu'ils doivent être adaptés au moins au ratio hauteur/largeur, et laisser tranquille les dispositifs relatifs.
            • [^] # Re: Synchro souris/écran lors de la rotation

              Posté par  . Évalué à 2.

              Heu, pas tout à fait.
              Si c'est pour un écran pivotable, à ce moment là il faudra faire tourner le pointeur _dans le sens inverse_ de rotation de l'écran. Réfléchissez deux secondes. L'écran, quand il est tourné, il apparait toujours comme si il était dans le bon sens pour la CG. Donc si on laisse la souris telle quelle, ça n'ira pas ...

              Et tout ça n'a rien à voir avec les périphériques de pointage relatifs ou non, comme expliqué au dessus : je ne vois pas le rapport.
    • [^] # Re: Synchro souris/écran lors de la rotation

      Posté par  . Évalué à 6.

      Est-ce que, lorsque l'on tourne l'écran, le stylet et la souris tourneront comme l'écran

      Avec un moteur, oui.
  • # panning

    Posté par  (site web personnel) . Évalué à 10.

    > Le « panning » est maintenant possible

    En fait, c'est plutôt _de nouveau_ possible. La fonctionalité
    existait depuis des lustres, et avait été supprimée lors de
    l'arrivée de Xrandr 1.2.
    • [^] # Re: panning

      Posté par  . Évalué à 5.

      Je me rappelle d'avoir été ébloui lors de ma première installation d'un Linux, en 1994, sur une carte graphique Cirrus Logic 5428.

      La souris faisait se déplacer l'écran, c'était magique. En même temps, l'écran était quasiment vide à part un xeyes...
  • # Entrées multiples == claviers multiples ?

    Posté par  . Évalué à 2.

    Est-ce que quelqu'un connait un peu le fonctionnement du clavier ?

    Actuellement sous X, comme sous Windows, on ne peut pas brancher 2 claviers et leur affecter des keymaps différents. Est-ce que la gestion des entrées multiples annoncée pour XInput 2 permettra de faire ce genre de chose ?
    • [^] # Re: Entrées multiples == claviers multiples ?

      Posté par  . Évalué à 3.

      Il y a quelques années, j'avais joué à faire du "multisiège" (1 ordi + n claviers + n écrans + n souris + n utilisateurs).

      Il y avait de gros hacks tordus, et je finissais toujours par bloquer sur une initialisation de carte.

      Est-ce que la situation a avancé ?

      Mieux : y a-t-il une solution, maintenant qu'on trouve de très grands écrans (26" en 2050 pixels de large) pour une solution
      1 ordi + 1 écran + 2 claviers + 2 souris + 2 utilisateurs)

      (chacun dans sa fenêtre)

      J'ai toujours trouvé curieux que ce genre de solution soit toujours restée quasi-inexistante.
      • [^] # Re: Entrées multiples == claviers multiples ?

        Posté par  . Évalué à -3.

        Tu as déjà vu une voiture avec deux volants ?
        Je dis çà, car j'ai toujours trouvé curieux que ce genre de solution soit toujours restée quasi-inexistante
      • [^] # Re: Entrées multiples == claviers multiples ?

        Posté par  . Évalué à 1.

        > Est-ce que la situation a avancé ?

        Non. Et c'est peut-être même l'inverse.
        Le "multisiège" n'est pas une priorité durant cette période de boulversement de Linux et Xorg. Il n'est pas complètement oublié, il y a quelles rares configurations qui marchent.
        La période est rude pour certains utilisateurs. Mais les choses avancent et ça va se calmer.
      • [^] # Re: Entrées multiples == claviers multiples ?

        Posté par  . Évalué à 3.

        Les ''Entrées multiples'' de Xinput2 sont plus connues sous le nom de MPX. On pourra avoir deux pointeurs chacun associé à un clavier, et bosser à deux dans deux fenêtres différentes, voire dans la même fenêtre si l'application le supporte (car les applications et en particulier les WM devront être adaptés pour pouvoir en tirer parti).
      • [^] # Re: Entrées multiples == claviers multiples ?

        Posté par  (Mastodon) . Évalué à 2.

        Bonjour

        J' avais également essayer de faire ceci. Sans trop de difficultés (avec 2 cartes nvidia et une autre avec une nvidia et une matrox. Toujours avec un couple ps2/usb pour les entrées.). Mon soucis se situait dans le reboot / arrêt : ça plantait quasiment à chaque fois. Sans conséquences, mais chiant.

        Novell commercialise toujours il me semble une solution pour cela.
        Quant à H.P (qui avait également une solution, dans un cadre "bundle éducation")... il me semble qu' ils ont arrêtés ce bundle.

        Il semble que l' orientation actuelle soit plutôt à la réduction de consommation électrique (et de place) des postes d' une part, et que l' on tendent plutôt à intégrer 2 souris (voir 2 claviers) sur un seul serveur X (voir une seule application). Non ?

        Cdlt.
        • [^] # Re: Entrées multiples == claviers multiples ?

          Posté par  . Évalué à 1.

          Il semble que l' orientation actuelle soit plutôt à la réduction de consommation électrique (et de place) des postes d' une part, et que l' on tendent plutôt à intégrer 2 souris (voir 2 claviers) sur un seul serveur X (voir une seule application). Non ?
          C'est bien de penser à ceux qui ne veulent pas que leur ordinateur prenne de la place, et c'est très bien de réduire la consommation au minimum.

          Reste que je vois pas l'intérêt de brancher deux machines si une seule suffit. Perso j'ai deux écrans, un 4/3 mat pour le bureau et un 16/9 glossy pour les films. Je suis contraint d'utiliser les pilotes nvidia pour ça… et ce n'est qu'un pis aller car je n'ai qu'un curseur, et les claviers sont partagés aussi. En gros si quelqu'un est sur l'ordi de bureau, tout ce qu'on peut faire avec l'autre écran c'est regarder une vidéo (c'est sa fonction première, certes, mais c'est pas l'idéal).

          Et si je veux rajouter un vidéo-projecteur ou un troisième écran, je sens que ça sera… amusant (voir pas possible).
    • [^] # Re: Entrées multiples == claviers multiples ?

      Posté par  . Évalué à 3.

      Je me demande pareil pour les souris, peut-on paramétrer plusieurs souris indépendemment en ce qui concerne la sensibilité, l'accélération avec le nouveau xinput ? (typiquement quand on a un trackpad, où on veut une faible sensibilité mais une grosse accélération (enfin, pour moi) et une souris où on veut l'inverse)
      • [^] # Re: Entrées multiples == claviers multiples ?

        Posté par  (site web personnel) . Évalué à 6.

        Si mes souvenirs sont bons, on peut facilement faire cela avec un équipement sous USB et un autre sous PS2. Le problème étant d'avoir deux souris USB ou deux claviers USB...

        Ce qui m'inquiète personnellement, c'est que cet aspect mutli-utilisateurs est en train de disparaître. On fait du FastUserSwitch alors qu'il n'y a pas de soucis a envoyer une session X sur le tty 8. On impose NetWorkManager, Avahi... On va bientot être obliger d'avoir toute cette daube sur nos serveurs (si serveur avec X d'installé).

        J'ai cru voir que la dernière debian installe xauth si on installe ssh ! Moi, je veux pouvoir avoir un serveur sans xauth car je ne veux pas que fenêtre graphique puisse s'ouvrir, même à distance et je ne veux pas sur certain serveur n'avoir qu'un bout de Xorg. Moins de code, moins de bogue.

        Bref, c'est bien de faire évolué X et le jour ou X ne tournera plus root, ce sera génial. Mais pensons qu'une machine n'est pas égal a un et un seul utilisateur à la fois !
        • [^] # Re: Entrées multiples == claviers multiples ?

          Posté par  . Évalué à 2.

          J'ai cru voir que la dernière debian installe xauth si on installe ssh ! Moi, je veux pouvoir avoir un serveur sans xauth...

          Effectivement, avec Lenny xauth est installé par défaut avec ssh. Mais seulement en temps que paquet recommandé d'openssh-client et d'openssh-server. Autrement dit, ce n'est pas une obligation.


          apt-get install ssh --no-install-recommends

          aptitude install ssh -R
        • [^] # Re: Entrées multiples == claviers multiples ?

          Posté par  (Mastodon) . Évalué à 2.

          Pour NetworkManager, tu peux désactiver les interfaces que tu ne souhaites pas voir contrôler par lui en ajoutant simplement la directive NETWORKMANAGER=no dans les ifcfg-xthx pour Redhat (et équivalent ailleurs ;) ) Il me semble que system-config-network propose maintenant une case à cochée. (pas ma redhat sous la main pour vérifier, et pas de fedora)

          Globalement je suis bien d' accord avec ton propos. Et j' ai du mal à cerner où nous sommes emmenés... Quel est l' intérêt par exemple du FastUserSwitch ? J' avoue que je ne vois pas. Sur Xorg en particulier, j' avoue que je ne vois pas son utilité sur des machines Intel destinées à être des Personnals Computers...
          En fait, si... mais c' est un peu exprès parceque peut être que la finalité d' utilisation des machines personnelles pour Mr michu est si précise que Xorg semble bien démesuré et plutôt taillé pour les "workstations", avec son adaptabilité à tout Unix et à de nombreuses architectures matérielles.

          Bref les utilisations sont tellement diverses et les possibilités offertes pas les *nix si variées qu' il me semble de moins en moins possible de proposer une solution unique pour tout ça... A défaut de TinyX ou autre DirectFB pour les matos récents et personnels, j' espère que WayLand saura combler ce manque.

          Comme le dit IsNotGood, "(...) rudes pour certains utilisateurs (...) mais (...) ça va se calmer"
          Finalement, ceux disant "distributions spécialisées" il y a qq années ne seraient ils pas les mêmes qui le font ? Wait and See. Perso j' attends en confiance.

          mes 2 cents
          • [^] # Re: Entrées multiples == claviers multiples ?

            Posté par  . Évalué à 3.

            Tiens, avec l'upgrade de sid d'il y a quelques jours, NM s'est mis à ne plus gérer une seule connexion lui même. D'un coté, c'est "bien", parce que c'est ce que voulaient les "power-user" depuis des lustres. Mais d'un autre, maintenant ça casse tout tellement on s'était habitué à cette régression ...
    • [^] # Re: Entrées multiples == claviers multiples ?

      Posté par  . Évalué à 2.

      À mon avis c'est déjà possible d'utiliser deux clavier avec deux keymap différents, juste que par défaut dans les distributions, xorg ne détecte que le clavier virtuel de linux (=somme de tout les claviers branchés)
  • # Amélioration de l'organistion des drivers

    Posté par  . Évalué à 2.

    On en est où dans la réorganistion de Xorg à fin de mieux séparer les drivers graphiques du serveur graphique ? Je crois que c'est l'un des chantiers acteuls.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

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