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 :
2
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).

        • [^] # Re: udev en effet

          Posté par  (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 07 janvier 2026 à 11:36.

          Il y aurait moyen de faire un truc mais indirectement:

          À l'ouverture de la session wayland on démarre un petit daemon qui en premier fait un lsusb pour savoir si l'appareil est déjà branché. Le cas échéant il execute la commande. Ensuite quelque soit la situation il écoute sur un socket filesytem qui lance la commande si il reçoit quelque chose pour pouvoir gérer les rebranchements.

          Et la règle udev ne ferait que taper sur ce socket (un simple GET via curl suffirait) pour le cas où l'appareil est branché après l'ouverture de la session ou rebranché.

          • [^] # Re: udev en effet

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

            Merci je bookmarke ça dans ma petite tête pour le jour où on passera ça en wayland

          • [^] # Re: udev en effet

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

            D'apres ce que j'ai lu, pas besoin, il semble que le compositor soit capable de gérer le hotplug, mais j'ai jamais essayé ….

  • # Début de solution ?

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

    J'ai un peu avancé. J'ai écris une règle udev /etc/udev/rules.d/çç-epson.rules qui semble fonctionner : 

    ACTION=="add|remove", SUBSYSTEM=="usb", ENV{DEVTYPE}==""usb_device" ENV{ID_SERIAL}=="*EPSON*Wi*", RUN+="/usr/local/bin/map-epson.sh"

    et le script en question : 

    #!/bin/sh
xinput | grep EPSON | grep -oP '(?<=id=)[0-9]+' | xargs -I % xinput map-to-output % DP-2
logger -udev_epson 'epson...'

    La dernière ligne créé bien l'entrée dans le journal mais la ligne xinput... n'est pas prise en compte.

    Problème d'utilisateur ? Pourtant cette même commande est OK quand elle est lancée par root (sudo -i) dans un xterm

    • [^] # Re: Début de solution ?

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

      Autre souci : seul le branchement est détecté, pas le débranchement (malgré le remove)

    • [^] # Re: Début de solution ?

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

      Les différences de comportement peuvent provenir de l'environnement (cf commande set ou env).
      Quid de la commande su - <utilisateur final> pour lancer le script ?

      On est en Xorg ou Wayland ici ?

      Si c'est Xorg, il faut peut-être ajouter le export DISPLAY=:0 dont je parlais dans mon autre commentaire.
      Pour Wayland, aucune idée.

      • [^] # Re: Début de solution ?

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

        Merci, je testera ça demain au collège.

        c'est du Xorg à priori, puisque (si j'ai bien compris) la bidouille xinput etc. ne fonctionnerait pas en wayland. Or elle fonctionne… OK, la méthode de diagnostic est toute pourrie

        Une question quand-même : si ce script est exécuté avec les droits root, comment celui-ci peut-il connaitre <utilisateur final> ?

        C'est un ordinateur accessible à de nombreux utilisateurs (intégré à un domaine windows), dans la pratique, il sera utilisé par des profs dans une salle de classe. Il peut donc y avoir 7 ou 8 utilisateurs différents dans la même journée et tous ne se déconnecterons pas forcément proprement. Par contre ils allumeront ou éteindront peut-être le VPI plusieurs fois par heure.
        Il y a donc bien un utilisateur concerné à chaque fois mais potentiellement plusieurs utilisateurs connectés. Il s'agit donc (sauf si je me goure - c'est possible) d'identifier l'utilisateur qui a une session graphique ouverte.

        • [^] # Re: Début de solution ?

          Posté par  (site web personnel) . Évalué à 1 (+0/-0).

          Pour le moment, avec xfce ça ne peut être que xorg si je ne m'abuse.

        • [^] # Re: Début de solution ?

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

          RTFM, ou plus exactement, man su

          SU(1)                                                  User Commands                                                 SU(1)

NAME
       su - run a command with substitute user and group ID

SYNOPSIS
       su [options] [-] [user [argument...]]

DESCRIPTION
       su allows commands to be run with a substitute user and group ID.
...

          • [^] # Re: Début de solution ?

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

            J'ai essayé en mettant le nom de l'utilisateur (c'est prn) "en dur" dans le script (pour des premiers essais) : 

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

            ça ne passe pas : Unable to connect to X server

            Avec sudo à la place de su plus d'erreur mais ça ne fonctionne quand même pas. J'ai ajouté un export pour DISPLAY puis pour XAUTHORITY mais pas mieux : ça fonctionne quand je lance le script depuis terminal xfce-terminal mais pas depuis la règle udev

            • [^] # Re: Début de solution ?

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

              La session de l'utilisateur prn était-elle lancée ?

            • [^] # Re: Début de solution ?

              Posté par  . Évalué à 1 (+0/-0). Dernière modification le 08 janvier 2026 à 10:45.

              Au cas où, en remplaçant su par runuser :

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

              Ça donne quoi ?
              (en théorie ça ne devrait rien changer, mais au point où on en est)

              Les vrais naviguent en -42

            • [^] # Re: Début de solution ?

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

              L'idée de sudo est stupide : seul l'utilisateur prnest dans sudoers or il faudra à la fin qu'il soit utilisable par n'importe quel utilisateur.
              J'essaye après l'idée de Flavien (la salle est prise ;-) )

  • # essai par rapports aux variables d'environnement etc.

    Posté par  . Évalué à 2 (+0/-0). Dernière modification le 08 janvier 2026 à 13:01.

    Le script avec juste

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

    fonctionne quand il est lancé par l'utilisateur prn
    Il fonctionne aussi quand l'utilisateur prn le lance après un sudo -i ou après un sudo

    Il ne fonctionne pas quand il est lancé par la règle udev.

    J'ai essayé de voir ce qui change en le remplaçant par 

    #!/bin/sh

