[expliqué/résolu]Clavier KDE, phénomène bizarre

Je résume la situation:

Une machine woody avec quelques backports. Je met cette machine à jour sous sarge avec un bon vieux dist-upgrade. Cela se fait en deux temps:

  1. Mise à jour de xlibs et quelques paquets fondamentaux qui virent les backports.

  2. un apt-get dist-upgrade derrière.

Tout se passe très bien. Je réinstalla kde qui avait été supprimé derrière. Pas de souci mais une erreur de configuration due au fait que je ne connais pas (et n’aime pas) KDE: Ce crétin s’occupe du clavier et me signale une incohérence entre le réglage KDE et le réglage X11, que faut-il faire? Je joue au poulet et valide la réponse par défaut: prendre le réglage KDE (c’est ça l’erreur). Bon, effectivement je constate que les touches < et > entre autres n’agissent plus sous KDE [si quelqu’un sait comment revenir sur ce réglage?]. Entre temps je dois partir. Bon…

De chez moi, je me connecte à la machine et je lance en remote sous root sur la machine kcontrol, là je sélectionne le clavier pc104 type Français. On verra bien si ça marche. Je ferme le kcontrol en remote et là, je m’aperçois que sous WindowMaker, sur mon portable à moi avec sa configuration aux petits oignons, les touches < et > ne fonctionnent plus!!! Un redémarrage de X a réglé le problème mais diable, pour le coup je regarde KDE d’un oeil moins complaisant: comment cette cochonnerie sur une machine à 20km de là a-t-elle pu modifier mon réglage clavier??? Je me doute de la réponse mais je suis surpris que des réglages fondamentaux de X puissent être modifiés à distance par une simple application.

pour règler le pb de config clavier, tu n’as qu’à faire un dpkg-reconfigure (-plow ?)

Sinon, pour la manip à distance, kcontrole à lancé dcop, un bus d’interaction kde (si j’ai bien compris, un peu comme corba ou bonobo - presque comme ole et .net), qui permet aux applis de se lancer dans un environnement homogène que tu les lances sur une machine ou sur une autre. C’est ça qui a exporté un élément de config foireux de ton ex woody sur ton portable.
Mais je pense que si aprés avoir fermé tous les éléments kde, tu avais killé le serveur dcop, tu serais revenu en config normale. Ou en redémarrant le serveur X peut être ?
Enfin en tous cas, ne t’inquiète pas, je n’imagine pas que ça laisse la moindre trace en dur…

Euh moi j’ai pc105.
Tu les as les touches au moins ?
Ca a l’air pas tres au point windowmaker :wink:

Le même problème peut-être?:
linuxfr.org/forums/15/4223.html

Boris: Tu n’as pas compris, la machine locale ne posait pas et ne pose toujours pas de pbm et Windowmaker est parfait. Il y a eu deux choses:

  1. Le problème du clavier: Cela s’est bien réglé avec ma manoeuvre (kcontrol), donc la machine en Remote fonctionne correctement maintenant.

  2. Ce que je ne comrepnds pas, c’est que on me connectant à distance via ssh -X à une machine où le clavier sous KDE ne reconnait pas la touche </>, après avoir fini la session, ma machine en locale hérite de cette imperfection. Il m’a suffit de relancer la session X pour régler le problème (donc localement tout va bien) mais je suis surpris qu’une application en remote puisse transmettre un rtéglage clavier à un serveur X distant (WindowMaker n’y est pour rien là dedans). Par contre effectivement, je n’ai pas pensé à regarder si un process dcop était présent mais je pense Mat que tu as la bonne explication. Etonnant quand même et déconcertant…