Journal Simuler un clic avec libevdev et uinput

Sommaire

• Préambule
• Problème et solution
• libevdev – récupérer les évènements des périphériques d’entrée
  • Ouverture du périphérique et réception des évènements tactiles
  • Gestion des évènements
• uinput – générer des évènements
• Compilation et installation
• Future work
• Conclusion

Préambule

Samedi 7 août, 14h UTC+2 : une pluie de tous les enfers se déchaîne. Il pleut tout l’après-midi, mais c’est la tempête surtout pendant une demi heure. Le sol est inondé. Les gens courent, l’imper sur lequel je comptais jette l’éponge, mon téléphone pas étanche dans la poche de l’imper pas étanche est mouillé et c’est le drame : il ne s’allume plus.

Dimanche 8 août. Le téléphone refonctionne (son module wifi et Bluetooth démarre bien quand bon lui semble, mais il finira par refonctionner normalement quelques jours plus tard. Ouf).

… mais une bande de l’écran ne répond plus au tactile. Cette bande correspond pile poil à la barre d’état de l’environnement graphique, Phosh. C’est la même qu’on trouve aussi sur iOS et Android, rien de remarquable : on en a besoin pour accéder aux différentes fonctionnalités activables et désactivables et il n’y a guère d’autres interactions possibles sur cette barre. Vous connaissez certainement.

Bon, c’est chiant, mais en même temps, je n’ai aucune envie de changer l’écran pour si peu. Alors, que faire ?

Problème et solution

Sur Phosh, la seule interaction possible sur cette barre est un clic, pour la dérouler. L’idée n’a pas tardé à arriver : on pourrait simuler un clic déclenché par une autre interaction, par exemple en posant trois doigts n’importe où sur l’écran. Il se trouve que le téléphone tourne sur une Debian, adaptée pour mobile (Mobian), tout ce qu’il y a de plus classique à part ça. On doit bien pouvoir faire quelque chose sur un tel système bidouillable sans devoir télécharger des centaines de mégas de SDK et accepter des licences pénibles, non ?

Bien sûr que oui, sinon ce journal n’existerait pas !! Phosh est basé sur Wayland, donc les solutions basées sur un serveur X11 comme xdotools sont très vite écartées. Il va falloir taper plus bas dans la pile logicielle. Il nous faudra également une manière de surveiller les tapes tactiles pour détecter quand trois doigts sont appuyés sur l’écran.

libevdev – récupérer les évènements des périphériques d’entrée

Une recherche « Komen kon fé pour détecté les tapes ? » me mène rapidement sur cet article du blog de Peter Hutterer, alias Who-T, de chez Red Hat. Peter, c’est le monsieur input de l’écosystème libre. La référence ultime. Quand tu tombes sur son blog, tu sais que tu ne vas pas lire de conneries. Il a donné une présentation super intéressante à la linux.conf.au 2020 "Write a single library to handle all input devices, it'll be easy" they said…, que je vous recommande vivement si vous comprenez l’anglais. C’est assez accessible et beaucoup plus intéressant que ça en a l’air. D’ailleurs, il y annonce qu’il cherche désespérément des gens pour travailler avec lui dans le domaine et que le bus factor est dangereusement proche de 1, mais que ce n’est pas très sexy comme domaine, parce qu’il faut péniblement prendre en charge et tester manuellement chaque matériel avec ses spécificités pour que le reste du monde n’ait pas besoin de s’emmerder avec ça et que tout fonctionne out of the box, et que les gens préfèrent généralement travailler sur d’autres trucs. Donc si ce journal suscite des vocations, ne vous censurez pas, contactez-le…

Bref, il nous raconte que :

libevdev is a wrapper library to access /dev/input/eventX devices and provide their events through a C API.

Traduction :

libevdev est une bibliothèque qui enrobe les périphériques /dev/input/eventX et fournit leurs évènements à travers une API C.

Parfait, ça ! Bon, c’était en 2013, mais tout fonctionne encore pareil. Ouf !