LOGFILE="/tmp/test.log"
echo "-------------------$(date)-----------------------------" >> "$LOGFILE" 2>&1
echo "whoami        : $(whoami)"        >> "$LOGFILE" 2>&1
echo "id            : $(id)"            >> "$LOGFILE" 2>&1
echo "pwd           : $(pwd)"           >> "$LOGFILE" 2>&1
echo "DISPLAY       : ${DISPLAY}"       >> "$LOGFILE" 2>&1
echo "XAUTHORITY    : ${XAUTHORITY}"    >> "$LOGFILE" 2>&1

    et selon les cas c'est assez différent :

    pour l'utilisateur prn : 

    whoami        : prn
id            : uid=1000(prn) gid=1000(prn) groupes=1000(prn),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),105(lpadmin),125(sambashare)
pwd           : /home/prn
DISPLAY       : :0.0
XAUTHORITY    : /home/prn/.Xauthority

    avec sudo -i :

    whoami        : root
id            : uid=0(root) gid=0(root) groupes=0(root)
pwd           : /root
DISPLAY       : :0.0
XAUTHORITY    : /home/prn/.Xauthority

    après la règle udev : 

    whoami        : root
id            : uid=0(root) gid=0(root) groupes=0(root)
pwd           : /
DISPLAY       : 
XAUTHORITY    :

    Pourtant quand j'essaye de "forcer" DISPLAY et XAUTHORITY ça ne marche pas ???

    • [^] # Re: essai par rapports aux variables d'environnement etc.

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

      Le export DISPLAY=:0 est-il inclus dans le script xinput | ... ?
      Idem pour export XAUTHORITY=/home/prn/.Xauthority si nécessaire.

      Au-delà de ça, via la règle udev, si whoami retourne root, c'est que le changement d'utilisateur n'est pas opéré correctement. Il faut peut-être tenter de décomposer en deux scripts :

      • le premier, lancé par udev de la façon la plus simple qui soit possible, lance le second script par l'une des méthodes de changement d'utilisateur (su ou autre)
      • le second script effectue les logs de vérification (whoami, etc), fait les export puis lance xinput | ...

      Si le second script n'est toujours pas lancé en tant que prn, il y a un problème qui m'échappe.

      En complément, il faudrait peut-être utiliser les commandes set et/ou env, redirigées dans des logs à comparer avec les mêmes commandes lancées à la main dans une session normale. Il y aura peut-être d'autres différences significatives, en plus de DISPLAY et XAUTHORITY.

      • [^] # Re: essai par rapports aux variables d'environnement etc.

        Posté par  . Évalué à 2 (+0/-0). Dernière modification le 08 janvier 2026 à 14:57.

        Le export DISPLAY=:0 est-il inclus dans le script xinput | … ?
        Idem pour export XAUTHORITY=/home/prn/.Xauthority si nécessaire.

        J'ai essayé, avec DISPLAY=:0 et DISPLAY=:0.0 et avec XAUTHORITY=/home/prn/.Xauthority

        Avec ou sans, c'est le même comportement : OK par l'utilisateur prn ou par sudo -i mais pas OK par la règle udev.

        Désolé de ne pas être forcément très réactif pour les tests, il faut que j'arrive à passer entre les cours dans la salle avec ce VPI et mes cours à moi :-/

        • [^] # Re: essai par rapports aux variables d'environnement etc.

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

          Bien compris, pas de soucis, à votre rythme.

          DISPLAY=:0 ou export DISPLAY=:0 ?
          Désolé d'insister, mais le export est capital. En son absence, toutes les commandes à droite du premier | n'en auront pas connaissance.

        • [^] # Re: essai par rapports aux variables d'environnement etc.

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

          Autre réponse à part pour insister aussi sur les su et autre moyen de changer l'utilisateur qui exécute le script.
          Si la règle udev lance des commandes ou un script qui persiste à s'exécuter en tant que root, c'est que su ou autre ne sont pas exploités correctement.

          Petit exemple écrit vite fait.

          Deux scripts appartenant à root, exécutable par tous :

          # l script*.sh
-rwxr-xr-x 1 root root 104 2026/01/09-14:38:23 script1.sh*
-rwxr-xr-x 1 root root  46 2026/01/09-14:38:27 script2.sh*

          Contenu du premier :

          # cat script1.sh
#!/bin/bash

echo "Script 1: I am $(whoami), about to launch script2.sh"
su - totof -c /tmp/script2.sh

          Et du second :

          # cat script2.sh
#!/bin/bash

echo "Script 2: I am $(whoami)"

          Exécution directe du second script par root :

          # ./script2.sh
Script 2: I am root

          Exécution indirecte du second en passant par le premier, toujours par root :

          # ./script1.sh
Script 1: I am root, about to launch script2.sh
Script 2: I am totof

          Ici, grace à su - totof ..., on "devient" totof avant l'exécution de script2.sh.

          • [^] # Re: essai par rapports aux variables d'environnement etc.

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

            Ça doit effectivement être un pb de su : dans le script lancé par la règle udev, j'ai mis :

            su - prn -c "whoami : $(whoami) >> /tmp/test.log"

            Le fichier test.log est bien créé mais il contient whoami : root !

            • [^] # Re: essai par rapports aux variables d'environnement etc.

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

              Il faut bien détacher / décomposer. Diviser pour mieux régner …
              En écrivant 

              su - prn -c "whoami : $(whoami) >> /tmp/test.log"

              le shell interprète immédiatement

              $(whoami)

              en tant que root, même si tout le reste se fait en tant que prn.
              Il faut écrire des scripts à part, et ne mettre que le lancement du premier script dans la commande lancée par udev.

              • [^] # Re: essai par rapports aux variables d'environnement etc.

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

                OK, donc si j'ai bien suivi : udev lance un script
                /usr/local/bin/script1.sh

                qui contient
                su - prn -c /usr/local/bin/script2.sh

                et c'est ce script2 qui contiendra la ligne
                xinput | grep EPSON | grep -oP '(?<=id=)[0-9]+' | xargs -I % xinput map-to-output % DP-2

                ?

                • [^] # Re: essai par rapports aux variables d'environnement etc.

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

                  Oui, c'est ça qu'il faut tenter.
                  Et encore une fois, en ajoutant les export si nécessaires.

                  Parce que ça commence à être noyé dans la masse de commentaires, je rappelle aussi qu'en dernier recours et pour éliminer tout doute, il faudrait lancer set > unFichierSet.txt et/ou env > unFichierEnv.txt, une fois à partir d'une ligne de commande normale, et une autre à partir du script lancé par su.
                  En changeant les noms de fichiers pour pouvoir les comparer bien sûr (ex: unFichierSetSession.txt et unFichierSetSu.txt).
                  Seule cette comparaison permettra de déterminer les variables d'environnement qui existent, ou pas, dans chacun des contextes.
                  Moi, j'ai l'habitude de faire ça avec diff, vimdiff ou gvimdiff, mais il existe à coup sûr des utilitaires plus "user friendly" (peut-être kdiff3 ou kdiff3-qt par exemple).

                  • [^] # Re: essai par rapports aux variables d'environnement etc.

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

                    J'ai fais quelques modifs dans les scripts pour logger les informations peut-être pertinentes :

                    udev lance script1.sh : 

                    #!/bin/sh

