Forum Linux.debian/ubuntu détecter le branchement ou l'allumage d'un périphérique USB (VPI Epson)

Posté par  . Licence CC By‑SA.
Étiquettes :
1
5
jan.
2026

Bonjour à tous et meilleurs vœux pour cette nouvelle année.

Encore une question pour simplifier l'utilisation des clients linux pour mon collège.

Les vidéoprojecteurs interactifs EPSON (en tout cas les EB-695-Wi) ont un mode "ubuntu" (qui marche aussi avec debian, et peut-être d'autres distributions) qui permet de les utiliser comme périphériques de pointage. Très utile avec un logiciel type OpenBoard…

Sauf que par défaut, la surface sensible de pointage correspond à l'entièreté du bureau. Cohérent en bureau cloné, pas du tout en bureau étendu. Pour corriger çà, un script m'avait été suggéré ici il y a quelques temps : 

xinput | grep EPSON | grep -oP '(?<=id=)[0-9]+' | xargs -I % xinput map-to-output % DP-2

Cela fonctionne très bien mais demande à être lancé à chaque fois que le VPI est (r)allumé ou (re)branché. Si le VPI est déjà branché et allumé au démarrage du poste il faut aussi le lancer. Si on bascule d'un mode d'affichage à un autre, idem.

Je peux mettre un lanceur sur le bureau mais cela ne me plaît que très moyennement.

Comment faire pour automatiser cela ?

Pour le lancement au démarrage du poste, un fichier.desktop dans les applications au démarrage, je sais faire.

Mais comment détecter le branchement ou l'allumage après le démarrage ? J'ai cru comprendre que cela se passait au niveau des évènements udev mais je ne sais pas faire :-(
Quelqu'un pourrait-il me conseiller une doc ou tuto clair et au moins les grandes lignes pour faire cela ?

Même chose pour le changement de mode de bureau.

Merci d'avance

  • # udev en effet

    Posté par  . Évalué à 5 (+2/-0).

    à une epoque un bete fichier de config à mettre dans /etc/udev.d/xx-ton-fichier

    il y a une syntaxe que tu retrouveras sur internet car j'ai plus en tete, où tu lui donnes les identifiants du peripheriques USB ou sont pilotes, et des paremetres pour lancer le script que tu souhaites

    si ta distrib est tres recentes, c'est peut-etre systemd-udev qui s'en occupe.

    • [^] # Re: udev en effet

      Posté par  . Évalué à 3 (+1/-0). Dernière modification le 05 janvier 2026 à 17:20.

      1/ Il faudra par contre peut-être faire attention à la gestion des erreurs dans le cas ou le periph est branché alors que l'environnnement graphique n'est pas (encore) démarré avec session utilisateur ouverte.

      2/ xinput, Ca marche avec Wayland ?

      • [^] # Re: udev en effet

        Posté par  . Évalué à 3 (+1/-0). Dernière modification le 05 janvier 2026 à 17:30.

        Hum … En y réfléchissant, pas sûr qu'udev seul puisse marcher : il tourne en root pour une session utilisateur graphique non root …. Bricoage en vue, même sans wayland.

      • [^] # Re: udev en effet

        Posté par  . Évalué à 2 (+0/-0).

        Merci pour ces premières pistes. Quelques réponses (à mon niveau de compétence, pas taper !)

        1/ : il semble que la commande ne pose pas de problème si elle est lancée (par l’utilisateur) quand le VPI n'est pas branché. Peut-être que c'est tout aussi indolore si le VPI est détecté « trop tôt ». L'expérience tranchera peut-être. Ensuite si je lance de toute façon la commande à l'ouverture de session, elle sera effective après le démarrage de l'environnement graphique.

        2/ : Xorg (pour le moment) sur ces postes (mint - XFCE) et la commande fonctionne bien quand elle est lancée par l'utilisateur

    • [^] # Re: udev en effet

      Posté par  . Évalué à 3 (+2/-0). Dernière modification le 05 janvier 2026 à 18:06.

      Le répertoire exact est /etc/udev/rules.d/.

      Voici le premier sujet que j'ai trouvé sur comment lancer un script dans ces circonstances.

      Après, comme mentionné dans d'autres commentaires, il faut voir si le fait que le script soit lancé en tant que root pose un problème.
      Et dans ce cas, peut-être que la solution tourne autour de :

      • setuid / chmod / etc : faire en sorte que le script appartienne à l'utilisateur "normal" et qu'à chaque lancement par root, une bascule s'opère vers cet utilisateur via le bon paramétrage des permissions
      • su et le paramètre -c pour lancer le script

      Il sera peut-être nécessaire d'ajouter export DISPLAY=:0 dans le script.

      Notez que je n'ai aucune expérience avec Wayland, je ne sais pas si cette solution peut fonctionner dans ce contexte.

      Pour la petite histoire, sur mon PC pas si vieux que ça (2021, Zyzen 5950X + 3090FE), avec une installation toute fraiche de Debian 12, ou plus tard, de Debian 13, le tout premier login KDE / Plasma + Wayland se termine toujours par 95 % d'utilisation CPU, que ce soit avec les drivers nouveau, propriétaire nVidia issus des repos Debian, ou propriétaire nVidia issus du site nVidia. À chaque fois, je dois basculer vers Xorg.

      • [^] # Re: udev en effet

        Posté par  . Évalué à 2 (+0/-0).

        Sur wayland ça ne marchera pas. J'ai cherché un peu hier, je n'ai pas tout compris ni eu l'occasion de tester mais il semble qu'avec wayland ça se fait au niveau du compositor (sway/wlroots) et ça ne se fait pas en script mais en paramétrage ( conf persistante de sway dans le homedir de l'utilisateur par exemple). Mais à confirmer, car je ne connais pas plus wayland que ça, et ça dépend aussi du compositor(pas comme X11 qui gérait tout de manière centralisée).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.