Why use a library though? The kernel interface is relatively simple, but it has a few pitfalls. For one, device data is accessed through ioctl(2) and can cause weird bugs [1]. Second, not all events work in the same way. e.g. EVIOCGABS doesn't work the same for multi-touch axes, simply because the slot protocol has different semantics than the normal EV_ABS protocol. EV_REP has different handling as EV_ABS, EV_SYN is a special case anyway, etc. libevdev tries to avoid having to think about the differences and does sanity checks for the various calls.

Traduction (romancée) :

Mais pourquoi utiliser une bibliothèque ? L’interface noyau est relativement simple, mais elle a quelques soucis. Ça va être chiant, franchement on s’est embêtés à faire une bibliothèque toute propre qui uniformise tous vos affreux périphériques tous les plus différents les uns que les autres, utilisez ça si vous ne voulez pas finir dans une pièce blanche avec une camisole. Pitié, on sait de quoi on parle, on s’est sacrifiés pour vous alors maintenant, faites-nous plaisir et utilisez libevdev.

Bon, ça a l’air bien libevdev, on va utiliser ça. Peter nous explique en détail comment faire dans son article en s’appuyant sur cet exemple simple. Pour votre plaisir je vais le faire de ma manière ici.

Ouverture du périphérique et réception des évènements tactiles

Commençons donc par inclure les bons entêtes, et on va ouvrir le périphérique qui correspond à la dalle tactile de mon téléphone et écouter les évènements qui arrivent :

// (Tout le code C dans ce journal est copyright 2013 Red Hat, Inc, copyright 2021 moi, licence MIT)
#include <stdbool.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

#include <libevdev/libevdev.h>

int main(int argc, char **argv)
{
    int rc = 1;

    struct libevdev *dev = NULL;

    int fd = open("/dev/input/by-path/platform-1c2ac00.i2c-event", O_RDONLY);

    if (fd < 0) {
        perror("Failed to open device");
        goto out;
    }

    rc = libevdev_new_from_fd(fd, &dev);

    do {
        struct input_event ev;
        rc = libevdev_next_event(dev, LIBEVDEV_READ_FLAG_NORMAL|LIBEVDEV_READ_FLAG_BLOCKING, &ev);
        if (rc == LIBEVDEV_READ_STATUS_SUCCESS) {
            handle_event(&ev);
        }
    } while (rc == LIBEVDEV_READ_STATUS_SYNC || rc == LIBEVDEV_READ_STATUS_SUCCESS || rc == -EAGAIN);

    if (rc != LIBEVDEV_READ_STATUS_SUCCESS && rc != -EAGAIN) {
        fprintf(stderr, "Failed to handle events: %s\n", strerror(-rc));
    } else {
        rc = 0;
    }

out:
    if (fd > 0) {
        close(fd);
    }

    if (dev != NULL) {
        libevdev_free(dev);
    }

    return rc;
}

Décortiquons tout ça :

1. on ouvre le périphérique qui correspond à la dalle tactile avec open
2. on passe le périphérique à libevdev pour pouvoir l’utiliser à travers la bibliothèque, avec libevdev_new_from_fd
3. on boucle sur les évènements qui arrivent, en récupérant le prochain évènement avec libevdev_next_event (appel bloquant)
4. on passe ces évènements à une fonction handle_event que nous nous apprêtons à construire

Il y a toute la gestion des erreurs, avec l’entier rc qui contient le code de retour, initialisé à 1 comme ça par défaut on retourne une erreur et on le passera à 0 quand tout se sera bien passé. On groupe le nettoyage à la fin de la fonction, accessible par des goto (en cas d’erreur) avec l’étiquette out qui va bien.

Le fonctionnement normal du programme est de ne jamais s’arrêter de lui-même. On ne compte pas débrancher l’écran tactile en cours d’utilisation. On attend continuellement des évènements à traiter.

Le programme peut être lancé en tant qu’utilisateur simple, puisqu’un utilisateur simple peut accéder en lecture aux périphériques d’entrée. D’ailleurs, si vous vous disiez que Wayland vous protégeait des keyloggers parce que ça isole correctement les applications entre elles, eh bien c’est raté, la couche d’en dessous se charge de donner les accès.

