et c'est pas possible d'arranger tout ça :s ?

Nope Chris, je tourne également sous Archlinux.

SachiNosaki : et ? Tu as une configuration différente, donc c'est pas anormale si c'est toi ça marche et pas chez lui. Ça veut juste dire qu'il y a un problème de configuration (que je situe dans openbox pour le moment).

Quand on met dans son .xinitrc qu'on veut un clavier azerty et qu'on finit avec un clavier en qwerty, c'est soit que le xinitrc n'est pas lu, soit qu'une commande après a remis le bazar.

donc en gros je vais me passer de openbox quoi :s

Où chercher à le configurer comme il faut.

Allez, un petit test :
$ echo $LANG

Pourtant, je l'avais déjà fait sous archlinux avec openbox et cela avait très bien marché

Comment tu y-est pris ?

je viens de remarquer au démarrage que lors du chargement de arch que j'ai loading console Font : lat9w-26 [fail] apparait c'est possible que ça ai un lien avec mon affaire ?
sinon ta commande donne :
[squall@BGU ~]$ echo $LANG
fr_FR.UTF-8
[squall@BGU ~]$

« c'est possible que ça ai un lien avec mon affaire ? » absolument aucun. Déjà ceci ne concerne que les ttys (ctrl+alt+Fn pour n <= 6). Ensuite c'est absolument bénin et ça se traduit en : "je veux te mettre une jolie police, mais je ne la trouve pas donc garder ta police crarca".

J'aurais vraiment aimé voir un en_US.UTF8 pour $LANG. C'était mon hyphothèse la plus crédible.

Fouille ta conf de OpenBox ainsi que le contenu de /etc/X11/xorg.conf.d, il doit y avoir un endroit qui force le clavier à être en qwerty.

Est ce que tu as francisé ton installation comme la doc l'indique ?

Sinon si tu veux savoir si c'est xorg ou openbox, tu commentes ton .xinitrc et tu lances startx.

Tu auras l'interface par défaut et verra si ton clavier est aussi qwerty

Non... pas startx... la vraie commande c'est xinit.

En plus, dans ce cas précis, ça pourrait bien être startx le fautif (j'avais pas pensé que slim pouvait bêtement lancer startx... mais en fait c'est très crédible).

j'ai que openbox, et j'ai vérifié les fichiers rien d'anormal tout est bien renseigné ...

bon le problème est résolu, en faisant un recherche sur le forum de Archlinux :
http://forums.archlinux.fr/post57952.html?hilit=clavier%20qwerty#p57952

Merci de votre aide !

Je te conseille oss à la place de latin9. C'est un peu le jour et là nuit au niveau des caratères fournis par la touche AltGr.

J'vois ce que tu veux dire. Mais j'ai plus besoin de la commande setxkbamp : j'ai pu trouver la variante française du clavier suisse.

Merci du conseil

Mais alors pour finir, c'est bien slim le fautif dans l'affaire?

J'ai l'impression que c'est la machinerie en entier qui est fautive. Manifestement, les outils configurés automagiquement n'interagissent pas bien, ce qui donne lieu à ce genre de bogue mystique.

La solution était bien de reconfigurer à la main, comme souvent. Par contre, vu que la solution est finalement de faire comme dans le message 0, je m'étonne qu'on ait traîné si longtemps sur ce sujet.

j'utilise slim sous squeeze, et je n'ai pas de .xinitrc, je pense que c'est .xsession qui est lu.

En fait j'ai configuré à l'origine comme la doc archlinux et dans un second temps j'ai vérifié que mes fichiers étaient bien configurés comme la doc le conseillait.
Au final la configuration qui est donnée sur la doc n'est pas bonne ceci expliquant le fait que je pensais avoir des fichiers bien configurés.
Et concernant le fichier .xinitrc j'ai mis une commande fausse à l'intérieur pour vérifier et slim utilise bien ce fichier dans mon cas ;).

Je pense que c'est comme tous les autres outils du genre (qingy compris) ... ça appelle startx qui commence par regarder s'il existe un .xsession et qui se rabat sur le .xinitrc le cas échéant.

Personnellement, j'ai fini par opté pour la startégie du lien symbolique .xsession -> .xinitrc pour être sûr de ne pas avoir de surprises.