LOGFILE="/tmp/script1.log"
echo "-------------------$(date)-----------------------------" >> "$LOGFILE" 2>&1
echo "whoami        : $(whoami)"                >> "$LOGFILE" 2>&1
echo "id            : $(id)"                    >> "$LOGFILE" 2>&1
echo "pwd           : $(pwd)"                   >> "$LOGFILE" 2>&1
echo "DISPLAY       : ${DISPLAY}"               >> "$LOGFILE" 2>&1
echo "XAUTHORITY    : ${XAUTHORITY}"    >> "$LOGFILE" 2>&1
echo "set ------------------------" >> "$LOGFILE" 2>&1
set >> "$LOGFILE" 2>&1
echo "env ------------------------" >> "$LOGFILE" 2>&1
env >> "$LOGFILE" 2>&1

echo "su - prn -------------------" >> "$LOGFILE" 2>&1
su - prn -c /usr/local/bin/map-epson.sh

                    puis map-epson.sh exécute la commande kivabien (et logge les données au passage)

                    #!/bin/sh

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

LOGFILE2="/tmp/script2.log"
echo "-------------------$(date)-----------------------------" >> "$LOGFILE2" 2>&1
echo "whoami        : $(whoami)"                >> "$LOGFILE2" 2>&1
echo "id            : $(id)"                    >> "$LOGFILE2" 2>&1
echo "pwd           : $(pwd)"                   >> "$LOGFILE2" 2>&1
echo "DISPLAY       : ${DISPLAY}"               >> "$LOGFILE2" 2>&1
echo "XAUTHORITY    : ${XAUTHORITY}"    >> "$LOGFILE2" 2>&1
echo "set ------------------------" >> "$LOGFILE2" 2>&1
set >> "$LOGFILE2" 2>&1
echo "env ------------------------" >> "$LOGFILE2" 2>&1
env >> "$LOGFILE2" 2>&1

logger -t udevepson 'epson...'

                    Si l'user prn lance le script map-epson.sh directement, ça fonctionne bien et le script2.log contient : 

                    -------------------lun. 12 janv. 2026 09:59:32 CET-----------------------------