Bon, alors, on se la fait cette gestion des évènements ??

Eh ben oui, allons-y…

Gestion des évènements

Alors là, on implémente la fonction handle_event qui manque dans la section précédente. On cherche à repérer le moment où trois doigts sont posés sur l’écran, ni plus, ni moins.

static int handle_event(struct input_event *ev, struct libevdev_uinput* uidev)
{
    static int max_finger_id = 0;
    static bool pressed = false;
    static int must_click_on_btn_release = false;

    switch (ev->type) {
        case EV_ABS:
            if (ev->code == ABS_MT_SLOT) {
                max_finger_id = max(max_finger_id, ev->value);
            }
            break;

        case EV_KEY:
            if (ev->code == BTN_TOUCH) {
                pressed = ev->value;
            }
            break;

        case EV_SYN:
            if (max_finger_id == 2  && pressed) {
                must_click_on_btn_release = true;
            } else if (must_click_on_btn_release && !pressed) {
                simclick();
                must_click_on_btn_release = false;
            }

            max_finger_id = 0;
            break;
    }

    return 0;
}

La structure input_event qu’on reçoit a trois champs qui nous intéressent : type, code et value. Le premier donne le type général de l’évènement, le deuxième spécifie plus précisément et le troisième est une info qui dépend de l’évènement (par exemple, quelle touche de clavier a été enfoncée).

Trois évènements nous concernent :

• le type EV_ABS, avec le code MT_SLOT. ABS, c’est pour absolu. Ça concerne les évènements qui ont des coordonnées absolues comme les écrans tactiles, à l’opposé des évènements relatifs comme les déplacements de souris. MT_SLOT, pour mutltitouch slot, permet de pister un doigt sur un écran tactile. Chaque doigt a son numéro, par ordre d’arrivée sur l’écran, en commençant par 0, puis 1, puis… vous avez compris. Quand vous déplacez vos doigts sur l’écran, ça va générer plein d’évènements mais chaque doigt aura toujours le même numéro (slot). C’est bien pratique. Vous imaginez, s’il fallait re-déduire le numéro de chaque doigt, évènement par évènement ? Heureusement que c’est fait pour nous !!
• le type EV_KEY, avec le code BTN_TOUCH. BTN pour button. Quand vous enfoncez un ou des doigt(s), ça génère un évènement BTN_TOUCH avec une valeur true, et quand vous le(s) relâchez, ça génère un évènement avec une valeur false.
• le type EV_SYN. C’est un évènement particulier, de synchronisation. Quand vous faites quelque chose sur votre écran (ou tout autre périphérique d’entrée), ça peut générer plusieurs évènements, pour la même action. Par exemple : « il s’est passé quelque chose avec le doigt 1 (EV_ABS). Il a été retiré de l’écran (EV_KEY). Ces évènements seront alors regroupés entre deux évènements de synchronisation EV_SYN.

Vous vous dites peut-être alors qu’il va falloir stocker tout un état entre plusieurs évènements, au moins jusqu’au prochain « EV_SYN », voire plus, pour réagir quand on a assez d’info. J’ai pour cela choisi d’utiliser des variables statiques, qui persistent entre deux appels de la fonction handle_event. Ultra pratique. C’est comme des globales, mais pas accessibles depuis les autres fonctions. Ça rend la fonction totalement impure et il faut faire attention, ça rend potentiellement les tests unitaires pour cette fonction compliqués (je suis tombé sur cet échange « amusant » avec un gars qui doit tester un code d’avion qu’il ne peut pas vraiment modifier en rédigeant le journal, il y a des astuces intéressantes chez IBM), mais en même temps ça colle parfaitement avec ce que j’ai envie de faire et je n’ai pas prévu de faire de tests unitaires.

Bref, en gros, ça fonctionne comme ça :

