problème de clavier ou bien de lightdm?

[tony]

salut,

le problème que j'attribuais à mon clavier serait-il en fait dû au gestionnaire d'affichage?

je viens de nouveau d'avoir un clavier erratique, incontrôlable car imprévisible. J''ai pu ouvrir une console tty2 en tant que root, ça ne marche pas toujours, et j'ai essayé de redémarrer lightdm: succès. Une fois l'affichage redémarré le clavier répondait tout à fait normalement. Je l'utilise actuellement sans problème, au moins apparemment.

Question: Lightdm peut-il influer sur le comportement de mon clavier?

PS1: je vais regarder les log de lightdm si qq chose est indiqué.

PS2: pas facile de se repérer sans chrono. Donc essais:

Code : Tout sélectionner

[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.00s] DEBUG: Starting Light Display Manager 1.26.0, UID=0 PID=70559
............

identification du process 70559

Code : Tout sélectionner

~$ ps -p 70559
    PID TTY          TIME CMD
  70559 ?        00:00:00 lightdm

il s'agit donc de ma session actuelle. Le log à consulter est donc log.old .... je suppose. Donc:

Code : Tout sélectionner

# cat lightdm.log.old >f1 
root@asus:/var/log/lightdm# cat f1
[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.00s] DEBUG: Starting Light Display Manager 1.26.0, UID=0 PID=981
[+0.00s] DEBUG: Loading configuration dirs from /usr/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/01_debian.conf
[+0.00s] DEBUG: Loading configuration dirs from /usr/local/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.00s] DEBUG: Registered seat module local
[+0.00s] DEBUG: Registered seat module xremote
[+0.00s] DEBUG: Registered seat module unity
[+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[+0.00s] DEBUG: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)
[+0.00s] DEBUG: _g_io_module_get_default: Found default implementation local (GLocalVfs) for ‘gio-vfs’
[+0.00s] DEBUG: Monitoring logind for seats
[+0.00s] DEBUG: New seat added from logind: seat0
[+0.01s] DEBUG: Seat seat0: Loading properties from config section Seat:*
[+0.01s] DEBUG: Seat seat0 has property CanMultiSession=no
[+0.01s] DEBUG: Seat seat0: Starting
[+0.01s] DEBUG: Seat seat0: Creating user session
[+0.01s] WARNING: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
[+0.01s] DEBUG: Loading user config from /etc/lightdm/users.conf
[+0.01s] DEBUG: User mmas added
[+0.02s] DEBUG: Seat seat0: Creating display server of type x
[+0.04s] DEBUG: Seat seat0: Plymouth is running on VT 1, but this is less than the configured minimum of 7 so not replacing it
[+0.04s] DEBUG: Quitting Plymouth
[+0.07s] DEBUG: Using VT 7
[+0.07s] DEBUG: Seat seat0: Starting local X display on VT 7
[+0.07s] DEBUG: XServer 0: Logging to /var/log/lightdm/x-0.log
[+0.07s] DEBUG: XServer 0: Writing X server authority to /var/run/lightdm/root/:0
[+0.07s] DEBUG: XServer 0: Launching X Server
[+0.07s] DEBUG: Launching process 1022: /usr/bin/X :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
[+0.07s] DEBUG: XServer 0: Waiting for ready signal from X server :0
[+0.07s] DEBUG: Acquired bus name org.freedesktop.DisplayManager
[+0.07s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0
[+1.20s] DEBUG: Got signal 10 from process 1022
[+1.20s] DEBUG: XServer 0: Got signal from X server :0
[+1.20s] DEBUG: XServer 0: Connecting to XServer :0
[+1.28s] DEBUG: Seat seat0: Display server ready, starting session authentication
[+1.28s] DEBUG: Session pid=1174: Started with service 'lightdm-autologin', username 'mmas'
[+1.29s] DEBUG: Session pid=1174: Authentication complete with return value 0: Success
[+1.29s] DEBUG: Seat seat0: Session authenticated, running command
[+1.29s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0
[+1.29s] DEBUG: Session pid=1174: Running command /etc/X11/Xsession default
[+1.29s] DEBUG: Creating shared data directory /var/lib/lightdm/data/mmas
[+1.29s] DEBUG: Session pid=1174: Logging to .xsession-errors
[+1.45s] DEBUG: Activating VT 7
[+1.45s] DEBUG: Activating login1 session 1
[+1.45s] DEBUG: Seat seat0 changes active session to 1
[+1.45s] DEBUG: Session 1 is already active
[+116199.75s] DEBUG: Seat seat0 changes active session to 
[+116297.14s] DEBUG: Seat seat0 changes active session to 67
[+116315.83s] DEBUG: Seat seat0 changes active session to 1
[+116315.83s] DEBUG: Session 1 is already active
[+116459.16s] DEBUG: Seat seat0 changes active session to 
[+116481.30s] DEBUG: Seat seat0 changes active session to 68
[+116551.22s] DEBUG: Got signal 15 from process 1
[+116551.22s] DEBUG: Caught Terminated signal, shutting down
[+116551.22s] DEBUG: Stopping display manager
[+116551.22s] DEBUG: Seat seat0: Stopping
[+116551.22s] DEBUG: Seat seat0: Stopping display server
[+116551.22s] DEBUG: Sending signal 15 to process 1022
[+116551.22s] DEBUG: Seat seat0: Stopping session
[+116551.22s] DEBUG: Terminating login1 session 1
[+116551.22s] DEBUG: Session pid=1174: Sending SIGTERM
[+116551.26s] DEBUG: Session pid=1174: Exited with return value 1
[+116551.26s] DEBUG: Seat seat0: Session stopped
[+116551.28s] DEBUG: Process 1022 exited with return value 0
[+116551.28s] DEBUG: XServer 0: X server stopped
[+116551.28s] DEBUG: Releasing VT 7
[+116551.28s] DEBUG: XServer 0: Removing X server authority /var/run/lightdm/root/:0
[+116551.28s] DEBUG: Seat seat0: Display server stopped
[+116551.28s] DEBUG: Seat seat0: Stopped
[+116551.28s] DEBUG: Display manager stopped
[+116551.28s] DEBUG: Stopping daemon
[+116551.28s] DEBUG: Exiting with return value 0
root@asus:/var/log/lightdm# 

je ne vois rien d'anormal là-dedans, non?

[piratebab]

Je ne vois pas trop le lien entre lightdm et le clavier. Lightdm n'est qu'un lanceur de session graphique. c'est ensuite la session graphique qui gére le clavier (couche au dessus du noyau et des drivers).
Si c'est un clavier usb, essaie de le débrancher/rebrancher qui ça déconne, et regarde les ogs et dmesg.

[tony]

Je ne vois pas trop le lien entre lightdm et le clavier. Lightdm n'est qu'un lanceur de session graphique. c'est ensuite la session graphique qui gére le clavier (couche au dessus du noyau et des drivers).
Si c'est un clavier usb, essaie de le débrancher/rebrancher qui ça déconne, et regarde les ogs et dmesg.

je ne sais même pas pourquoi j'ai eu l'idée de redémarrer lightdm pour un problème de clavier. J'ai été le 1er surpris du résultat. Ceci dit j'ai déjà épluché les logs suivants:

• journalctl, très pratique avec son horodatage. Malheureusement rien d'anormal à mon sens: aucun "failed", aucun "error", aucun code de retour=1

• less Xorg.0.log.old | grep keyboard: .old car après redémarrage. Là non plus rien d'anormal.

• less Xorg.0.log | grep -i keyboard: rien d'anormal

Que consulter de plus? dmesg apporte-t-il un supplément par rapport à journalctl?

PS1: à moins que ceci, répété plusieurs fois, ne dénote un dysfonctionnement du clavier:

Code : Tout sélectionner

event0  - AT Translated Set 2 keyboard: is tagged by udev as: Keyboard
[116557.453] (II) event0  - AT Translated Set 2 keyboard: device is a keyboard
[116557.455] (II) event0  - AT Translated Set 2 keyboard: device removed
[116557.472] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD, id 14)

à propos de AT Translated...

Code : Tout sélectionner

~$ xinput list 11
AT Translated Set 2 keyboard            	id=11	[slave  keyboard (3)]
	Reporting 1 classes:
		Class originated from: 11. Type: XIKeyClass
		Keycodes supported: 248

[piratebab]

dmesg c'est pour les logs noyau.

[tony]

je crois que j'ai mal interprété l'extension .old de Xorg.0.log.old, car si elle est reliée à un automatisme de rotation et conservation des logs défini dans le fichier /etc/logrotate.conf alors la période est de 1 semaine et n'a rien à voir avec un redémarrage:

Code : Tout sélectionner

/etc$ cat logrotate.conf 
# see "man logrotate" for details

# global options do not affect preceding include directives

# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

et donc j'ai consulté le mauvais log. À refaire..... enfin si je comprends bien cette histoire de rotation des logs.

refait: pas de changement, rien de signalé pour conclure.

[tony]

lorsque je suis bloqué et à cours d'idées, j'utilise parfois le forum Super User. Comme je raconte pas mal de bêtises je me fais taper sur les doigts mais au moins j'apprends.

Donc voici la page en question: https://superuser.com/questions/1866254 ... 83#1866283

• Le 1er commentaire semble intéressant et je pense que je peux le tester . Commentaire:
  

  The keyboard has a builtin microprocessor, type depending on which choice the producer has made. Your restart of the display manager may well include a reset of the keyboard's builtin software, "a reboot" in effect. Try find a replacement keyboard to use, see if that eliminates the problem

  test proposé:

  I think I can test this hypothesis by running the chvt 7 command from tty2. I should return to my normal environment without restarting lightdm.

  si ça ne débloque pas le clavier le commentaire pourrait bien être correct et donner une piste pour la relation clavier/DM, dans le cas contraire l'hypothèse avancée ne tient pas. Ai-je bon?

• la solution proposée envisage une autre piste et d'ailleurs expliquerait que les 3 logs que j'ai mentionnés ne gardent aucune trace de l'événement. Enfin, il me semble. Je vais voir ce que je peux en tirer.

PS: Aïe! je viens de voir qu'elle a un score de -2!! pas bon du tout ça. Je garde quand même une copie car j'ai l'impression que ça n'est pas le contenu qui est évalué, mais c'est l'utilisation de l'IA qui est réprouvée.

[piratebab]

Je t'avais proposé de débrancher/rebrancher le clavier pour faire un reset à la fois du clavier et des drivers (kernel et serveur graphique). Ca permettra de peut étre réduire le domaine d'investigation.

[tony]

Je t'avais proposé de débrancher/rebrancher le clavier pour faire un reset à la fois du clavier et des drivers (kernel et serveur graphique). Ca permettra de peut étre réduire le domaine d'investigation.

j'ai un ordi portable, comment débrancher le clavier ? J'avoue que ça ne me tente pas beaucoup d'ouvrir la bête.

J'avance un peu après chaque panne: en particulier je me suis aperçu que la touche Ctrl (à gauche) se comporte comme si elle était enfoncée en permanence pour certaines touches, ce qui fait que , entre autre, je ne peux pas ouvrir le terminal ni par le raccourci habituel ni avec le menu "Applications" car le clic gauche se comporte comme l'ensemble "Ctrl + clic gauche", imitant alors un clic droit. Je peux facilement reproduire ce comportement. De même les minuscules deviennent des majuscules et inversement, sauf dans une console tty ou tout semble fonctionner normalement (au moins pour entrer une commande). Il faut que j'arrive à ouvrir un terminal [tty7], ce serait déjà pas mal.

À la prochaine panne j'ai d'autres idées à tester. Mon but, temporaire, étant de trouver un moyen de reprendre le contrôle du clavier d'une manière simple, à défaut de trouver le coupable lui-même. Réactiver le D.M, en constitue une étape, pas très satisfaisante quand même.

[zargos]

Bonjour,
Quel age a ton portable?
De quand date le dernier nettoyage en profondeur?
Quand a-t-il été ouvert pour la dernière fois?
De quel type est ton clavier (membrane, mecanique, semi-mecanique, etc...)

Un clavier erratique sur un portable implique souvent un mauvais remontage, ou un clavier usé en fin de vie qui est donc à changer.

[tony]

Bonjour,
Quel age a ton portable?
..............

portable d'environ 5 mois, donc neuf.

Le comportement de la touche Ctrl, lorsque je perds le contrôle du clavier, me fait penser à une touche rémanente . Je vais enlever cette fonction, elle est activée et verrouillée depuis le 1er jour, et voir ce que ça donne.

[piratebab]

Je n'avais pas compris que c'était un portable. Du coup, essaie un clavier externe en USB quand tu as la panne.

[tony]

Je n'avais pas compris que c'était un portable. Du coup, essaie un clavier externe en USB quand tu as la panne.

Il faut donc que je puisse le brancher à chaud, que Debian le reconnaisse et installe les pilotes automatiquement. Est-ce bien le cas avec Debian 12?

[piratebab]

oui, clavier et souris, c'est plug and play (sauf appareils gamers ..., )

[zargos]

oui, clavier et souris, c'est plug and play (sauf appareils gamers ..., )

Même appareils gamers si tu ne te préoccupe pas des LEDs et autres RGB

[piratebab]

Je sais que c'est la période de noel, et qui tout ce qui clignote est considéré comme beau, .......