problème clavier avec Asus X1704VA Le sujet est résolu

[tony]

salut,

en consultant le forum US j'ai trouvé un intervenant qui faisait état d'un problème clavier avec un Asus X1704VP: https://forums.debian.net/viewtopic.php?p=808370.

En comparant sa réponse à la commande dmesg | grep -C 2 serio à la mienne je me suis aperçu qu'elles sont très proches. Seulement lui a vu un problème, moi pas. Peut-être que mon problème aléatoire de l'ensemble { pavé tactile, souris, clavier } pourrait avoir un lien, surtout que la dernière option que je suis en train d'essayer i8042.dumbkbd=1 "semble" apporter un mieux. Or cet intervenant signale que cette option semblait avoir réglé son problème. Voici donc les réponses à la commande donnée plus haut avec en 1er la réponse de mon pc, puis la sienne:

Code : Tout sélectionner

# dmesg | grep -C 2 serio
[    1.634374] i8042: PNP: PS/2 Controller [PNP030b:PS2K] at 0x60,0x64 irq 1
[    1.634376] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[    1.635151] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.635394] mousedev: PS/2 mouse device common for all mice
[    1.635438] rtc_cmos rtc_cmos: RTC can wake from S4
--
[    1.636581] rtc_cmos rtc_cmos: alarms up to one month, y3k, 114 bytes nvram
[    1.637334] intel_pstate: Intel P-state driver initializing
[    1.637659] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
[    1.638400] intel_pstate: HWP enabled
[    1.638586] ledtrig-cpu: registered to indicate activity on CPUs

# dmesg |grep -C 2 serio
[    0.923993] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[    0.923997] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[    0.925117] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.925276] mousedev: PS/2 mouse device common for all mice
[    0.925293] rtc_cmos rtc_cmos: RTC can wake from S4
[    0.926107] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0

• 1ère remarque: je ne vois pas où se situe le problème et donc je suis passé à côté dès le début car:

  Code : Tout sélectionner

  # dmesg -l err
  [    6.574422] Bluetooth: hci0: Opcode 0x0c03 failed: -110

  ne signale rien.

• 2ème remarque: en suivant les liens donnés par l'intervenant j'ai abouti ici https://lore.kernel.org/linux-acpi/2024 ... edhat.com/ où il est dit que:

  Like other Asus Vivobook models the X1704VAP has its keybopard IRQ (1)
  described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh
  which breaks the keyboard.
  
  Add the X1704VAP to the irq1_level_low_skip_override[] quirk table to fix
  this.

Le problème est que je suis bien incapable de comprendre de quoi il s'agit et surtout d'en tirer, peut-être, une solution adaptable à mon cas.

[tony]

après consultation de Archwiki et si ça peut être utile:
ps1:

Code : Tout sélectionner

# dmesg | grep DSDT
[    0.010480] ACPI: DSDT 0x00000000715FA000 0978BB (v02 _ASUS_ Notebook 01072009 INTL 20200717)
[    0.010526] ACPI: Reserving DSDT table memory at [mem 0x715fa000-0x716918ba]

PS1: je pense avoir trouvé l'endroit où placer le fichier-solution-provisoire "resource.c": /usr/lib/modules/6.1.0-xx-amd64/kernel/drivers/acpi, xx étant le noyau en cours d'utilisation. Mais quelle peut-être la raison qui a poussé l'auteur de ce fichier à le préférer à l'option dumbkbd? Peut-être que l'option prive le clavier d'une fonctionnalité intéressante, le script non? Ça paraît plausible.

PS2: si j'ai bien compris ce patch devrait être inclus dans une version encore(?) à venir du noyau? Comment savoir lorsque ce sera le cas?

[piratebab]