• quand on reçoit un numéro de doigt on enregistre son numéro (slot), s’il est plus grand que le numéro qu’on connait déjà.
• quand un (des) doigt(s) est (sont) appuyé(s) ou relâché(s), on stocke ça dans pressed
• quand la fin d’un bloc d’évènements arrive :
  • si on réalise que exactement 3 doigts on été pressés (max_finger_id == 2 && pressed), on enregistre le souhait de générer un clic quand les doigts sont relâchés (must_click_on_btn_release);
  • si on réalise que tous les doigts ont été relâchés et qu’on souhaitait générer le clic, on le génère en appelant la fonction simclick et on oublie le souhait de générer un clic
  • on réinitialise le numéro de doigts max.

Notes :

• en jouant avec libevdev, on peut avoir l’impression qu’il manque des évènements. En fait, si on s’attendait à avoir un évènement mais que celui-ci aurait eu la même valeur que le dernier évènement reçu du même type et du même code, on ne le reçoit pas une nouvelle fois. Ainsi, si vous voulez écrire des interactions compliquées, il ne faudrait pas réinitialiser votre état après chaque évènement EV_SYN, ce serait une erreur. Il n’y a probablement qu’en pratiquant et en se payant le mur soi-même que ça devient clair.
• Pourquoi attendre que les doigts soient relâchés ? Pourquoi ne pas simplement générer un clic dès qu’on voit que tous les doigts ont été pressés ? Eh bien parce que c’est plus intuitif à l’utilisation. Si vous alliez poser un 4ᵉ doigt par exemple, trop tard, vous avez déjà généré le clic qui correspond à 3 doigts (or, je vous montre une version simplifiée de handle_event, et j’ai effectivement une gestion différente pour un 4ᵉ doigt). Et aussi, à cause d’un problème dont je parle dans la section suivante.

Notre détection des 3 doigts est maintenant complète. Youpeee ! C’est déjà ça ! Vous pourriez vous arrêter là. Si vous vouliez par exemple exécuter une commande quand trois doigts sont appuyés, vous avez gagné. Il suffit d’appeler system ou fork + une version de exec.

Mais nous, on veut simuler un clic, alors c’est parti.

uinput – générer des évènements

J’apprends rapidement que pour simuler des clics (donc produire des évènements d’entrée « fake »), on peut utiliser l’interface du noyau Linux uinput. Pour citer Who-T :

uinput is the kernel interface to create evdev devices that, for most purposes, look the same as real devices

Traduction :

uinput est l’interface noyau pour créer des périphériques evdev qui, pour la plupart des situations, ressemblent comme deux gouttes d’eau à des périphériques réels

Très bien !

On continue à lire :

As the evdev interface, the uinput interface requires you to handle a few structs and ioctls, not necessarily in an obvious way. libevdev wraps that for you.

Traduction :

Comme pour l’interface evdev, l’interface uinput vous demande de gérer quelques structures et ioctls, pas forcément de manière évidente. libevdev vous enrobe tout ça pour vous.

Traduction :

Rendez-vous service, utilisez libevdev-uinput. Sérieux.

Bon, très bien, nous allons utiliser libevdev-uinput pour simuler un clic.

Comme pour la section précédente, Peter fait une très bonne présentation sur son article, et je vais vous la faire à ma sauce. Les exemples d’utilisations de libevdev et libevdev-uinput ne courent pas spécialement les rues d’internet alors ça ne peut pas faire trop de mal.

On peut créer un périphérique d’entrée virtuel de zéro, en spécifiant toutes ses caractéristiques, et notamment les types d’évènement qu’il est capable de générer. Mais en fait, il y a une manière plus simple de faire : il est possible de copier un périphérique existant, tout simplement. Et ça tombe bien, parce qu’on en a déjà un sous la main qu’on utilise déjà : c’est l’écran tactile. En plus, ça permettra vraiment de simuler exactement ce qu’il se serait passé si on avait nous-même touché l’écran tactile au bon endroit (c’est-à-dire, là où il est mort, si vous suivez), et Phosh n’y verra que du feu.

On va reprendre la ligne qui charge notre dalle tactile :

    rc = libevdev_new_from_fd(fd, &dev);

Le périphérique est chargé dans la structure dev si l’opération a réussi.