whoami        : prn
id            : uid=1000(prn) gid=1000(prn) groupes=1000(prn),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),105(lpadmin),125(sambashare)
pwd           : /home/prn
DISPLAY       : :0.0
XAUTHORITY    : /home/prn/.Xauthority
set ------------------------
CLUTTER_BACKEND='x11'
CLUTTER_IM_MODULE='ibus'
COLORTERM='truecolor'
COMPIZ_CONFIG_PROFILE='mint'
DBUS_SESSION_BUS_ADDRESS='unix:path=/run/user/1000/bus'
DESKTOP_SESSION='xfce'
DISPLAY=':0.0'
GDMSESSION='xfce'
GDM_LANG='fr_FR'
GTK3_MODULES='xapp-gtk3-module'
GTK_IM_MODULE='ibus'
GTK_MODULES='gail:atk-bridge'
HOME='/home/prn'
IFS='   
'
LANG='fr_FR.UTF-8'
LANGUAGE='fr_FR'
LESSCLOSE='/usr/bin/lesspipe %s %s'
LESSOPEN='| /usr/bin/lesspipe %s'
LOGFILE2='/tmp/script2.log'
LOGNAME='prn'
LS_COLORS='rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.crdownload=00;90:*.dpkg-dist=00;90:*.dpkg-new=00;90:*.dpkg-old=00;90:*.dpkg-tmp=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:*.swp=00;90:*.tmp=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:'
OPTIND='1'
PANEL_GDK_CORE_DEVICE_EVENTS='0'
PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin'
PPID='1894'
PS1='$ '
PS2='> '
PS4='+ '
PWD='/home/prn'
QT_ACCESSIBILITY='1'
QT_IM_MODULE='ibus'
SESSION_MANAGER='local/linux-n-08.0670107C.ac-strasbourg.fr:@/tmp/.ICE-unix/1259,unix/linux-n-08.0670107C.ac-strasbourg.fr:/tmp/.ICE-unix/1259'
SHELL='/bin/bash'
SHLVL='1'
SSH_AGENT_PID='1466'
SSH_AUTH_SOCK='/tmp/ssh-bbLIHggS9cUr/agent.1456'
TERM='xterm-256color'
USER='prn'
VTE_VERSION='7600'
WINDOWID='60817901'
XAUTHORITY='/home/prn/.Xauthority'
XDG_CONFIG_DIRS='/etc/xdg/xdg-xfce:/etc/xdg'
XDG_CURRENT_DESKTOP='XFCE'
XDG_DATA_DIRS='/usr/share/xfce4:/home/prn/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share'
XDG_GREETER_DATA_DIR='/var/lib/lightdm-data/prn'
XDG_MENU_PREFIX='xfce-'
XDG_RUNTIME_DIR='/run/user/1000'
XDG_SEAT='seat0'
XDG_SEAT_PATH='/org/freedesktop/DisplayManager/Seat0'
XDG_SESSION_CLASS='user'
XDG_SESSION_DESKTOP='xfce'
XDG_SESSION_ID='c2'
XDG_SESSION_PATH='/org/freedesktop/DisplayManager/Session0'
XDG_SESSION_TYPE='x11'
XDG_VTNR='7'
XMODIFIERS='@im=ibus'
_='/usr/local/bin/map-epson.sh'
ftp_proxy='http://10.131.254.254:3128/'
http_proxy='http://10.131.254.254:3128/'
https_proxy='http://10.131.254.254:3128/'
no_proxy='localhost,127.0.0.1,::1'
env ------------------------
LESSOPEN=| /usr/bin/lesspipe %s
no_proxy=localhost,127.0.0.1,::1
LANGUAGE=fr_FR
USER=prn
XDG_SEAT=seat0
SSH_AGENT_PID=1466
XDG_SESSION_TYPE=x11
COMPIZ_CONFIG_PROFILE=mint
SHLVL=1
HOME=/home/prn
DESKTOP_SESSION=xfce
PANEL_GDK_CORE_DEVICE_EVENTS=0
GTK_MODULES=gail:atk-bridge
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
COLORTERM=truecolor
https_proxy=http://10.131.254.254:3128/
GTK_IM_MODULE=ibus
LOGNAME=prn
WINDOWID=60817901
http_proxy=http://10.131.254.254:3128/
_=/usr/local/bin/map-epson.sh
XDG_SESSION_CLASS=user
CLUTTER_BACKEND=x11
TERM=xterm-256color
XDG_SESSION_ID=c2
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
SESSION_MANAGER=local/linux-n-08.0670107C.ac-strasbourg.fr:@/tmp/.ICE-unix/1259,unix/linux-n-08.0670107C.ac-strasbourg.fr:/tmp/.ICE-unix/1259
GDM_LANG=fr_FR
GTK3_MODULES=xapp-gtk3-module
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_MENU_PREFIX=xfce-
ftp_proxy=http://10.131.254.254:3128/
XDG_RUNTIME_DIR=/run/user/1000
DISPLAY=:0.0
LANG=fr_FR.UTF-8
XDG_CURRENT_DESKTOP=XFCE
XMODIFIERS=@im=ibus
XDG_SESSION_DESKTOP=xfce
XAUTHORITY=/home/prn/.Xauthority
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.crdownload=00;90:*.dpkg-dist=00;90:*.dpkg-new=00;90:*.dpkg-old=00;90:*.dpkg-tmp=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:*.swp=00;90:*.tmp=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:
SSH_AUTH_SOCK=/tmp/ssh-bbLIHggS9cUr/agent.1456
XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/prn
SHELL=/bin/bash
QT_ACCESSIBILITY=1
GDMSESSION=xfce
LESSCLOSE=/usr/bin/lesspipe %s %s
QT_IM_MODULE=ibus
XDG_VTNR=7
PWD=/home/prn
XDG_CONFIG_DIRS=/etc/xdg/xdg-xfce:/etc/xdg
CLUTTER_IM_MODULE=ibus
XDG_DATA_DIRS=/usr/share/xfce4:/home/prn/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
VTE_VERSION=7600

                    Le branchement du VPI et donc le déclenchement par udev ne donne pas le résultat escompté pour le fonctionnement du VPI et les logs sont :

                    script1.log

                    -------------------Mon Jan 12 10:01:20 CET 2026-----------------------------
whoami        : root
id            : uid=0(root) gid=0(root) groups=0(root)
pwd           : /
DISPLAY       : 
XAUTHORITY    : 
set ------------------------
ACTION='add'
BUSNUM='001'
CURRENT_TAGS=':seat:'
DEVNAME='/dev/bus/usb/001/020'
DEVNUM='020'
DEVPATH='/devices/pci0000:00/0000:00:14.0/usb1/1-1'
DEVTYPE='usb_device'
DRIVER='usb'
ID_BUS='usb'
ID_FOR_SEAT='usb-pci-0000_00_14_0-usb-0_1'
ID_MODEL='0907'
ID_MODEL_ENC='0907'
ID_MODEL_ID='0907'
ID_PATH='pci-0000:00:14.0-usb-0:1'
ID_PATH_TAG='pci-0000_00_14_0-usb-0_1'
ID_PATH_WITH_USB_REVISION='pci-0000:00:14.0-usbv2-0:1'
ID_REVISION='0000'
ID_SERIAL='04b8_0907'
ID_USB_INTERFACES=':090001:090002:'
ID_USB_MODEL='0907'
ID_USB_MODEL_ENC='0907'
ID_USB_MODEL_ID='0907'
ID_USB_REVISION='0000'
ID_USB_SERIAL='04b8_0907'
ID_USB_VENDOR='04b8'
ID_USB_VENDOR_ENC='04b8'
ID_USB_VENDOR_ID='04b8'
ID_VENDOR='04b8'
ID_VENDOR_ENC='04b8'
ID_VENDOR_FROM_DATABASE='Seiko Epson Corp.'
ID_VENDOR_ID='04b8'
IFS='   
'
LOGFILE='/tmp/script1.log'
MAJOR='189'
MINOR='19'
OPTIND='1'
PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
PPID='4169'
PRODUCT='4b8/907/0'
PS1='# '
PS2='> '
PS4='+ '
PWD='/'
SEQNUM='4736'
SUBSYSTEM='usb'
TAGS=':seat:'
TYPE='9/0/2'
UDEV_DATABASE_VERSION='1'
USEC_INITIALIZED='1765002875'
env ------------------------
ID_BUS=usb
DEVNAME=/dev/bus/usb/001/020
ID_FOR_SEAT=usb-pci-0000_00_14_0-usb-0_1
ACTION=add
ID_VENDOR_FROM_DATABASE=Seiko Epson Corp.
ID_PATH_WITH_USB_REVISION=pci-0000:00:14.0-usbv2-0:1
SEQNUM=4736
USEC_INITIALIZED=1765002875
ID_USB_VENDOR_ENC=04b8
UDEV_DATABASE_VERSION=1
BUSNUM=001
TAGS=:seat:
MAJOR=189
ID_USB_VENDOR=04b8
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-1
ID_USB_VENDOR_ID=04b8
ID_MODEL_ENC=0907
ID_USB_REVISION=0000
ID_USB_INTERFACES=:090001:090002:
ID_MODEL=0907
SUBSYSTEM=usb
ID_SERIAL=04b8_0907
ID_MODEL_ID=0907
MINOR=19
DRIVER=usb
TYPE=9/0/2
ID_PATH=pci-0000:00:14.0-usb-0:1
CURRENT_TAGS=:seat:
DEVNUM=020
ID_VENDOR_ENC=04b8
PRODUCT=4b8/907/0
ID_PATH_TAG=pci-0000_00_14_0-usb-0_1
ID_USB_MODEL_ENC=0907
ID_VENDOR=04b8
PWD=/
DEVTYPE=usb_device
ID_VENDOR_ID=04b8
ID_USB_MODEL=0907
ID_USB_SERIAL=04b8_0907
ID_USB_MODEL_ID=0907
ID_REVISION=0000
su - prn -------------------

                    et pour script2.log

                    -------------------lun. 12 janv. 2026 10:01:20 CET-----------------------------
