Journal De l'évolution du serveur X et de sa configurabilité

Posté par .
Tags : aucun
15
16
déc.
2008
Dans ce journal je souhaite discuter des récentes évolutions du serveur X et plus précisément de l'auto-configuration et du passage à evdev. Pour simplifier la configuration et permettre le branchement à chaud, le serveur X s'appuie de plus en plus lourdement (si si) sur HAL.

J'utilise une disposition clavier personnalisée ne figurant pas dans les paquets des distributions et n'ayant pas de raison d'y figurer : elle est notamment basée sur l'excellente disposition bépo (dont aucune version récente n'est disponible dans les paquets non plus). Pour utiliser une disposition clavier personnalisée proprement pour tout le système (j'y tiens) il faut la copier dans un fichier de /usr/share/X11/xkb/symbols/ qui sera alors écrasé à chaque mise à jour du paquet correspondant. Merveilleux.

Maintenant (depuis Fedora 10 pour moi), c'est encore mieux, grâce à evdev. La configuration des périphériques d'entrée dans xorg.conf est ignorée. Dorénavant, elle est effectuée notamment à partir du fichier /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi. Cela ne s'invente pas. C'est un fichier XML, bien abscons, de moins de 10 lignes et sans commentaires, qui contient la chaîne "fedora-setup-keyboard".
Euh, voyons la documentation. Il n'y a pas de documentation digne de ce nom. Comment font les autres alors ? Réponse un peu partout sur le web : ils éditent à La Rache® les fichiers XML dans /usr/share/hal/fdi/ …

Précisons, tout de même, que certaines distributions ont placé ces fichiers dans /etc/hal/fdi/ , ce qui permet de ne pas voir les modifications écrasées. Dans ce cas, nous passons d'un fichier texte simple, lisible et documenté à un obscur fichier XML.

Cependant, si chez Fedora les fichiers sont dans /usr c'est que nous ne sommes pas censés les éditer.

D'où vient tout ceci ?
Un rpm -qf /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi dénonce xorg-x11-server-Xorg.

% rpm -ql xorg-x11-server-Xorg
[...]
/usr/bin/fedora-setup-keyboard
[...]
/usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi
[...]


% fedora-setup-keyboard
Traceback (most recent call last):
File "", line 1, in
KeyError: 'fr-dvorak-bepo'


% cat /usr/bin/fedora-setup-keyboard
#!/bin/sh
#
# Trivial egregious hack to load the console keyboard layout into XKB.
#
# Yes, this should really just be written in python. If you can figure
# out how to make hal callouts written in python _work_, then please
# let me know. In the meantime, we'll do this.

[[ -x /usr/bin/python ]] || exit 0
[[ -x /usr/bin/hal-set-property ]] || exit 0

source /etc/sysconfig/keyboard >& /dev/null || exit 0

[[ -n "$KEYTABLE" ]] || exit 0

rhplquery () {
/usr/bin/python -c "import rhpl.keyboard_models; m = rhpl.keyboard_models.KeyboardModels().get_models(); print \"junk='%s'layout='%s' model='%s' variant='%s' options='%s'\" % tuple(m[\"$1\"])" || echo "exit 0"
}

eval `rhplquery $KEYTABLE`

hal_set () {
if [[ -n "${!1}" ]]; then
/usr/bin/hal-set-property --direct --udi "$UDI" --key input.xkb.$1 --string "${!1}"
else
/usr/bin/hal-set-property --direct --udi "$UDI" --key input.xkb.$1 --remove
fi
}

hal_set layout
hal_set model
hal_set variant
hal_set options

En effet :

% cat /etc/sysconfig/keyboard
KEYBOARDTYPE="pc"
KEYTABLE="fr-dvorak-bepo"


Le script fedora-setup-keyboard précédent utilise la « bibliothèque » keyboard_models.py pour vérifier si une disposition est « disponible ».