On va lui donner un nom à l’aide de la fonction libevdev_set_name et le copier dans une nouvelle structure semblable, uidev, à l’aide de la fonction libevdev_uinput_create_from_device.

On déclare la structure au début de la fonction main avant toute utilisation de goto :

    struct libevdev_uinput* uidev = NULL;

    libevdev_set_name(dev, "Fake device clicking on the top of the screen");

    rc = libevdev_uinput_create_from_device(dev, LIBEVDEV_UINPUT_OPEN_MANAGED, &uidev);
    if (rc < 0) {
        fprintf(stderr, "Failed to create fake device (%s)\n", strerror(-rc));
        goto out;
    }

Faudra pas oublier de libérer le périphérique dans la section out de main:

    if (uidev != NULL) {
        libevdev_uinput_destroy(uidev);
    }

On va passer à uidev à handle_event pour qu’elle puisse la passer à simclick:

• handle_event(&ev); devient handle_event(&ev, uidev);
• static int handle_event(struct input_event *ev) devient static int handle_event(struct input_event *ev, struct libevdev_uinput* uidev)
• simclick(); devient simclick(uidev);

La fonction simclick est assez bête. J’ai pris le programme d’exemple de Peter, je l’ai compilé, je l’ai lancé et j’ai appuyé sur mon écran tactile. J’ai pu voir tous les évènements qui étaient générés et j’ai bêtement copié tout ça en adaptant les coordonnées de l’évènement pour que ça clique au bon endroit. Petite subtilité avec le tracking id pour discerner les évènements générés :

static void simclick(struct libevdev_uinput* uidev)
{
    static int tracking_id = 1;
    int x = 15;
    int y = 15;
    libevdev_uinput_write_event(uidev, EV_ABS, ABS_MT_SLOT, 0);
    libevdev_uinput_write_event(uidev, EV_ABS, ABS_MT_TRACKING_ID, tracking_id++);
    libevdev_uinput_write_event(uidev, EV_ABS, ABS_MT_POSITION_X, x);
    libevdev_uinput_write_event(uidev, EV_ABS, ABS_MT_POSITION_Y, y);
    libevdev_uinput_write_event(uidev, EV_ABS, ABS_MT_TOUCH_MAJOR, 22);
    libevdev_uinput_write_event(uidev, EV_ABS, ABS_MT_WIDTH_MAJOR, 22);
    libevdev_uinput_write_event(uidev, EV_KEY, BTN_TOUCH, 1);
    libevdev_uinput_write_event(uidev, EV_ABS, ABS_X, x);
    libevdev_uinput_write_event(uidev, EV_ABS, ABS_Y, y);
    libevdev_uinput_write_event(uidev, EV_SYN, SYN_REPORT, 0);
    libevdev_uinput_write_event(uidev, EV_ABS, ABS_MT_TRACKING_ID, -1);
    libevdev_uinput_write_event(uidev, EV_KEY, BTN_TOUCH, 0);
    libevdev_uinput_write_event(uidev, EV_SYN, SYN_REPORT, 0);
}

… C’est… laborieux, mais pas très compliqué.

Et voilà, on a fini !
Si vous lancez le programme, si tout va bien, vous pourrez voir votre périphérique virtuel apparaitre dans la liste produite par la commande libinput list-devices :

Device:           Goodix Capacitive TouchScreen
Kernel:           /dev/input/event2
Group:            3
Seat:             seat0, default
Capabilities:     keyboard touch 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      identity matrix
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   n/a
Rotation:         n/a

…

Device:           Fake device clicking on the top of the screen
Kernel:           /dev/input/event6
Group:            6
Seat:             seat0, default
Capabilities:     keyboard touch 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      identity matrix
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   n/a
Rotation:         n/a

Les plus attentifs et les plus attentives auront remarqué qu’on ne supprime jamais les évènements initiaux correspondant aux trois doigts appuyés sur l’écran tactile. Et, oui, il s’agit d’une limitation. Je ne sais pas (encore) faire. Il y a peut-être moyen d’enregistrer notre périphérique virtuel et de bloquer le vrai périphérique et de filtrer les bons évènements. Il ne faut probablement pas tous les filtrer, mais peut-être juste les évènements BTN_TOUCH par exemple si ça suffit (peut-être pas). Sinon, ça pourrait avoir des effets de bords indésirables. Donc oui, si je ne fais pas attention, je déclenche des clics dans les applications actuellement affichées sur l’écran.

