Journal La sortie de X.Org 7.2

Posté par  .
Étiquettes : aucune
0
16
fév.
2007
La nouvelle version de X.Org est sortie hier, 15 fevrier 2007, la liste des nouveautes est faible puisqu'elle est plus une version mise a jour de la 7.1 pour laisser le temps aux developpeurs de perfectionner la 7.3 qui apportera de nombreux changements dont la tres attendu autoconfiguration de xorg.conf.

Voici donc les modifications tels qu'inscrite sur le site www.x.org
It incorporates significant stability and correctness fixes, including improved autoconfiguration heuristics, enhanced support for GL-based compositing managers such as Compiz and Beryl, and improved support for PCI systems with multiple domains. It also incorporates the new, more extensible XACE security policy framework.

http://xorg.freedesktop.org/wiki/PressReleases/X11R72Release(...)

P.S. Desole pour les accents, la version de developpement de Puppy Linux que j'utilise pour ecrire ce journal ne me permet pas de les utiliser.

  • # XACE security policy framework.

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

    Il y a un pro dans la salle ?
    pour une explication ... avec des mots simples ^^

    • [^] # Re: XACE security policy framework. FRENCH TRANSLATION ATTEMPT

      Posté par  . Évalué à 3.

      http://people.freedesktop.org/~ewalsh/xace_proposal.html

      The XACE (X Access Control Extension) est une gamme de "portes dérobées?" utilisée par des instructions graphiques pour sécuriser les contrôles d'accès. Le but de XACE est de clarifier et d'homogénéiser ces accès en fournissant un mécanisme commun pour des connections graphiques sécurisées. Le concepte est identique au module de sécurité linux (LSM) du noyau linux.

    • [^] # Re: XACE security policy framework.

      Posté par  . Évalué à 2.

      A noter que LSM est un patch noyau pour la série 2.6 qui est là: http://downloads.sourceforge.net/realtime-lsm/rt-lsm-0.8.7-k(...)

      Même mécanisme c'est à dire grosso-modo une authentification basée sur l'uid et le gid du programme mais uniquement pour les processus graphiques pour XACE.

      • [^] # Re: XACE security policy framework.

        Posté par  . Évalué à 1.

        noter que LSM est un patch noyau pour la série 2.6


        Euh non, LSM est une partie standard du noyau 2.6, c'est là dessus que se basent SELinux ou les moins connus AppArmor ou Dazuko.

        Il a d'ailleurs été question de supprimer récemment cette couche du noyau : http://lwn.net/Articles/138042/

        Ce que tu pointes, rien qu'à voir l'url ça doit être un patch pour que le noyau RT (Ingo Molnar toussa) utilise/supporte LSM.

        • [^] # Re: XACE security policy framework.

          Posté par  . Évalué à 1.

          LSM est une partie standard du noyau 2.6

          J'en doute --> grep LSM config-2.6.18.2-34-default
          grep LSM config-2.6.18.2-34-default
          donnent rien c'est pas pris en charge par défaut

          • [^] # Re: XACE security policy framework.

            Posté par  . Évalué à 1.

            Je crois que par "partie standard", le post plus haut voulait dire que c'était dans les sources vanilla du noyau, sans besoin de patcher. LSM fait partie du noyau depuis 2001 ou 2002. Après, effectivement p't'être il est pas activé par défaut.

            Voir notamment un récit par LWN (en anglais) de récentes discussions autour de LSM: http://lwn.net/Articles/180194/

          • [^] # Re: XACE security policy framework.

            Posté par  . Évalué à 2.

            Ca prouve quoi ?
            LSM c'est une infrastructure, pas un module particulier désactivable.

            Tu peux regarder dans la doc qui va avec les sources de ton kernel, la présentation sur LSM : Documentations/DocBook/lsm.tmpl, ou il est indiqué que LSM va être mergé dans la branche 2.5... Désormais LSM c'est les fichiers dans security/

            SELinux s'appuie dessus, et est bien en standard dans le noyau... (cherche SELinux dans ton interface de configuration favorite).

            Sinon dans include/linux/security.h, les belles macros LSM_SETID_ID, LSM_SETID_RE...

            Tu me crois maintenant ;-) ?

  • # driver radeon

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

    Quelqu'un sait-il si le driver libre radeon pour les carte ATI a été amélioré ?
    Je possède une radeon 9250 et bien que sensée être dans les cartes les mieux supportées par ce pilote, il persiste quelques petits défauts d'affichage (même en 2D). Merci si vous êtes plus doués que moi pour trouver cette info !

    • [^] # Re: driver radeon

      Posté par  . Évalué à 2.

      Difficile de repondra a ta question sans description precise. De plus quand Xorg sort cela ne veut plus necessairement dire que les drivers videos sont aussi update. Enfin dans la chaine d'affichage graphique il n'y pas que le driver DDX d'xorg qui gere la carte mais aussi le module DRM (kernel), le DRI et Mesa bref tout ca fait qu'il peut y avoir plusieurs sources a tes problemes.

      Une description plus precises aiderait, sinon cherche sur le bugzilla de freedesktop.

      • [^] # Re: driver radeon

        Posté par  . Évalué à 1.

        En effet, si ce sont les perfs 3d qui t' intéressent c' est plutôt Mesa/dri/drm qu' il faut regarder.
        En général les nouvelles de mesa mettent à jour les pilotes DRI , pour les DRM (direct rendering management) c' est plutôt le kernel.

  • # RAndR

    Posté par  . Évalué à 2.

    J' ai un problème avec RAndR et les pilotes proprio nvidia. Cette interface renvoie de mauvaises valeurs de fréquence de balayage, ce qui m'empèche d'utilser krandrtray sous kde.
    Il semble que ce problème soit réglé avec randr 1.2, mais je n'arrive pas à savoir si xorg7.2 implémente randr 1.2 ou a conservé la version 1.1 de xorg7.1.
    Quelqu'un avec l'info svp? Ou à défaut un lien pour les releasenotes.
    Merci.

    • [^] # Re: RAndR

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

      Si j'ai bien suivi, RanDR 1.2 n'est pas intégré actuellement, il le sera dans le server X 1.3, qui devrait être une mise à jour compatible ABI/API avec le reste de xorg 7.2.
      Xorg 7.3 devrait être quand à lui fourni avec le serveur X 1.4

    • [^] # Re: RAndR

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

      C'est pas un probleme de X.org c'est le drivers Nvidia qui fait ca,
      au lieu de t'afficher ton balayage tu as 50,51,52 qui correspond aux modes dual head etc ... C'est un hack nvidia.


      C'est pour la meme raison que le detecteur de framerate beryl marche pas avec nvidia, et qu'il faut forcer a la main son rafraichisssement ( 80 par ex )

      • [^] # Re: RAndR

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

        Why is the refresh rate not reported correctly by utilities that use the XRandR X extension (e.g., the GNOME "Screen Resolution Preferences" panel, `xrandr -q`, etc)?


        The XRandR X extension is not presently aware of multiple display devices on a single X screen; it only sees the MetaMode bounding box, which may contain one or more actual modes. This means that if multiple MetaModes have the same bounding box, XRandR will not be able to distinguish between them.

        In order to support DynamicTwinView, the NVIDIA X driver must make each MetaMode appear to be unique to XRandR. Presently, the NVIDIA X driver accomplishes this by using the refresh rate as a unique identifier.

        You can use `nvidia-settings -q RefreshRate` to query the actual refresh rate on each display device.

        This behavior can be disabled by setting the X configuration option "DynamicTwinView" to FALSE.



        http://us.download.nvidia.com/XFree86/Linux-x86/1.0-9746/REA(...)

        • [^] # Re: RAndR

          Posté par  . Évalué à 1.

          Ah ben voui , yavaika RTFM.
          Mais j'ai cherché au mauvais endroit et une récente interview de K. Packard m'a conforté dans mon erreur.
          Tout remarche nickel, merci.

        • [^] # Re: RAndR

          Posté par  . Évalué à 1.

          A noter qu'on a le même problème avec les ATI quand on utilise MergedFB (l'équivalent du TwinView). Et ça fait un bout de temps que ce problème existe.

          • [^] # Re: RAndR

            Posté par  . Évalué à 2.

            Enfin le probleme il est pire sur les ATI vu que cela detruit le matos et il y a assez peu de personne pour se porter volontaire pour verifier que ca et je comprend pourquoi!

            • [^] # Re: RAndR

              Posté par  . Évalué à 1.

              Gni ? Tu parles de quoi exactement là ? J'ai jamais détruit ma carte à cause de ça...

              • [^] # Re: RAndR

                Posté par  . Évalué à 4.

                Je parle de ce "petit" bug:

                https://bugs.freedesktop.org/show_bug.cgi?id=4552

                Que tu n'est pas detruit ta carte, tant mieux pour toi (moi non plus mais j'ai ete content de pas avoir fait mumuse avec MergeFB...)

                • [^] # Re: RAndR

                  Posté par  . Évalué à 1.

                  Oui enfin là on parle pas exactement du même problème : celui de la sélection d'un mode en MergedFB par l'interface graphique (qui bug comme généralement la fréquence ne correspond à rien, puisqu'elle est censée représenter la fréquence de 2 écrans différents, ce qui n'est pas possible et donc les devs ont choisi une valeur unique négative). Si c'est pour troller sur un bug du drivers radeon (qui n'apparait que sur des cartes encore pas vraiment supportées, ou en alpha), ce qui n'a rien à voir, change de topic...

                  • [^] # Re: RAndR

                    Posté par  . Évalué à 2.

                    dans ce cas la il serait bienvenu que xorg (ou les distribs) desactive carrement soit l'option MergeFB soit le driver radeon pour ces cartes la car, c'est mon avis et il n'engage que moi, c'est une tres tres mauvaise image pour le xorg/linux si tu detruis ton matos...

Suivre le flux des commentaires

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