% cat /usr/lib/python2.5/site-packages/rhpl/keyboard_models.py
[...]
def __init__(self):
# NOTE: to add a keyboard model to this dict, copy the comment
# above all of them, and then the key should be the console layout
# name. val is [N_('keyboard|Keyboard Name'), xlayout, kbmodel,
# variant, options]
self._modelDict = {
# Translators: the word before the bar is just context and
# doesn't need to be translated. Only after will be translated.
'ar-azerty' : [N_('keyboard|Arabic (azerty)'), 'us,ara', 'pc105', 'azerty', 'grp:shifts_toggle,grp_led:scroll'],
# Translators: the word before the bar is just context and
# doesn't need to be translated. Only after will be translated.
'ar-azerty-digits' : [N_('keyboard|Arabic (azerty/digits)'), 'us,ara', 'pc105', 'azerty_digits', 'grp:shifts_toggle,grp_led:scroll'],
# Translators: the word before the bar is just context and
# doesn't need to be translated. Only after will be translated.
'ar-digits' : [N_('keyboard|Arabic (digits)'), 'us,ara', 'pc105', 'digits', 'grp:shifts_toggle,grp_led:scroll'],
[...]


On n'arrête pas le progrès… Conclusion, il est impossible de configurer proprement une disposition clavier personnalisée : c'est pire que sous Windows. Je ne commenterai pas l'implémentation mais, tout de même, il devrait être possible de mettre le fichier dans /usr/local/share/X11/xkb/symbols/ et les options dans /etc/sysconfig/keyboard ou ailleurs et que cela soit automatiquement pris en compte. De même pour le mode texte qui utilise une keymap indépendante du serveur X11 (/lib/kbd/keymaps/ pour Fedora).

Pour l'instant (mais pour combien de temps ?) il est encore possible de s'en sortir en spécifiant, à l'ancienne, dans la section clavier du xorg.conf :

Driver "evdev" # et non kbd
Option "Device" "/dev/input/eventX" # obligatoire
Option "XkbModel" "xx"
Option "XkbLayout" "xx"
Option "XkbVariant" "xx"
Option "XkbOptions" "xx"

Bien entendu il faudra réinstaller la disposition clavier à chaque fois qu'elle est écrasée : il ne faut pas abuser non plus.

Je trouve qu'il est de plus en plus difficile de personnaliser son système. Évidemment je peux envoyer un patch mais cela prend du temps et puis je n'ai rien cassé moi. Ce problème peut sembler un détail mais c'est tout de même frustrant. Avec la suppression du multi-gpu (que j'utilisais) et ce nouveau système de configuration je commence à être sérieusement ennuyé par ces régressions (même si je n'oublie pas les améliorations). Le serveur X a besoin d'être modernisé, c'est certain, mais pas n'importe comment.
Qu'en pensez-vous ? Est-ce mieux géré dans d'autres distributions ? Je n'ai rien compris ou bien cela mérite-t-il un rapport de bug ?
  • # Même bateau

    Posté par . Évalué à 3.

    Sous Gentoo aussi c'est la merde, même pour faire marcher un simple azerty sous KDE ou KDM.
    Depuis une mise à jour d’il y a une semaine, mon touchpad a également arrêté de marcher.

    Un post intéressant d’un développeur qui explique un peu comment ça fonctionne :
    http://forums.gentoo.org/viewtopic-t-641870-postdays-0-posto(...)
    • [^] # Re: Même bateau

      Posté par . Évalué à 1.

      Depuis une mise à jour d’il y a une semaine, mon touchpad a également arrêté de marcher.

      Condoléances. Moi c'est pour ma tablette graphique que j'ai peur. Pour l'instant elle fonctionne encore avec xorg.conf et j'espère qu'il y aura de la documentation disponible quand il faudra aller éditer du XML pour la paramétrer (modification de la sensibilité à la pression etc).
  • # Plateforme de lancement de Troll en construction

    Posté par . Évalué à 5.

    [Phase de Lancement]
    Parce que Fedora fait tout pour que l'utilisateur prenne plaisir à passer plus de temps à bidouiller, c'est un système expérimental pour les expérimentateurs!
    [Mise en orbite du Troll: OK!]

    Sinon, j'ai fait quelques bidouilles sur ma Debian parce que j'ai un clavier qwerty que j'utilise en azerty (si si, regardez attentivement, il manque une précieuse touche pour faire < et >). Je n'ai pas encore pris le temps d'apprendre le bépo, mais j'y pense!

    Plus sérieusement:
    Moi, ce que je ne comprends toujours pas, c'est pourquoi X ne peut pas utiliser la configuration du clavier proposée par le système:
    - un "wrapper" standard pour mapper le clavier
    - chaque OS se débrouille pour développer l'interface avec sa gestion clavier sous-jacente, pas de problème de "marche que pour Linux, et les BSD alors? etc."

    L'évolution de X va vers une meilleure interface avec l'OS pour la carte graphique (si j'ai bien compris: le driver passe du côté du noyau, et X appellera le driver, corrigez-moi si je me trompe, et ça évitera d'avoir des effets spéciaux au démarrage de X qui font peur aux débutants, entre autres avantages bien sûr...).

    Pourquoi donc continuer à gérer le clavier, les souris, etc. dans X? Ca ne relève pas de l'affichage, si?? C'est le boulot de l'OS!

    C'était ma contribution à la gueulante, bonne journée à toutes et à tous!
    • [^] # Re: Plateforme de lancement de Troll en construction

      Posté par . Évalué à 7.

      Plus sérieusement:
      Moi, ce que je ne comprends toujours pas, c'est pourquoi X ne peut pas utiliser la configuration du clavier proposée par le système:
      - un "wrapper" standard pour mapper le clavier
      - chaque OS se débrouille pour développer l'interface avec sa gestion clavier sous-jacente, pas de problème de "marche que pour Linux, et les BSD alors? etc."


      Je ne sais pas en ce qui concerne les autres variantes BSD, mais OpenBSD fait ça. Grâce à l'infrastructure wscons(4) ( http://www.openbsd.org/cgi-bin/man.cgi?query=wscons&sekt(...) ) et à un petit patch intégré à Xenocara (Xorg avec des patchs).

      Du coup, un petit "echo fr > /etc/kbdtype" et pouf on a un clavier azerty dans la console et dans Xorg sans avoir à toucher quoi que ce soit d'autre (en virant éventuellement le fichier xorg.conf qui ne vous sert probablement à rien).

      Mais bon ça ne fait que détecter la disposition clavier et sa variante de la console pour trouver l'équivalente dans les /etc/X11/xkb/symbols/* d'Xorg. Mais c'est déjà pas mal.
      • [^] # Re: Plateforme de lancement de Troll en construction

        Posté par . Évalué à 4.

        C'est "presque pareil" pour NetBSD.
      • [^] # Re: Plateforme de lancement de Troll en construction

        Posté par . Évalué à 1.


        Du coup, un petit "echo fr > /etc/kbdtype" et pouf on a un clavier azerty dans la console et dans Xorg sans avoir à toucher quoi que ce soit d'autre (en virant éventuellement le fichier xorg.conf qui ne vous sert probablement à rien).

        Mais bon ça ne fait que détecter la disposition clavier et sa variante de la console pour trouver l'équivalente dans les /etc/X11/xkb/symbols/* d'Xorg. Mais c'est déjà pas mal.


        C'est vrai que c'est très élégant (et très UNIX). Avoir un dossier /etc/X11/xkb/symbols/ où déposer les fichiers personnalisés et une détection automatique résoudrait le problème pour Linux.
    • [^] # Re: Plateforme de lancement de Troll en construction

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

      En plus une distribution qui écrase les fichier de config a chaque update.... on a vu mieux.
      • [^] # Re: Plateforme de lancement de Troll en construction

        Posté par . Évalué à 1.

        Ce ne sont pas des fichiers de config, ce sont des librairies de formats de claviers :-)
      • [^] # Re: Plateforme de lancement de Troll en construction

        Posté par . Évalué à 1.

        Fedora n'écrase pas les fichiers dans /etc . En fait le fichier de configuration est censé être /etc/sysconfig/keyboard mais c'est très insuffisant : il n'y a pas de disposition personnalisée possible puisqu'il s'appuie sur la bibliothèque python.
        Normalement, il faut créer des fichiers XML dans /etc/hal/fdi/ mais, comme il n'y a pas de documentation correcte disponible, la plupart des gens éditent directement, au petit bonheur la chance, les fichiers dans /usr/share/hal/fdi/policy/10osvendor/ . Ces fichiers seront écrasés à chaque mise à jour (c'est à dire souvent avec Fedora).

        Par contre effectivement, le fichier de la disposition clavier dans /usr/share/X11/xkb/symbols/ sera tout le temps écrasé puisqu'on ne peut pas le mettre ailleurs : mais ce n'est pas spécifique à Fedora.
        • [^] # Re: Plateforme de lancement de Troll en construction

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

          Il y a aussi une hiérarchie FDI dans /etc/hal/fdi ... Il me semblait que l'idée c'était de mettre ta config. personnalisée là-dedans pour faire en sorte qu'elle écrase la config. livrée avec hal qui se trouve dans /usr/share/hal.
  • # Sous OpenBSD,

    Posté par . Évalué à 5.

    Sous OpenBSD, Il n'y a pas d'hal (et tout le bordel qui va avec) du coup, c'est beaucoup plus simple à configurer.

    J'ai créé un fichier "/etc/X11/xkb/symbols/pc/bepo" qui contient quelque chose du genre :
    partial alphanumeric_keys
    xkb_symbols "bepo" {
    // ma disposition personnelle des touches...
    };


    Et ensuite pour utiliser automatiquement cette disposition, je modifie le fichier "/etc/X11/xdm/Xsetup_0" d'XDM en y ajoutant:
    setxkbmap bepo &

    C'est une solution parmi tant d'autres.

    En revanche sous OpenBSD, il doit être possible de charger la disposition bépo sans à avoir à modifier le fichier xorg.conf ou les fichiers de configuration de XDM (comme je fais ici), car l'xorg d'OpenBSD détecte automatiquement la disposition clavier de la console et l'applique au serveur X. Pour ce faire il faut utiliser le clavier bépo en mode console :
    echo fr.dvorak > /etc/kbd
    et mettre sa disposition de clavier dans le fichier "/etc/X11/xkb/symbols/pc/fr" avec pour nom de variante "dvorak" (et non pas "bepo").
    • [^] # Re: Sous OpenBSD,

      Posté par . Évalué à 3.

      echo fr.dvorak > /etc/kbd
      Pour être exact, c'est "echo fr.dvorak > /etc/kbdtype" et non pas "echo fr.dvorak > /etc/kbd". kbd(8), c'est le programme pour changer de disposition clavier à la main.
    • [^] # Re: Sous OpenBSD,

      Posté par . Évalué à 1.

      C'est génial ça ! Ceci dit le branchement à chaud fourni par HAL est utile. Il faudrait pouvoir mettre la disposition du clavier dans un dossier où elle ne serait pas écrasée type /etc/X11/xkb/symbols/ comme OpenBSD.
  • # setxkbmap

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

    Comme j'apprends le dvorak en ce moment, je passe régulièrement du fr au dvorak. Sous debian (sur un macbook), je me suis créé 2 scripts.

    Pour le fr:
    $ cat ~/bin/fr
    #!/bin/sh
    setxkbmap -model macbook79 -layout fr -option lv3:rwin_switch,ctrl:nocaps


    et pour le dvorak:
    $ cat ~/bin/dvorak
    #!/bin/sh
    setxkbmap -model pc105 -layout fr -variant bepo


    du coup pour switcher je tape juste fr ou dvorak.
    • [^] # Re: setxkbmap

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

      Bin crée toi des alias plutôt que des scripts pour des commandes d'une seule ligne...
      • [^] # Re: setxkbmap

        Posté par . Évalué à 4.

        comment tu mets l'auteur, la date ou le numéro de version, des commentaires et une copie complète de la GPL et enfin ton .sig dans un alias ?
        • [^] # Re: setxkbmap

          Posté par . Évalué à 0.

          Depuis quand on peut mettre une commande et son utilisation sous licence... o_O
  • # hal

    Posté par . Évalué à 6.

    Ce qui me surprend tjs c'est que (il me semble) chaque distro fait sa propre cuisine derrière hal. En fait il y a constamment des régressions et il me semble du matériel moins supporté.

    J'ai mis archlinux depuis quelques jours et j'ai déjà eu plusieurs problèmes avec hal, dbus...

    Les hotkeys, la détection du lid de mon thinkpad marchent mal. Certains scripts pour l'acpi plus étoffé dans ubuntu sont absents dans arch.

    Je ne jette pas la faute sur arch, mais c'est hallucinant que concernant la détection matérielle il n'y aie aucun effort commun entre les distributions.
    • [^] # Re: hal

      Posté par . Évalué à 2.

      Une page sur le nouveau fonctionnement du serveur X :

      http://wiki.archlinux.fr/howto:indispensable:xorg?s=xorg%20e(...)
      • [^] # Re: hal

        Posté par . Évalué à 2.

        Merci, j'ai pas eu trop de problème avec ca mais tjs utile.

        D'une manière générale les wiki de arch sont super bien.

        Le problème que j'ai encore (malgré plusieurs recherche et essais) c'est le power management sous gnome qui malgré le fait qu'il soit activé (par exemple suspend quand on ferme le lid), que l'événement acpi est bien vu et que si on clique sur l'icône est qu'on choisis suspend ca marche, en fermant le lid rien ne se passe.

        Alors bien sur je peux mettre dans /etc/acpi/handler.sh mais si c'est pas gnome qui l'active, il ne me demande pas mon mot de passe lors du réveil.
  • # Tu t'y prends mal

    Posté par . Évalué à 9.

    J'ai eu (comme beaucoup de monde) le même problème de changement de X.

    Donc voici la procédure :

    1/copier /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi dans /etc/hal/fdi/policy/

    2/modifier le fichier /etc/hal/fdi/policy/10-x11-keymap.fdi , en effet le fichier dans usr est la valeur par défaut, mais toute valeur spécifiée dans etc passera avant, et ne sera pas modifiée par la prochaine MAJ du paquet
    • [^] # Re: Tu t'y prends mal

      Posté par . Évalué à 1.

      Chez moi, ça donne /etc/hal/fdi/policy/10-x11-keymap.fdi :

      <?xml version="1.0" encoding="ISO-8859-1"?>
      <deviceinfo version="0.2">
      <device>
      <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.rules" type="string">base</merge>
      <merge key="input.xkb.model" type="string">evdev</merge>
      <merge key="input.xkb.layout" type="string">fr</merge>
      <merge key="input.xkb.variant" type="string">bepo</merge>
      <merge key="input.xkb.options" type="string">compose:menu</merge>
      </match>
      </device>
      </deviceinfo>

      Ça mériterait de la doc mais ça reste lisible je trouve.
      Le bépo est intégré à /usr/share/X11/xkb/symbols/fr sous le nom de variante bepo.
      Pour les soucis de mise à jour, j'ai nommé le fichier modifié frbepo et je fais un lien symbolique que je rétablis à chaque mise à jour (rare).
      Il y a sûrement moyen de faire plus propre, genre utiliser directement le fichier séparé.
      • [^] # Re: Tu t'y prends mal

        Posté par . Évalué à 4.

        Plus simplement, il suffit de créer un fichier /usr/share/X11/xkb/symbols/fr_bepo (ou n'importe quel nom qui ne rentre pas en conflit avec l'existant) avec les définitions de touches et d'utiliser "fr_bepo" comme "XkbLayout". Et hop, plus de soucis avec les mises à jour.

        En ce qui concerne le sujet initial du journal, il suffit normalement d'utiliser :

        Section "ServerFlags"
        Option "AutoAddDevices" "False"
        EndSection

        dans Xorg.conf pour continuer à utiliser l'ancien comportement de Xorg vis à vis des périphériques (mais par contre on perd les avantages du branchement à chaud de ceux-ci).

        Yannick
      • [^] # Re: Tu t'y prends mal

        Posté par . Évalué à 2.


        Ça mériterait de la doc mais ça reste lisible je trouve.

        Oui, ce qui m'ennuie le plus c'est le manque de documentation. Néanmoins je trouve que c'est nettement plus ardu à éditer que xorg.conf. Après, une fois fait, ce n'est pas illisible, c'est sûr. Il faut quand même des notions de XML ou une documentation de qualité pour écrire un tel fichier. Le XML c'est surtout bien pour être modifié par des programmes et justement (pour l'instant ?) il n'y a pas de logiciels de configuration pour ces fichiers.

        À la base je suis passé de Windows à Linux parce que j'ai beaucoup apprécié la documentation abondante et claire ainsi que la possibilité de personnaliser proprement son système. Le système donnait une impression de simplicité et de grande robustesse tout en étant facilement configurable à souhait. J'ai l'impression que ce n'est plus la priorité et je le regrette. Évidemment il faut nuancer : il y a aussi de grandes améliorations, tout peut encore s'améliorer pour ce problème, cela reste du libre (et pour moi c'est l'essentiel) et on n'édite pas encore des fichiers de configurations binaires à l'éditeur hexadécimal :)


        Le bépo est intégré à /usr/share/X11/xkb/symbols/fr sous le nom de variante bepo.

        C'est une vieille version et puis je n'utilise pas exactement le bépo.


        Pour les soucis de mise à jour, j'ai nommé le fichier modifié frbepo et je fais un lien symbolique que je rétablis à chaque mise à jour (rare).

        C'est également ce que je fais et en plus d'être dégueulasse (on n'écrit pas dans les dossiers gérés par le système de paquet) cela demande de la maintenance : les mises à jour ne sont pas rare avec Fedora.
  • # pas mieux

    Posté par . Évalué à 1.

    j'utilise le mode 8 bit avec une resolution de 640x480 , lorsque j'installe un distribution je m'empresse d'aller dans xorg.conf faire mes petites modif bien sympa.

    lors de l'installation de la derniere ubuntu je lance vim xorg.conf pour editer mes 2 lignes:

    -rw-r--r-- 1 root root 0 2008-12-16 09:56 xorg.conf

    ah ben le fichier est vide, un petit man m'apprend que maintenant tout est automatiques mais que si on veut vraiment on peut creer un fichier xorg.conf il seras alors utilisé.

    super ! se taper un xorg.conf from scratch. j'en recupere un sur internet et j'arrive quand meme a lancer X mais sans l'acceleration materiel. mais bon j'ai mes 8 bit en 640x480. si quelqu'un a une idée pour le forcer a ecrire un xorg.conf histoire de le modifier par la suite :'(

    c'est vraiment une grosse regression je trouve, sans compter ton histoire avec des fichiers en xml.
    • [^] # Re: pas mieux

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

      X -configure ? Comme au bon vieux temps ?
      • [^] # Re: pas mieux

        Posté par . Évalué à 2.

        ou dpkg-reconfigure xserver-xorg, ça devrait le faire aussi
    • [^] # Re: pas mieux

      Posté par . Évalué à 4.

      Tu peux essayer un petit « X -configure », ça te génère un xorg.conf complet dans le répertoire où tu te trouve.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: pas mieux

      Posté par . Évalué à 4.

      Je pense que tu peux ajouter seulement les lignes de conf qui t'intéresse. xorg utilisera l'autodetection pour les lignes manquantes.
  • # "c'est pire que sous Windows"

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

    Pour une fois que ce n'est pas moi qui le dit...
  • # Je me marre !!!!

    Posté par . Évalué à 8.

    Ha Ha Ha !!! J'entends encore crier ici et ailleurs les gens qui reprochaient au projet xfree86 de trainer dans les évolutions du bouzin et crier leur joie lors du fork .... Moi je dirais "Vous l'avez voulu, vous l'avez eu !!!" .

    Sinon c'est le genre de problème qui m'a fait passer de Linux à BSD : Les développeurs noyau et de softs linux passent leur temps à casser des trucs qui marchent de façon simple pour développer des trucs complexe qui ne marchent pas bien, sans les documenter de façon claire, juste pour le plaisir .... D'autre part la tendance est en ce moment au "tout XML un peu partout sans raison" .... Peut-être faudrait-il penser à arrêter, et utiliser le XML là ou c'est vraiment utile ...
    • [^] # Re: Je me marre !!!!

      Posté par . Évalué à 10.

      Peut-être faudrait-il penser à arrêter, et utiliser le XML là ou c'est vraiment utile ...

      "XML is like violence. If it doesn't work, use more!"

      ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

  • # C'est tout jeune

    Posté par . Évalué à 6.

    C'est tout jeune cette nouvelle façon de faire chez Xorg, laissons leur le temps de murir un peu avant de taper dessus.
    • [^] # Re: C'est tout jeune

      Posté par . Évalué à 7.

      Je suis assez d'accord. Je ne pense pas que cette évolution soit une régression.

      Ce qui se passe, est simplement que le support matériel est déporté vers des couches basses du systèmes.

      Évidemment, ça ne se fait pas en un jour, mais les développeurs de Xorg ont du considérer que le support de l'abstraction matérielle était suffisament mature pour pouvoir l'utiliser dans leur logiciel.

      Ce que je comprends, c'est que maintenant, les efforts d'intégration devront se faire en majorité sur HAL, DBUS, etc, et plus sur le serveur X.

      Je pense que c'est avancer sur le chemin de l'uniformisation des technologies dans Linux. On a une factorisation du code, et suivant la tradition Unix, on utilise un outil pour faire une chose et pour la faire bien, enfin c'est comme ça que je le comprends.
      • [^] # Re: C'est tout jeune

        Posté par . Évalué à 6.

        Je suis assez d'accord. Je ne pense pas que cette évolution soit une régression.

        Bien sur que si ... A partir du moment ou un truc qui fonctionnait avant ne fonctionne plus dans cette version, c'est une régression ...

        Évidemment, ça ne se fait pas en un jour, mais les développeurs de Xorg ont du considérer que le support de l'abstraction matérielle était suffisament mature pour pouvoir l'utiliser dans leur logiciel.

        Dans ce cas on sort ça en version beta ...

        Ce que je comprends, c'est que maintenant, les efforts d'intégration devront se faire en majorité sur HAL, DBUS, etc, et plus sur le serveur X.

        Je pense que c'est avancer sur le chemin de l'uniformisation des technologies dans Linux. On a une factorisation du code, et suivant la tradition Unix, on utilise un outil pour faire une chose et pour la faire bien, enfin c'est comme ça que je le comprends.


        Linux, Xorg et beaucoup de softs s'éloignent de plus en plus de la tradition d'Unix .... Seule l'arborescence et quelques commandes ressemblent encore à Unix mais de moins en moins ...
        • [^] # Re: C'est tout jeune

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

          « Bien sur que si ... A partir du moment ou un truc qui fonctionnait avant ne fonctionne plus dans cette version, c'est une régression ... »

          Modulo l’ajout de 3 lignes dans ton xorg.conf, le dernier Xorg se comportera de manière traditionnelle (sans HAL).
          Donc je ne vois pas où est la régression si on peut le faire fonctionner comme avant avec une configuration des fichiers qui est sensiblement la même.
          C’est un peu comme quand il y avait eu la cohabitation de devfs et de udev un moment donné (c’est peut-être pas le meilleur exemple)…

          « Linux, Xorg et beaucoup de softs s'éloignent de plus en plus de la tradition d'Unix .... Seule l'arborescence et quelques commandes ressemblent encore à Unix mais de moins en moins ... »

          En même temps l’OS Linux se base traditionnellement sur des outils GNU et “GNU is not unix” en même temps ;)
          • [^] # Re: C'est tout jeune

            Posté par . Évalué à 1.

            Modulo l’ajout de 3 lignes dans ton xorg.conf, le dernier Xorg se comportera de manière traditionnelle (sans HAL).


            Non, ce devrait être l'inverse : supprimer les lignes lorsque l'on veut activer la fonctionnalité.

            En même temps l’OS Linux se base traditionnellement sur des outils GNU et “GNU is not unix” en même temps ;)


            En même temps, GNU se voulait à l'origine un système "unix" sans l'être réelement (un clone quoi) ....
            • [^] # Re: C'est tout jeune

              Posté par . Évalué à 5.

              Non, ce devrait être l'inverse

              Pourquoi donc, pour forcer l'utilisateur à mettre la main dans le cambouis et à le foutre dans la merde quand il change de config ? à faire faire le boulot de configuration par la distribution (avec l'éparpillement qu'on connait) ?
              • [^] # Re: C'est tout jeune

                Posté par . Évalué à 2.

                Pourquoi ? Ca change quoi par rapport à la situation actuelle ? Là la nouveauté ne marche pas. N'importe comment l'utilisateur doit mettre les mains dans le cambouis ....
                • [^] # Re: C'est tout jeune

                  Posté par . Évalué à 3.

                  C'est une question de nombre d'utilisateurs pour lesquels ça marche et pour lesquels ça marche pas ... Après t'as aussi une histoire de défauts de jeunesses ...
                  • [^] # Re: C'est tout jeune

                    Posté par . Évalué à 3.

                    Pour ma part j'aurais tendance à mettre ce genre de fonctionnalité nouvelle en option, et laisser à l'utilisateur le choix de l'installer ou non (un peu comme les options expérimentales du noyau)... Cela dit le journal parlait de Fedora ... qui elle-même est une distrib utilisée pour tester ce genre de fonctionnalité, et j'avais oublié ce détail lorsque j'ai répondu.

                    Cependant dcelà ne change pas grand chose à ce que je disais auparavant : il y a plein de trucs qui marchaient de façon simple sous GNU/Linux et qui ont été remplacés par des trucs plus complexes et qui marchent moins bien. Je n'ai malhereusement pas d'exemple en tête ( ah si un exemple : la détection des périphériques au boot il y a quelques temps qui prenait des plombes pour se faire. Ca a peut-être été corrigé ensuite mais je trouve qu'on a remplacé un truc simple par une usine à gaz ...).

                    Il y a aussi cette manie de mettre du XML partout qui est un peu pénible. XML est un truc vereux qui n'apporte pas forcément grand chose de plus pour de la coniuration système. Un fichier de conf classique avec un truc du genre param=valeur est souvent largement suffisant. Attention, ça ne veut pas dire que je n'aime pas XML, simplement que ce n'est pas toujours utilisé à bon escient.
            • [^] # Re: C'est tout jeune

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

              En même temps, les distributions peuvent ajouter ces 3 lignes dans leurs paquets. Ce sont elles qui ont vraiment fait le choix de laisser tout à HAL.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Gentoo

    Posté par . Évalué à 4.

    Au moins, je comprends pourquoi les mainteneurs gentoo ont choisi de masquer les paquets de xorg supérieur à la version 7.2...

Suivre le flux des commentaires

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