Bonjour, pour faire simple, ton clavier à un comportement qui n'est pas le comportement attendu par le noyau un niveau d'un signal d'interruption.
Il n'est semble t il pas le seul, il a été ajouté à la liste des exceptions dans le code source du driver.
Pour savoir dans quelle version cela sera intégré, il faut éplucher les "change log" du driver à la recherche de cette modification.
En attendanr, tu dois pouvoir trouver une version de de driver "patchée" avec cette modification, ça t'évitera de passer par l'étape de compilation .

[tony]

........
En attendanr, tu dois pouvoir trouver une version de de driver "patchée" avec cette modification, ça t'évitera de passer par l'étape de compilation .

la prochaine version du pilote se trouvera dans le paquet xserver-xorg-input-libinput de bookworm-backports. J'ai inclus ce dépôt dans mes sources, donc apt peut me renseigner:

Code : Tout sélectionner

~$ apt changelog  xserver-xorg-input-libinput -t bookworm-backports
 xserver-xorg-input-libinput (1.2.1-1) unstable; urgency=medium
 

je vois qu'en fait il s'agit de la même version que dans stable, donc rien à en attendre je pense. C'est d'ailleurs corroboré, il me semble, par une autre commande:

Code : Tout sélectionner

~$ apt policy  xserver-xorg-input-libinput 
xserver-xorg-input-libinput:
  Installé : 1.2.1-1+b1
  Candidat : 1.2.1-1+b1
 Table de version :
 *** 1.2.1-1+b1 500
        500 http://ftp.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

pas de version bpo proposée..... sauf si un patch ne modifie pas le numéro d'une version.... mais ça m'étonnerait. Sinon il faut aller dans trixie pour trouver la future version 1.4.0-1.

Comme la commande apt changelog ne fonctionnera pas dans trixie, comment faire pour faire apparaître les changements apportés par cette version 1.4? Entrer trixie dans le fichier sources.list serait une solution, mais je préférerais l'éviter. En tout cas si je me réfère à cette page, trixie, il n'y en aurait pas, ce qui est bizarre, non?

ps1: j'ai téléchargé le .deb de trixie puis j'ai obtenu ceci avec uniquement les lignes qui concernent les logs:

Code : Tout sélectionner

$ dpkg -X xserver-xorg-input-libinput_1.4.0-1_amd64.deb mmas
..........
./usr/share/doc/xserver-xorg-input-libinput/
./usr/share/doc/xserver-xorg-input-libinput/changelog.Debian.gz
./usr/share/doc/xserver-xorg-input-libinput/changelog.gz
...........

j'ai bien récupéré les logs, reste à les décrypter.

ps2: changelog date de 2017 et changelog.Debian est le log de la version actuelle!!! ce qui tendrait à confirmer ce que la page "trixie" citée plus haut implique = pas de changement. J'ai dû faire une erreur qq part, mais comme l'option dumbkbd=1 a l'air de tenir la route je laisse l'affaire en l'état.

[piratebab]

Quand la modif est urgente, le numéro de version ne change pas, mais on rajoute un suffixe. Ici c'est db1
Tu peux utiliser le pining (épinglage) pour prendre une version plus récente uniquement de ce paquet

[tony]

.......
Tu peux utiliser le pining (épinglage) pour prendre une version plus récente uniquement de ce paquet

Si je veux donner la priorité à la version 1.4 de testing j'aurai au moins 2 1 dépendance non satisfaite: la version de libinput10 est trop ancienne. Quant à celle de xorg-input-abi-24 je ne sais pas car ce paquet n'est pas installé c'est OK, il est dans xserver-xorg-core avec la bonne version. Ça doit être un peu risqué, non?

Tant que l'option dumbkbd fonctionne je préfère ne pas prendre le risque de déstabiliser mon système. Maintenant que je sais ce qu'est un fichier "changelog" je regarderai les màj de ce paquet d'un peu plus près.

Quand la modif est urgente, le numéro de version ne change pas, mais on rajoute un suffixe. Ici c'est db1

je ne vois pas où se trouve ce suffixe, par contre il y a bien un +b1 dans la version. Même signification peut-être?

