vendredi 08 août
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

: X11R7.0 sous le sapin de Noël

Posté par Calim' Héros (Jabber id, page perso, ). Modéré le 22 décembre 2005.
Pour fêter Noël, la fondation Xorg nous livre la première version majeure de X11 en plus de dix ans : X11R7.0

La principale avancée de X11R7.0 est sa modularisation (passage d'une archive de sources unique à 287 archives distinctes) et son "autotoolisation", c'est-à-dire le passage à autoconf et automake pour la configuration et la compilation. Cette version est accompagnée d'une petite soeur : X11R6.9. Cette dernière est le pendant "classique" de X11R7.0, comprenant le même code mais non modularisé, et avec l'ancien système de compilation (imake). À l'avenir, la branche monolithique devrait être maintenue, mais les ajouts de nouvelles fonctionnalités seront concentrés sur la branche modulaire (avec l'objectif d'un X11R7.1 à la mi-2006).

Par ailleurs, le chargeur de modules utilise désormais un protocole basé sur libdl et permet entre autre l'utilisation de cette nouvelle mouture sur MIPS, Motorola 68000, HP PA/RISC, etc, ainsi que la compatibilité binaires des modules sur une même architecture (un module compilé sous Linux/x86 pourra donc être utilisé sous OS2/x86, FreeBSD/x86, Hurd/x86).

On notera aussi l'apparition dans ces versions de EXA, une alternative à XAA (XFree86 Acceleration Architecture) pour l'accélération 2D, qui promet de meilleures performances avec les cartes graphiques modernes. Cette architecture n'est cependant pour l'instant supportée que par les drivers i128, radeon et sis, et n'est pas activée par défaut.

On retiendra enfin nombres d'améliorations du support Multi-Head et une réécriture complète de Xinerama, le support (expérimental) de l'accélération 3D pour les cartes Radeon r3xx et r4xx, ou encore la possibilité d'utiliser les définitions de clavier xkbdesc qui supplantent le traditionnel xkbdata et offrent plus de cohérence et de souplesse.

NdM : merci à Guillomovitch pour avoir également proposé la news.

> Lire la dépêche (144 commentaires, moyenne: 3,1).  

Vous avez demandé le commentaire #664039.

Killer feature

Posté par Victor STINNER (page perso, ) le 22/12/2005 à 19:54. (lien). Évalué à 6.

Chaque nouvelle version d'un programme apporte son lot de nouvelles fonctionnalités. Mais là je pense qu'on a vraiment le droit à une killer feature :

Support for more than 12 buttons in the generic mouse driver

(en français : Support des souris de plu de 12 boutons dans le pilote souris de base)

Super, je vais enfin pouvoir brancher ma souris sans boule mais avec 105 touches :-D

Haypo
PS: Plus sérieusement, vous avez une photo de ce genre de monstre ?

  • [^]Re: Killer feature

    Posté par Olivier Samyn (page perso, ) le 22/12/2005 à 20:01. (lien). Évalué à 4.

    Là y'en a tout plein :)
    http://www.logitech.com/index.cfm/products/productlist/BE/FR(...)

    Sur ma souris, y'a par exemple 10 boutons:
    - Btn gauche, droit
    - Molette + click sur la molette ( = 3 boutons)
    - La molette peut basculer de gauche à droite (en plus de la rotation) => 2 boutons supplémentaires
    - Un p'tit bouton derrière la molette
    - 2 boutons à hauteur du pouce

    => 10 boutons

    • [^]Re: Killer feature

      Posté par Ontologia (page perso, ) le 22/12/2005 à 20:06. (lien). Évalué à 8.

      Il en manque plus que deux pour couvrire une gamme : Do - Do# - Ré ...

      Ok je ---> []

    [^]Re: Killer feature

    Posté par Axys () le 22/12/2005 à 20:13. (lien). Évalué à 1.

    La MX1000 de Logitech à 10 boutons (il me semble que dans xorg la roulette compte comme des boutons, ce qui fait 12)... :)
    D'ailleur, à propos de cette souris, sous linux le curseur ne se déplace pas de manière très fluide... Lors de grands mouvements, aucun problème, mais lorsque que j'ai besoin de précision (par exemple, du dessin au pixel sous Gimp), c'est assez génant... je possède une mx500 qui n'a pas ce problème... une idée d'où ça peut venir?

    • [^]Re: Killer feature

      Posté par fenril () le 22/12/2005 à 20:53. (lien). Évalué à 0.

      chez moi ca marche
      google est ton ami.

      Le problème, pour moi n'est pas la fluidité mais qu'une fois sur deux, elle est sur un /dev/input/eventX différent. Mais le fait d'utiliser une distrib en phase de développement n'aide pas beaucoup. :)

      • [^]Re: Killer feature

        Posté par Amand Tihon (page perso, ) le 22/12/2005 à 22:19. (lien). Évalué à 4.

        Pour le /dev/input/eventX, si tu utilises udev, tu peux facilement le forcer sur une valeur "utilisable".

        Tu trouveras une manière de faire sur http://floam.sh.nu/index.xhtml?page=guides&section=mx100(...) par exemple.

        Ma configuration est très légèrement différente :


        KERNEL="event*", SYSFS{idVendor}="046d", SYSFS{idProduct}="c50e" NAME="input/event-mx1000" SYMLINK="input/%k"
        KERNEL="mouse*", SYSFS{idVendor}="046d", SYSFS{idProduct}="c50e" NAME="input/mouse-mx1000" SYMLINK="input/%k"


        Il ne reste plus qu'à spécifier le nom du périphérique dans ton xorg.conf.

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.0538s (dont 0.0057 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.