Note : contrairement à juste capter des évènements, simuler un périphérique nécessite d’être root (ou peut-être d’appartenir au bon groupe, mais je n’ai pas trop creusé).

Compilation et installation

C’est pas le tout, mais maintenant, il faut que le programme tourne et se lance au démarrage. Déjà, il faut installer le paquet de développement de libevdev (libevdev-dev chez les debianeux, libevdev-devel chez les rpmistes).

Puis, on compile et on installe :

gcc simclick.c $(pkg-config --libs --cflags libevdev) -o simclick 
sudo cp simclick /usr/local/bin/simclick

On fait un service systemd :

cat > /etc/systemd/system/simclick.service <<EOF
[Unit]
Description=Simulate top click using three fingers
ConditionFileIsExecutable=/usr/local/bin/simclick
After=phosh.service
[Service]
Type=simple
ExecStart=/usr/local/bin/simclick
RemainAfterExit=no
[Install]
WantedBy=multi-user.target
EOF

(je réalise qu’il faudra adapter ce After=phosh.service, d’ailleurs, et peut-être trouver une autre cible pour le rendre plus générique, là ça le rend spécifique à Phosh)

Et au redémarrage, ça marche tout seul.

Future work

(J’aurais pu titrer « Pistes d’amélioration » mais allez, ça me fait plaisir de nommer cette section comme ça.)

Pour l’instant j’utilise Phosh, mais je compte à plus ou moins court terme passer à Plasma Mobile, qui est d’ailleurs maintenant l’environnement par défaut du PinePhone (quelques trucs bloquants mais de moins en moins, et tant mieux, parce ça me convient mieux. Mais du coup, l’interaction sur la barre d’état pour la dérouler est vraiment un glisser vers le bas comme sous Android, donc la fonction simclick sera autrement plus compliquée. Mais ça ne devrait pas être trop difficile à faire, surtout qu’on peut enregistrer les évènements et presque les copier bêtement dans le code.

On pourrait s’amuser à rendre l’interaction plus intuitive en permettant demandant à ce que l’utilisateur fasse un glissé, peut-être avec deux doigts seulement. On peut imaginer tout un tas d’interactions pratique qui ne sont pas fournies par l’environnement. Il faut cependant trouver le moyen de garder la fonction handle_event lisible et claire, parce que pour avoir un peu tester, ça devient vite le bronx. Ou organiser autrement : faire une fonction par interaction. Pas toujours simple parce que parfois il y a des conflits. Tout bêtement, après un glissé, vous ne voulez pas déclencher l’action déclenchée par un touché simple.

Bon, on ne va pas se mentir, tout ça, c’est pour susciter votre esprit bidouilleur, mais restons les pieds sur terre : m’amuser avec des interactions tactiles sur le téléphone passera certainement après un tas de trucs que j’ai envie de faire donc il est peu probable que j’y passe un temps fou. À la base, c’est juste pour contourner cette zone morte de mon écran :-)

Conclusion

J’espère que vous avez apprécié ce journal. Si vous avez des questions ou des remarques, n’hésitez pas. En tout cas, ça fait un mois que j’utilise ce petit programme, sans accros ! Ça tourne et ça ne plante pas (ou, en tout cas, moins fréquemment que le téléphone lui-même !), et je m’y suis fait, j’aime plutôt bien taper sur l’écran avec trois doigts pour dérouler ce menu !

Références :

• Le code complet décrit dans ce journal : https://paste.chapril.org/?37aacff5e147e0b5#FbqoSBgy89n12jEd3anFNx4CEca8FY5tZ5qfcdD4Bw2L
• libevdev – handling input events
• libevdev – creating uinput devices
• Le code d’exemple de départ : https://gitlab.freedesktop.org/libevdev/libevdev/blob/master/tools/libevdev-events.c