Forum-Francophone-LinuxMint.fr

Dernier message de la page précédente :

Merci tioker.

Effectivement, cette manip que je ne connaissais pas (je n'ai jamais utilisé github jusqu'à ce jour) m'a permis de charger le source de libinput10.

Mais je n'arrive toujours pas à gérer les dépendances ni a effectuer le patch (étapes apt-get build-dep et patch de la procédure de Cordic77).
J'ai beau potasser les man, je suis dans le bleu.

Ce que je comprends confusément, c'est que :

• apt-get build-dep va chercher les dépendances dans les dépots officiels pour les "lier" au source de Cordic77

• patch va chercher le source officiel dans ces mêmes dépôts pour lui appliquer le patch de Cordic77, pour obtenir le source définitif qui sera compilé ensuite

Et tout ce monde-là s'y retrouve grâce au fichier /etc/apt/sources.list/official-package-repositories.list qui donne l'emplacement des dépôts et (en principe ?) du source de Cordic77.

J'ai donc modifié ce fichier de plusieurs manières, sans résultat.
Le dernier essai était celui-ci :
Et j'obtiens systématiquement un résultat de ce type : Est-ce que c'est juste un problème de syntaxe que je ne saisis pas, ou bien y a-t'il quelque chose de plus profond ?

Il y a aussi autre chose qui me chagrine, c'est qu'en poursuivant sur cette voie (charger le patch en local avant de l'appliquer) , on s'écarte de la procédure de Cordic77 qui me semble tout traiter à partir de son dépôt sur github. Mais alors, comment faire comprendre à mon Linux qu'il doit aller pêcher sur le dépôt Cordic77 ?

Kerver a écrit : mar. 6 sept. 2022 00:01 Merci tioker.

Là non seulement ma compétence approche de ses limites mais je n'ai pas de Linux sous la main avant le 15 septembre (les retraités c'est toujours en vacances ...).
Je regarderai à mon retour sur une machine virtuelle car moi je suis sous Ubuntu et Gnome, et surtout je ne veux rien casser (surtout pas des briques).
Mais y'aura peut-être une âme charitable qui va t'aider à relever ce défi d'ici là.
Ma mère (ancienne dactylo) aurait aussi aimer taper à l'ancienne sur un PC ... avec le bruit des leviers... https://youtu.be/CwSChUUjBhQ
Aller, je retourne à l'apéro.

Pareil pour moi, je repars demain pour une dizaine de jours sans Linux...
Enorme, la vidéo ! Y'a pas, faut rajouter ce bruitage dans xkbcomp !

Ceci dit, pour apprendre à dactylographier, rien ne remplace une machine mécanique pour muscler les ch'tis doigts 4 et 5.
A moins d'être pianiste, auquel cas c'est déjà fait.

Bonnes vacances.

J'avance, pas à pas, mais j'avance.

Je viens de découvrir un truc tout con : les dépôts des sources ne sont pas activés dans l'installation par défaut de Mint.
Pour compiler, c'est ballot...
Dans le Gestionnaire de programmes, cliquer sur Sources de logiciels, cocher Dépôts de code source, et voilà !