Code : Tout sélectionner

~$ apt policy xserver-xorg-input-libinput
xserver-xorg-input-libinput:
  Installé : 1.2.1-1+b1

ps1:

Sometimes the initial porter upload is problematic because the environment in which the package was built was not good enough (outdated or obsolete library, bad compiler, etc.). Then you may just need to recompile it in an updated environment. However, you have to bump the version number in this case
[...]
The magic for a recompilation-only NMU is triggered by using a suffix appended to the package version number, following the form bnumber. For instance, if the latest version you are recompiling against was version 2.9-3, your binary-only NMU should carry a version of 2.9-3+b1. If the latest version was 3.4+b1 (i.e, a native package with a previous recompilation NMU), your binary-only NMU should have a version number of 3.4+b2.
..........
This is a type of Non-maintainer uploads (NMU) called Binary-only non-maintainer upload.

ça n'a pas l'air d'être équivalent à db1, ce serait plutôt un truc genre "bumped version" si je comprends bien.

ps2: en poursuivant ma lecture de la source du commentaire ci dessus, toujours à propos de la version 1.4, et même si ça me dépasse:

Code : Tout sélectionner

$ zless changelog.Debian.amd64.gz
xserver-xorg-input-libinput (1.2.1-1+b1) sid; urgency=low, binary-only=yes
 
  * Binary-only non-maintainer upload for amd64; no source changes.
  * Rebuild against xorg-server ABI 25

ps3: je procède à une vérification à propose de la bonne utilisation de la commande dpkg -X <paquet> <répertoire cible>, il y a qq chose qui me chiffonne.

[piratebab]

L'ABI, c'est ce qui permet à 2 logiciels de s'échanger des infos.
J'ai l'impression qu'ils ne sont pas pressés d'intégrer cette modification. Je ne sais pas si c'est au niveau du dev des sources ou du mainteneur debian

[tony]

un grand mea culpa: je n'avais tout simplement pas compris le fonctionnement de dpkg -X, en particulier où les résultats étaient affichés, et en conséquence j'ai tout faux. Voilà ce que donne le changelog de la version 1.4:

$ zless changelog.Debian.gz
xserver-xorg-input-libinput (1.4.0-1) unstable; urgency=medium

* New upstream release.

-- Timo Aaltonen <tjaalton@debian.org> Tue, 12 Mar 2024 10:38:17 +0200

xserver-xorg-input-libinput (1.3.0-1) unstable; urgency=medium

[ Debian Janitor ]
* Remove constraints unnecessary since buster (oldstable):
+ Build-Depends: Drop versioned constraint on libinput-dev (>= 1.4.901).
+ Build-Depends: Drop versioned constraint on xserver-xorg-dev (>=
2:1.15.99).
[ Timo Aaltonen ]
* New upstream release.

-- Timo Aaltonen <tjaalton@debian.org> Tue, 01 Aug 2023 13:48:53 +0300

ps: l'info que j'avais loupée

Code : Tout sélectionner

$ man dpkg
dpkg peut également être utilisé comme interface pour dpkg-deb(1)
-x, --extract archive répertoire
               Extraire les fichiers contenus dans un paquet.  --> sans préciser où et comme je ne sais pas remplir les vides....

$ man dpkg-deb
-x, --extract archive répertoire
           Extrait l'arborescence des fichiers d'un paquet archive dans le répertoire spécifié.  --> pour les béotiens ça va mieux en le disant
           ....
          répertoire est créé si nécessaire (mais pas ses répertoires parents) et ses permissions sont modifiées pour correspondre au contenu du paquet. 

et donc cette commande n'extrait pas des fichiers ( man dpkg) mais affiche une arborescence (man dpkg-deb)..... sauf à considérer que les répertoires sont aussi des fichiers puisque j'ai lu que pour Linux tout est fichier. Ouf! ...ce fut laborieux.

