Merci beaucoup, je vais regarder ca. Par contre, il est temps de passer a un xorg automatise, le fichier xorg.conf est quand meme assez pourri et long a concevoir -une fois que c'est fait, il est vrai que ca marche bien. Par contre, je trouve hal bugge, et passe par hal me deplait beaucoup -il merdait deja avec le driver ipw3945 pour ma part-.

Pour configurer tout ça dans kde, il suffit d'aller dans kcontrol-->Régionalisation et accessibilité et choisir dans disposition du clavier le modèle de clavier evdev-managed keyboard. Ensuite, vous choisissez le clavier de pays qui vous convient et c'est régler... Reste à faire marcher http://dev.gentoo.org/~compnerd/temp/hal-config-examples/migrate-xorg-to-fdi.py pour que ce soit fonctionnel aussi sous wmii (il faut xf86config ?).

ce script python qui demande le paquet dev-python/pyxf86config (c'est marqué nul part, désolé pour le triple poste).

"le fichier xorg.conf est quand meme assez pourri et long a concevoir" euh... sudo dpkg-reconfigure xserver-xorg

Ouais, pour twinview et xinerama, tu fais comment (me réponds pas nvidia-settings ou le machin d'ubuntu, ça m'affiche effectivement sur les deux écrans, mais c'est les ttys qui y sont ;-) ) ?

Je ne connais pas twinview (sûrement lié à nvidia donc...). Mais ce que tu dis reste faisable à la main après un reconfigure de xserver-xorg (ça change sûrement pas tout le fichier conf...)

Quoiqu'il en soit :
1) c'est pas la dépendance à hal de xserver-xorg qui va le faire à ta place
2) si c'est trop chiant à faire la main, alors il faut coder un utilitaire pour rendre la chose automatique qu'on appelle quand on veut, mais pas imposer un truc à tout le monde

J'ai jamais dis le contraire, et je n'aime pas hal du tout.
Je dis juste que Xorg aurait besoin d'être automatisé, ce qui semble pas infaisable (le noyau sait bien comment gérer le matériel sans trop de configuration lui, ça doit bien pouvoir se faire pour xorg).

Ouais enfin personnellement, j'aime pas trop l'automatisation. Je préfère les utilitaires qui pondent/patchent les fichiers de configuration à la place. C'est une question de goût.

Ce que j'ai peur avec l'automatisation, c'est que ça soit mal fait et que les gens qui ont des configurations un peu exotiques voient X chier dans la colle à cause d'un bête truc optionnel qui améliore à peine les performances pour la configuration standard.

Dargor> Le code de Xorg, c'est un sacré morceau. Faut dire aussi que je l'avais maté avant le split.
Maintenant avec le Xorg modulaire c'est sans doute plus abordable et surtout plus facile pour quelqu'un de rentrer dans le projet.
Bref si tu parviens à t'impliquer dans le projet et à scander haut et fort ce que la majorité non silencieuse pense tout bas (i.e. HAL c'est nul ) tu gagneras toute ma gratitude (Quoi ? C'est nul aussi ? Ah bon... ).

At0m3> Moi j'ai justement peur qu'avec ce genre d'automatisation non seulement la configuration du multi-écran ne devienne pas plus simple mais que les tâches triviales, telles que la configuration du clavier et de la souris deviennent un véritable calvaire à reparamétrer en cas de pépin.

On nous balance du XML et des couches et surcouches de communication inter process (dcop, dbus et maintenant hal) à tour de bras pour automatiser des tâches triviales. Ça ne me plaît pas du tout, plus on ajoute ce genre de trucs, plus on s'éloigne du principe KISS (Keep It Simple and Stupid) qui fait la robustesse et la beauté des systèmes UNIX.
Enfin peut-être que je m'effraie pour rien et que hal ne plante plus une fois sur quatre comme la dernière fois que je l'ai utilisé, que les distributions ont retenu la leçon du passage devfs-->udev (kernel 2.6.8... ça ne nous rajeunit pas tout ça) et que foutre en stable par défaut un machin dont la configuration change toute les semaines (non je suis méchant, c'était tout les mois) c'est pas hyper top... Seul l'avenir nous le dira.

--
Sankukai aka le vieux con.

Je suis d'accord avec vous, mais pouvoir paramétrer à chaud sans problème, ça n'empêche pas non plus d'utiliser un fichier statique. Et puis ça évites pour les distributions user-friendly d'utiliser un éditeur de fichier statique graphique en plus.

Et pour le hal c'est nul, je pense qu'on est tous d'accord là dessus ;-) , et je parlais pour le cas général. À l'heure actuelle, utiliser hal pour configurer Xorg n'est clairement pas une bonne idée :
_l'utilisateur devra éditer un autre fichier (en xml en plus )
_hal, c'est instable
Mais pour les développeurs, ça évite de maintenir x11-drivers/xf86-input-****** alors qu'hal peut déjà le gérer.

Le code de Xorg, c'est un sacré morceau. Faut dire aussi que je l'avais maté avant le split. Maintenant avec le Xorg modulaire c'est sans doute plus abordable et surtout plus facile pour quelqu'un de rentrer dans le projet.

Ouais, enfin je pensais surtout au code d'OpenBSD, il me manque quelques options aux utilitaires de base (genre -v, pas dur à faire...)

Mais pour les développeurs, ça évite de maintenir x11-drivers/xf86-input-****** alors qu'hal peut déjà le gérer.

Ouais enfin X était censé être indépendant de l'OS à la base... Y'en a marre de tous ces projets qui pensent qu'il n'y a d'OS que Linux. Manquerait plus qu'ils nous passent X en GPLv3 tiens...