Du coup, je passe sans coup férir (enfin, semble-t'il...) les étapes i à vi de la procédure de Cordic77.

Là où ça coince, c'est l'étape vii. Probablement parce que libinput est maintenant à la version 1.15.5 ?
Et bien sûr, le fichier à modifier (evdev.c) a bougé entre les deux versions.
Quand je dis que les mises à jour sont la malédiction de notre époque...

Prochaines étapes :
- éplucher le fonctionnement de la commande patch
- plonger dans le code pour voir les évolutions de evdev.c, en espérant que ça porte sur des trucs sans intérêt (pour moi) genre touchpad, donc non impactés par le patch.

A suivre...

Ayé, ça marche !!!!
J'ai mis le temps, mais de gros problèmes personnels m'ont écarté du projet (la déclaration de revenus, mais pas que).

En résumé, le patch de Cordic77 fonctionne parfaitement. Il faut juste aller le chercher sur github, et comprendre un peu la logique de l'environnement de compilation de meson...

Dans la bibliothèque libinput10, seul le fichier evdev.c est à patcher. Ce fichier gère les différents évènements venant des périphériques d'entrée : appui/relâché des touches, touchpad, souris, etc. Coup de bol, ce fichier est stable, c'est-à-dire qu'il change peu, voire pas du tout, au fils des versions successives de Mint. Le dernier copyright est 2017. Et dans ce fichier, la partie réservée aux touches du clavier est certainement la plus stable dans le temps, pour des raisons bêtement historiques.

Ce qui veut dire qu'on peut y aller franco pour le patcher : la dernière version libinput-1.14.1.patch publiée par Cordic77 fonctionne non seulement avec libinput-1.14.1, mais aussi avec les versions suivantes, au moins jusqu'à libinput-1.20.0.

Une fois ces interrogations levées, et meson (un peu) maîtrisé, la manip s'est déroulée sans problème, et le fichier obtenu a été installé sans difficulté.
Mais la procédure de Cordic77 est quand même un peu synthétique, je me suis permis de l'étoffer et de la commenter à l'usage des nouveaux venus (et de moi-même si j'ai besoin d'y revenir un jour...). La voici :

*********************************************************************
sudo su root

# installation de l'environnement de compilation meson
sudo apt-get install -y meson cmake

# installe les dépendances de libinput10 pour la compilation
apt-get build-dep -y libinput10

apt-get install -y libgtk-3-dev libunwind-dev libsystemd-dev libudev-dev libmtdev-dev libevdev-dev libwacom-dev check doxygen
apt-get install -y python3-pydot python3-sphinx python3-recommonmark python3-sphinx-rtd-theme

# installation des sources libinput (le dernier, à ce jour libinput-1-20-1 ) dans le répertoire courant
apt-get source libinput10

# récupération du dépôt de Cordic77
git clone https://github.com/Cordic77/xkb-typewriter-caps.git

# et copie du patch libinput-1.14.1.patch de Cordic77 dans le répertoire des sources
cp xkb-typewriter-caps/libinput10/libinput-1.14.1.patch libinput-1.20.0/src

# on se place dans le répertoire des sources à patcher
cd libinput-1.20.0/src


# génération du fichier à compiler à partir du patch
patch -p0 < libinput-1.14.1.patch
# à la question "file to patch :" répondre : evdev.c

# On a récupéré dans le répertoire libinput-1.20.0/src un fichier evdev.c.orig original, et un fichier evdev.c patché, qui sera compilé.

# On revient dans le répertoire libinput-1.20.0 pour la compilation. Dans ce répertoire, il y a meson.build, description du projet de compilation
cd ..

# Création du répertoire builddir/ avec tous les fichiers à compiler, et indication que l'installation finale se fera dans /usr/bin
meson --prefix=/usr builddir/

# compile et édite les liens à partir du répertoire builddir/ (option -C : répertoire courant)
ninja -C builddir/

# installe le nouveau libinput dans /usr/bin
ninja -C builddir/ install

# Si nécessaire, ou pour les curieux, instructions pour vérifier la bonne installation (et procédure de reversion)
# https://wayland.freedesktop.org/libinpu ... lding.html

# préconisé par Cordic77 : mise à jour de la base de données de drivers hwdb
# udevadm hwdb --update
# n'est plus nécessaire sur les versions postérieures à libinput 1.11

# rebooter, et vérifier la bonne configuration de xkbmap dans l'écran préférences/clavier/agencements/options :
# - compatibility options : Maj. annule Verr. Maj.
# - comportement de la touche Verr. Maj. : par défaut

# Caps Lock se comporte maintenant comme elle aurait TOUJOURS dû se comporter !

*********************************************************************
Seule interrogation : est-ce que cette évolution va résister aux mises à jour de Mint, ou bien va-t'elle être écrasée, auquel cas il faudra refaire la manip ?
Pour l'instant, j'arrête là.

Prochain défi : convaincre l'équipe de développement de Linux que ce comportement de Caps Lock doit impérativement être intégré au système !!

Pour reprendre la formule de Chépuki, on constate une fois de plus que "Linux fournit tous les outils nécessaires à la résolution de problèmes qui ne se seraient jamais posés sous Windows."

Enjoy !

Kerver

Post sciptum

La manip que je viens de décrire ne change que le comportement de la touche Caps Lock.
Elle ne bascule pas la ligne supérieure vers les chiffres (comme sur Windows), mais on reste dans la logique Linux :

é <Caps lock> É

et non

é <Caps Lock> 2

Pour avoir ce dernier comportement, il faut modifier la configuration du clavier via xkb, c'est un autre sujet qui n'a rien à voir.

Est-ce intéressant pour un dactylographe, même habitué à cette bascule ?
Je n'en suis pas sûr, c'est quand même confortable d'avoir les majuscules accentuées et les parenthèses quand on est en mode majuscules.

Post post scriptum :

A l'utilisation, le comportement décrit dans mon message précédent, à savoir que Caps Lock ne bascule pas la ligne supérieure vers les chiffres est intolérable.
On aboutit à une dissociation de Caps Lock et de Shift en terme de caractère frappé, ce qui est un non sens : on est à l'opposé du but recherché, et ça pénalise la vitesse de frappe.

Je vais donc m'orienter vers un remapping du clavier (en plus de la modification de Caps Lock décrite plus haut, qui elle perdure) pour aboutir au minimum à un comportement type "Windows bien configuré".