ps: conséquences fâcheuses de l'utilisation de /tmp/ comme répertoire cible = problème lors d'une mise à jour du système = les permissions sont passées de 1777(?) à 755 ( cf ci-dessus ) pour /tmp/ et ça m'a permis d'apprendre que ce répertoire est utilisé lors d'une màj. La prochaine fois j'utiliserai /tmp/dir/ pour éviter ça.Que d'inconnues, que d'inconnu.

Code : Tout sélectionner

W: Impossible de récupérer http://security.debian.org/dists/bookworm-security/InRelease  Couldn't create temporary file /tmp/apt.conf.OEs2uD for passing config to apt-key

[piratebab]

Code : Tout sélectionner

* New upstream release

, c'est positif. Reste à trouver le changelog du code source. Un vrai jeu de pistes :)

[tony]

je viens de vérifier le changelog du dernier noyau et on peut lire ceci:

Code : Tout sélectionner

~$ apt changelog linux-image-6.1.0-27-amd64 | grep -i asus | less
ACPI: resource: Add Asus Vivobook X1704VAP to ---> cf PS

peut-on le rapprocher de ceci, vu plus haut:

Like other Asus Vivobook models the X1704VAP has its keybopard IRQ (1)
described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh
which breaks the keyboard.

Add the X1704VAP to the irq1_level_low_skip_override[] quirk table to fix
this.

peut-être que le problème est réglé par le dernier noyau, non?

PS1: la phrase paraît tronquée mais avec 44.000 lignes comment faire apparaître la phrase en entier sans tout lire?

PS2: moyennant l'utilisation d'une astuce probablement non homologuée voici la phrase en entier:

Code : Tout sélectionner

636     - ACPI: resource: Add Asus Vivobook X1704VAP to
 637       irq1_level_low_skip_override[] (Closes: #1078696)

et donc le bogue est bien corrigé pour X1704VAP mais qu'en-est-il pour mon X1704VA? Réponse dans peu de temps car je viens d'enlever l'option dumbkbd=1.
PS3: ne sachant pas comment numéroter les lignes dans un terminal voici la méthode utilisée:

Code : Tout sélectionner

$ apt changelog linux-image-6.1.0-27-amd64 > f 
$ nl f | grep -i vivobook   ---> fournit le numéro 636
$ less -N f  avec :636g

comment faire en plus concis?

PS4: en plus concis:

Code : Tout sélectionner

$ apt changelog linux-image-6.1.0-27-amd64 | grep -i -A 1 'vivobook X1704'
     - ACPI: resource: Add Asus Vivobook X1704VAP to
      irq1_level_low_skip_override[] (Closes: #1078696)

conclusion: RTFM

[piratebab]

Dans le bug concerné, il me semble voir ton clavier
https://lists.debian.org/debian-kernel/ ... 00202.html

[tony]

Dans le bug concerné, il me semble voir ton clavier
https://lists.debian.org/debian-kernel/ ... 00202.html

mon clavier y figure bien mais d'après ce que j'ai lu il y a une liste d'exceptions dans laquelle on doit ajouter son modèle, or c'est le modèle X1704VAP qui a été ajouté comme indiqué dans le changelog. Je vois que , comme sur le forum Debian US, un intervenant a fait fonctionner mon modèle:

My keyboard don't work on my Asus Vivobook X1704VA. This is a common problem with Asus computer.
I avoid this error by adding my computer in kernel source: drivers/acpi/resources.c

mais malheureusement il ne fournit pas le mode d'emploi, tellement ça doit lui paraître évident... pff....

Ceci dit le mainteneur a écrit sur la même page que le bogue a été résolu. Je ne peux qu'attendre et voir. Jusqu'à présent, sans l'option dumkbd=1 j'ai eu jusqu'à 10 jours de répit Ajdh j'en suis à 3 jours. Si dans 3 semaines je n'ai toujours pas de problème alors je pourrais respirer.