whoami        : prn
id            : uid=1000(prn) gid=1000(prn) groupes=1000(prn),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),105(lpadmin),125(sambashare)
pwd           : /home/prn
DISPLAY       : 
XAUTHORITY    : 
set ------------------------
DBUS_SESSION_BUS_ADDRESS='unix:path=/run/user/1000/bus'
HOME='/home/prn'
IFS='   
'
LANG='fr_FR.UTF-8'
LOGFILE2='/tmp/script2.log'
LOGNAME='prn'
MAIL='/var/mail/prn'
OPTIND='1'
PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin'
PPID='4176'
PS1='$ '
PS2='> '
PS4='+ '
PWD='/home/prn'
SHELL='/bin/bash'
SHLVL='0'
USER='prn'
XDG_DATA_DIRS='/home/prn/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share'
XDG_RUNTIME_DIR='/run/user/1000'
XDG_SESSION_CLASS='background'
XDG_SESSION_ID='c19'
XDG_SESSION_TYPE='unspecified'
_='/usr/local/bin/map-epson.sh'
ftp_proxy='http://10.131.254.254:3128/'
http_proxy='http://10.131.254.254:3128/'
https_proxy='http://10.131.254.254:3128/'
no_proxy='localhost,127.0.0.1,::1'
env ------------------------
MAIL=/var/mail/prn
no_proxy=localhost,127.0.0.1,::1
USER=prn
XDG_SESSION_TYPE=unspecified
SHLVL=0
HOME=/home/prn
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
https_proxy=http://10.131.254.254:3128/
LOGNAME=prn
http_proxy=http://10.131.254.254:3128/
_=/usr/local/bin/map-epson.sh
XDG_SESSION_CLASS=background
XDG_SESSION_ID=c19
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
ftp_proxy=http://10.131.254.254:3128/
XDG_RUNTIME_DIR=/run/user/1000
LANG=fr_FR.UTF-8
SHELL=/bin/bash
PWD=/home/prn
XDG_DATA_DIRS=/home/prn/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share0

                    (j'ai coupé les deux derniers logs : udev s'exécute deux fois et donc les logs bégayent mais je ne pense pas que ce soit ça le problème. Je n'ai mis qu'une seule des deux occurences)

                    • [^] # Re: essai par rapports aux variables d'environnement etc.

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

                      J'ai copié les sorties des deux cas de figure pour les comparer avec vimdiff.
                      Je ne sais pas comment faire apparaître ce que j'ai sous les yeux ici, pas sans que ça ne devienne très confus.
                      Je constate de nombreuses différences entre les environnements, certaines pouvant expliquer les différences de comportement. À commencer par les export de DISPLAY et XAUTHORITY déjà mentionnés plusieurs fois qui sont absents au tout début de map-epson.sh.
                      Mais il y a beaucoup d'autres variables qui manquent dans le contexte udev et qui pourraient expliquer la différence de comportement.
                      Je ne suis certain de rien, mais ça pourrait être aussi simple que quelques variables liées à la langue (exemple au hasard : LANGUAGE=fr_FR), de la même manière que ça pourrait être beaucoup plus subtil.

                      Question annexe au passage : existe-t-il une solution officielle pour linuxfr.org pour stocker et intégrer des images dans les posts ? Je n'ai pas trouvé la réponse sur le site (wiki inclus). J'ai moyennement envie de publier ça sur mon serveur auto-hébergé.

                      • [^] # Re: essai par rapports aux variables d'environnement etc.

                        Posté par  (site web personnel) . Évalué à 3 (+0/-0).

                        Question annexe au passage : existe-t-il une solution officielle pour linuxfr.org pour stocker et intégrer des images dans les posts ? Je n'ai pas trouvé la réponse sur le site (wiki inclus). J'ai moyennement envie de publier ça sur mon serveur auto-hébergé.

                        Affichage d'images externes https://linuxfr.org/aide#aide-imagesexternes
                        Si tu la mets sur ton auto-hébergé, seul le service img de LinuxFr org ira la chercher.
                        Et sinon les CHATONS fournissent divers endroits pour stocker temporairement des images.

                      • [^] # Re: essai par rapports aux variables d'environnement etc.

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

                        En espérant que ce soit utile, je tente la publication :

                        image de la comparaison entre les deux sorties

                        • [^] # Re: essai par rapports aux variables d'environnement etc.

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

                          Est-ce résolu ?

                          Dans le diff, on voit beaucoup de variables d'environnement qui différent et peuvent indiquer qu'on est pas une session graphique… DISPLAY, XAUTHORITY, XDG_SESSION_CLASS, XDG_SESSION_TYPE. D'autres sont manquantes

                          Pour se rapprocher au plus près de ce qui marche , tu pourrais lancer ton script dans un émulateur de terminal graphique.
                          Par exemple:
                          DISPLAY=:0.0 kgx -e

                          Remplace kgx par xterm, gnome-terminal, konsole si besoin

                          • [^] # Re: essai par rapports aux variables d'environnement etc.

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

                            Est-ce résolu ?

                            Pas tout à fait de cette manière et je pense que j'ai dans mes essais précédents accumulé les erreurs de syntaxe que j'ai eu du mal à débugger. J'ai posté plus bas une ébauche partiellement fonctionnelle, solution que je pensais avoir déjà explorée.

                            Mais merci à tous ceux qui se sont déjà penché sur le problème…

                      • [^] # Re: essai par rapports aux variables d'environnement etc.

                        Posté par  . Évalué à 3 (+1/-0). Dernière modification le 13 janvier 2026 à 09:35.

                        sans que ça ne devienne très confus

                        « confus » c'est effectivement le mot qui m'est venu à l'esprit quand j'ai vu la sortie du truc ;-)

                        • [^] # Re: essai par rapports aux variables d'environnement etc.

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

                          Meuhnan ! Faut pas se laisser impressionner.
                          Il faut déjà écarter les lignes identiques à droite et à gauche, normale en blanc sur noir, signifiant qu'il n'y a pas de différence.
                          Et puis, petit à petit, se focaliser sur les autres lignes, et tenter de deviner si ce qui change peut avoir un impact sur le comportement quand le script est lancé par udev.
                          Le mot qui s'applique ici serait plutôt "fastidieux" non ?…

  • # utilisation VPI ou TBI ?

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

    bon, utilises-tu ton VPI en tant que TBI ?

    bien sûr cela correspond à Tableau blanc interactif — j'adore les sigles et acronymes lorsqu'expliqués — et non Traumatic brain injury quoique…

    quels sont vos cas d'utilisation ?

    • programmer à plusieurs en scratch ? (comme c'est avec l'utilisation de blocs ça peut être pratique)

    • dessiner avec inkscape ou autre logiciel ?

    • refaire un épisode des Experts ou de NCIS Los Angeles pour faire apparaître des infos sur un suspect ?

    Aurais-tu de la doc' de ton EPSON EB-695 ? (URL avec des ressources utiles)

    Dans notre fablab, avons récupéré des modèles plus anciens EB-470 et EB-570 et les spécifications constructeur EB-470 sont de peu d'aide pour des cas d'utilisation concrets…
    Peut-être y-a-t'il des sites spécifiques ?

    • [^] # Re: utilisation VPI ou TBI ?

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

      Pour les précisions technopédagogiques, un VPI (vidéoprojecteur interactif) ou TBI (tableau blanc interactif) sont deux dispositifs fonctionnellement identiques : des périphériques de pointage couvrant une grande surface d'affichage. La différence est que la partie sensible d'un VPI est dans le vidéoprojecteur courte focale alors que dans le TBI elle est dans la surface de projection. Le vidéoprojecteur est alors des plus classiques (courte ou longue focale). Le confort d'utilisation du VPI, du moins pour les EPSON, est incomparable (calibrage super stable, pas d'éblouissement)
      Il existe aussi des écrans interactifs (de très grands écrans tactiles, type LCD, oLED ou je ne sais quoi) mais je n'en ai jamais utilisé, juste vu un en démo il y a qq années. De ce que j'ai compris, c'est plus qu'un écran puisque ça embarque un système android complet mais c'est interfaçable avec un ordi plus conventionnel.

      J'ai une grosse doc papier au collège et un CD… quelque part mais sinon en ligne c'est ici : https://www.epson.fr/fr_FR/support/sc/epson-eb-695wi/s/s1534#manuals mais c'est juste la doc d'installation pas de la documentation d'usage. Pour les utilisations péda, il y a pas mal de contenus sur les sites académiques, mais pas sûr que cela puisse correspondre aux usages d'un fablab.

      Mais comme il s'agit d'affichage en grand et de pointage, tu peux l'utiliser pour tout ce que tu veux montrer et manipuler en même temps.
      Ta démo scratch sera plus pertinente qu'un tuto avec des captures d'écran, plus pratique qu'une manip à la souris avec un VP classique. Démo de logiciels idem.

      Le reste c'est du logiciel : des logiciels de constructeurs plus ou moins complets, propriétaires pour ce qui est des constructeurs, et plus ou moins complets. Sur ce dernier point, en tout cas pour ceux que j'ai vraiment utilisé, EPSON fait du très basique (gribouillage sur l'image de projection pas beaucoup plus), promethean est très riche (mais complètement fermé) avec beaucoup de fonctionnalités scolaire (et un OCR manuscrit qui marche !)

      Pour ma part j'utilise principalement OpenBoard malgré une orientation fonctionnelle très école primaire. J'ai aussi utilisé xournal++ quand les fonctionnalités multi-écran (j'y tiens) d'OpenBoard n'étaient pas au top. En physique-chimie c'est surtout en association avec la caméra qui me permet de montrer une manip puis d'en faire une photo et la gribouiller, l'annoter etc. L'intérêt de l'interactivité est de pouvoir faire évoluer les gribouillages, schémas, graphiques etc.
      Évidemment sauvegarde en pdf, mise à disposition des élèves, retour en arrière sur les séances précédentes…
      Les prof des écoles aiment bien les manipulations de morceaux de phrases à reconstituer, les applis de calculs, etc. Toujours dans la même idée : manipuler et visualiser en même temps.

      On s'éloigne du sujet mais ça mériterai un nourjal ça, si j'arrive à y consacrer un peu de temps.

      • [^] # Re: utilisation VPI ou TBI ?

        Posté par  (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 09 janvier 2026 à 19:58.

        On s'éloigne du sujet mais ça mériterai un nourjal ça, si j'arrive à y consacrer un peu de temps.

        ça vaudrait le coup, c'est toujours compliqué d'imaginer des usages utiles et qui ne soient pas gadget

        merci pour les docs, ça m'a permis d'en trouver d'autres pour nos vidéoprojecteurs :-)

  • # Une autre approche (réalisable ?)

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

    Est-ce qu'il ne serait pas possible d’utiliser une autre approche avec service systemd --user qui écoute udevadm monitor et lance le script quand il détecte le branchement ?

    • [^] # Re: Une autre approche (réalisable ?)

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

      Cela semble tout à fait approprié en effet.

      Un fichier de périphérique est-il créé au branchement ?
      udevadm wait pourrait faire l'affaire aussi.

      • [^] # Re: Une autre approche (réalisable ?)

        Posté par  . Évalué à 2 (+0/-0). Dernière modification le 12 janvier 2026 à 17:46.

        Un fichier de périphérique est-il créé au branchement ?

        il y a effectivement 7 (!) entrées qui sont crées dans /dev/input/by-id/ du type usb-EPSON_EPSON_EPSON_695Wi_695WT-event-mouse` et qui disparaissent à la déconnexion

        Il y a moyen d'en faire quelque-chose ?

    • [^] # Re: Une autre approche (réalisable ?)

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

      Il existe aussi un type de unit appelé device qui pourrait être pratique,
      mais il faut que udev marque le périphérique avec un tag "systemd" ("TAG+="systemd"" dans le fichier de règles udev)

    • [^] # Re: Une autre approche (réalisable ?)

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

      J'ai essayé ceci, suggéré par ailleurs (mais qui ne marche pas mieux :-( )

      /etc/udev/rules.d/91-vpi-epson.rules : 

      SUBSYSTEM=="usb", ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0907", OWNER="${USER}", GROUP="${USER}", MODE="0664"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0907", TAG+="systemd", ENV{SYSTEMD_ALIAS}="/dev/vpi"
ACTION=="remove", SUBSYSTEM=="usb", ENV{PRODUCT}=="04b8/0907/*", TAG+="systemd"

      /etc/systemd/user/epson-vpi.service : 

      [Unit]
Description=VPI Epson
Requisite=dev-vpi.device
After=dev-vpi.device
StartLimitIntervalSec=1m
StartLimitBurst=5

[Service]
Type=simple
ExecStart=/usr/local/bin/map-epson.sh
Restart=on-failure
RestartSec=1

[Install]
WantedBy=dev-vpi.device

      et le script : 

      #!/bin/sh
xinput | grep EPSON | grep -oP '(?<=id=)[0-9]+' | xargs -I % xinput map-to-output % DP-2
logger -t epson 'epson détecté...'

      Le service est activé par par systemctl --user enable epson-vpi.service

      En branchant le VPI, je vois bien que le script est lancé
      Mais le stylet n'est pas aligné !! alors que si l’utilisateur lance la commande directement, ça fonctionne et le stylet est aligné.

      Pourtant dans ce cas, su n'est pas nécessaire, c'est bien l'utilisateur qui exécute le script.

  • # Où cela commence à fonctionner

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

    Je progresse (enfin j'espère)

    N'ayant pas de VPI à la maison, je me suis rabattu sur ce que j'avais, plus simple et finalement plus accessible. J'arrive à quelque chose qui fonctionne. J'ai utilisé comme périphérique USB une tablette graphique wacom et simplement xeyes comme programme à lancer.

    fichier ̀ /etc/udev/rules.d/90-usb-test.rules` : 

    ACTION=="add|remove", SUBSYSTEM=="input", ENV{DEVLINKS}=="*Wacom_Co*-event-mouse", RUN+="/usr/local/bin/usb-test.sh"

    Et dans le script /usr/local/bin/usb-test.sh : 

    #!/bin/sh

# valeurs pour mon portable perso
USER_NAME="christian"
DISPLAY_VALUE=":0"

su - "$USER_NAME" -c "DISPLAY=$DISPLAY_VALUE /usr/bin/xeyes" &

    Constats :
    - xeyes est bien lancé à chaque branchement - débranchement de la tablette
    - ça marche même sans export et sans préciser le fichier .Xauthority

    Demain j'essaye de remplacer d'abord la chaîne caractéristique de la tablette par une du VPI epson
    Ensuite de remplacer xeyes par la longue ligne xinput | grep EPSON | grep -oP '(?<=id=)[0-9]+' | xargs -I % xinput map-to-output % DP-2

    Reste une partie pour laquelle je n'ai pas d'idée : l'utilisateur est codé pour le moment en dur. Comment faire pour remplacer USER_NAME="christian" par le nom de l'utilisateur qui est effectivement connecté à l'ordinateur ? (non prévisible : il s'agit des utilisateurs du domaine)

    • [^] # Re: Où cela commence à fonctionner

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

      C'est pour cela que j'envisageais un unit utilisateur.
      On connait déjà l'utilisateur. Et pas que.
      J'ai fait le test rapidement, chez moi, la variable DISPLAY est positionnée dans ce cas.

      Sinon, pour trouver l'utilisateur qui a ouvert la première session :

      w|grep seat0|cut -d' '  -f1

      Quand une seule commande est lancée, ici xeyes, pas besoin d'export, mais ta commande est composée de plusieurs appels de programmes enchainés.

      • [^] # Re: Où cela commence à fonctionner

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

        On connait déjà l'utilisateur.

        J'ai peut-être mal compris mais en fait non, on ne le connais pas. J'ai fait des tests avec un utilisateur connu mais à priori on ne le connaît pas : c'est un utilisateur lambda du domaine.

        pour trouver l'utilisateur qui a ouvert la première session :

        C'est plutôt le dernier, ou plutôt celui qui a une session graphique ouverte au moment où le script est lancé.
        Il peut y avoir plusieurs utilisateurs qui se sont succédé et qui n'ont pas forcémentfermé leur session.

        • [^] # Re: Où cela commence à fonctionner

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

          Question peut-être bête : est ce que 

          loginctl list-sessions | awk '$6=="active" {print $3}'

          est quelque chose de sûr ? Ça à l'air de renvoyer l'id de l'utilisateur connecté mais il y a peut-être un problème caché…

          • [^] # Re: Où cela commence à fonctionner

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

            En effet, seat0 c'est peut-être pas le meilleur choix… la ligne où idle est à 0.00s.

            Ça doit fonctionner tant que tu ne changes pas de version de systemd.
            Ça ne marche pas chez moi.

            Je peux avoir l'info avec loginctl session-status

            C'est une bonne idée, mais prépare-toi à modifier ton script à l'avenir

    • [^] # Re: Où cela commence à fonctionner

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

      Avec cet exemple, ça fonctionne sans règle udev supplémentaire :

      Le nom du fichier (ici dev-sdb1.device) doit correspondre à un des fichiers de périphérique créé quand tu allumes l'appareil.

      /usr/lib/systemd/user/dev-sdb1.device

      [Unit]
Description=Detects the usb stick is mounted
Requires=test.service

      /usr/lib/systemd/user/test.service 

      [Unit]
Description=Start a program when a usbstick is plugged

[Service]
Type=oneshot
ExecStart=kgx -e /home/geegeek/test.sh &

      (On doit pouvoir utiliser un template si on a plusieurs ports usb, plusieurs clés usb…)

      Le service n'a même pas à être activé puisqu'il est déclenché par l'unit device.

      • [^] # Re: Où cela commence à fonctionner

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

        Le nom du fichier (ici dev-sdb1.device) doit correspondre à un des fichiers de périphérique créé quand tu allumes l'appareil.

        /usr/lib/systemd/user/dev-sdb1.device

        Les périphériques créés sont : 

        /dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-event-if02
/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-if02-event-mouse
/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-if02-mouse
/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-if01-event-mouse
/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-if01-mouse
/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-event-mouse
/dev/input/by-id/usb-EPSON_EPSON_EPSON_695Wi_695WT-mouse
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.2-event
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.2-event-mouse
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.2-mouse
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.1-event-mouse
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.1-mouse
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.0-event-mouse
/dev/input/by-path/pci-0000:00:15.0-usb-0:4.3:1.0-mouse

        donc pour moi, si je suis bien, ce serait un fichier : /usr/lib/systemd/user/dev-usb-EPSON_EPSON_EPSON_695Wi_695WT-mouse.device ?

        • [^] # Re: Où cela commence à fonctionner

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

          Dans un des précédents messages, tu évoques un périphérique /dev/vpi (dev-vpi.device)
          Peut-être faut-il une règle udev quand même pour nommer le device plus simplement.

          Ces chemins sont stables, mais je ne suis pas sûr de la syntaxe quand il y a des tirets dans le nom…
          dev-input-by-id-usb-EPSON_EPSON_EPSON_695Wi_695WT-mouse.device ?

          • [^] # Re: Où cela commence à fonctionner

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

            Dans un des précédents messages, tu évoques un périphérique /dev/vpi

            Mea culpa, c'était un raccourci parce que je n'avais pas le nom complet sous les yeux.

    • [^] # Re: Où cela commence à fonctionner

      Posté par  . Évalué à 1 (+0/-0). Dernière modification le 19 janvier 2026 à 09:59.

      Bonjour

      Ça ne résoudra pas le problème, mais on peut remplacer :

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

      par :

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

      ou bien par :

      xinput map-to-output $(xinput | grep -oP 'EPSON.+\K(?<=id=)[0-9]+') DP-2

      … et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.

    • [^] # Re: Où cela commence à fonctionner

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

      Solution provisoire et mise en test

      Un fichier /etc/udev/rules.d/90-usbepson.rules : 

      ACTION=="add|remove", SUBSYSTEM=="input", ENV{DEVLINKS}=="*usb-EPSON_EPSON_EPSON_695Wi_695WT-mouse", RUN+="/usr/local/bin/map-epson2.sh"

      un script /usr/local/bin/map-epson2.sh : 

      !/bin/sh

USER_NAME=$(loginctl list-sessions | awk '$6=="active" {print $3}')
DISPLAY_VALUE=":0.0"

su - "$USER_NAME" -c "export DISPLAY=$DISPLAY_VALUE;  sh -c \"xinput | grep EPSON | grep -oP '(?<=id=)[0-9]+' | xargs -I % xinput map-to-output % DP-2 \""

      Ça semble fonctionner comme souhaité, du moins quand on branche le VPI avec une session ouverte. Reste à voir les cas où le VPI est déjà allumé et branché et le changement d'utilisateur…

      • [^] # Re: Où cela commence à fonctionner

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

        Finalement cela n'a pas survecu au redémarrage : ça ne fonctionne plus. J'ai ajouté echo "$(date)- start" >> /tmp/foobar.log au script pour constater qu'il n'est plus lancé par le branchement du VPI…

      • [^] # Re: Où cela commence à fonctionner

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

        Bonjour

        Il est possible que l'évènement add soit détecté par la règle udev trop tôt <=> avant que le VPI ne soit complètement initialisé et que tous les liens pour y accéder aient été créés.
        Un des derniers évènements bind concernant ce périphérique serait peut-être plus fiable.

        Il faudrait que le script lancé par la règle udev ne fasse rien s'il ne détecte pas de session ouverte par le compte utilisateur concerné.

        Pour le cas où le VPI serait déjà connecté et allumé au moment de l'ouverture de session du compte utilisateur,
        un script, lancé par l'ouverture de session, pourrait tester la présence des liens qui auront été créés pour ce VPI
        et donc ne lancer les commandes xinput nécessaires que si ces liens existent.

        … et dans ce royaume, ceux qui y voient un peu plus clair sont parfois très mal vus.

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.