Forum

Reprise du message précédent

Yuusha, je vais te taquiner,
l'esthetique de l'écran est encore moins vrai si on allume le micro et que l'on fasse autre chose. Si on n'est pas devant l'écran, et d'ailleurs l’économiseur de jus rentre en service!!
En tout cas, depuis tous ces gestionnaires, on peut aller sur d'autres WM que celui pour lequel ils ont été créé!! et dans mon cas heureusement, car sans cela, j’étais un peu coincé, Vouf a eu le bon réflexe!!!

Édité par loul1933 Le 16/11/2020 à 14h17

Merci Aurelien, je vais tester celà.

re bonjour Auroud85
je viens de verifier ton fichier et le mien, voici le resultat, j'ai l'impression que il n'y a que l'autologin de different et le numlock?

En fait, SDDM permet une intégration avec Plasma et LXQt. Il permet la mise en veille, l'extinction et le redémarrage dans l'interface de Plasma.
GDM permet la même chose pour GNOME.
LightDM permet cela pour Cinnamon, Mate et XFCE, bien que ces bureaux recourent à leur propre binaire pour le verrouillage de l'écran et la sortie de veille.
Le libre permet de choisir ce qu'on veut, l'intégration que l'on souhaite.
La force de Mageia est de proposer l'immense majorité des Gestionnaires de connexion graphique.

Aurélien
Bugsquad et QA Team

Tu avais l'autologin de paramétré ?
Sinon, le numlock activé c'est utile pour les claviers étendus comme le mien (ceux avec un vrai pavé numérique et pas les claviers de portable).

S'il n'y pas de différences majeures, je ne vois pas pourquoi il plante.

Non non pas d'autologin
Pour le pavé numerique, je le parametre via "configuration du systeme>peripherique d'entrée> verouillage"


et il fonctionne aussi avec Plasma (je viens de tester la mise en veille)

Et aussi LXDE.

Numlock peut également être activé dans les services systemd.
Mais il est important que les paramètres ne soient pas en conflit. Par exemple, si vous activez Numlock dans XFCE et systemd, cela ne fonctionnera pas.

Après analyse des logs dans les 2 cas (sddm fonctionnel / sddm non fonctionnel)

Tout ce que je vois est que sddm 0.18-3 démarre en écrivant un cookie de session 1 seconde que soit logguée la commande :
"Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{9a7c4fcb-174e-4aed-aeda-4b8daf77c78f} -background none -noreset -displayfd 17 -seat seat0 vt1"

Analysant /var/run/sddm/{WHAT EVER NUMBER} : C'est un Magic MIT-X-COOKIE avec le nom de la machine en FQDN !
Regarde les journaux :
La machine est renommée de "localhost" à "localhost.localdomain" pendant que sddm démarre ce qui n'est pas supporté.

C'est pourquoi le MIT-X-COOKIE est mal écrit sous sddm 0.18-3 car il écrit "localhost" au lieu de "localhost.localdomain".
C'est pourquoi sddm-greeter ne peut pas accéder au serveur X sur display :0 : il n'en a pas le droit.

Donc je recommande fortement de renommer la machine définitivement en tant que root :

Vérifie:

La seconde commande permet de vérifier que le nom nouveau est bien écrit.
xyz peut être : mageia.local ou m7.local ...

Je suis particulièrement sûr que tu peux ensuite mettre à jour sddm à la dernière version supportée par Mageia.

Bonjour

auroud85, chapeau bas . On va tester ça cet après midi avec mon loul1933.. J'étais loin de penser à un problème de ce type...

Bravo Auroud85 !

Vérifiez quand même avant de me dire bravo. Je ne vois que ça.
Après, il existe bien un rapport de bug upstream https://github.com/sddm/sddm/issues/1316 mais il apparaît que la machine du rapporteur est "trop rapide..." Une "race condition"...

Bonjour

Nous avons appliqué tes recommandations, à savoir fixé le nom de la machine de loul1933. Après le reboot, tout a fonctionné.. On ne comprends pas forcément pourquoi le problème est apparu après la mise à jour du paquet sur cette machine... Mais, bon maintenant ça fonctionne. Merci pour l'aide..