cévhé a écrit 386 commentaires

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

?

Il y a bien le export (j'ai aussi essayé sans et :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 !

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 ?

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.

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 :-/

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 ???

Pas mieux :-(

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 ;-) )

Oui…

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

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.

Des LinuxFrNonBinaires sur un site d'informatique, ce serait un grand changement de paradigme.

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

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

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

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

Y a-t-il une différence légale entre la VOD « en location » et « en vente » au niveau de la copie privée ?

Le problème c'est que 100 % de mon équipe est nulle et à 100 % constituée de moi-même.

Je ne suis vraiment pas aidé par mon équipe ;-)

J'ai peut-être trouvé la solution, vous me direz si c'est propre ou pas.

Les fichiers .desktop sont placés dans /etc/skel directement, droit d'exécution positionnés, comem prévu initialement.

La copie dans le home se fait correctement mais il y a l'avertissement gênant pour l'utilisateur.

Si l'utilisateur exécute gio set ~/Desktop/lelanceur.desktop metadata::trusted true l'avertissement disparaît** mais seulement après reconnexion**. J'avais déjà essayé cela mais sans penser à faire une déconnexion-reconnexion :-(

Je vais donc essayer d'insérer, juste après session required pam_mkhomedir.so skel=/etc/skel/ umask=jesaisplusquoi la commande for f in ~/Desktop/*.desktop; do gio set "$f" metadata::trusted true; done

Pas eu le temps de tester cet automatisme, mais sur le principe cela parait plus propre, non ?

pourquoi ne pas juste parametrer thunar pour afficher de dossier sur le bureau

je ne comprend pas ce que tu suggères. Peux-tu préciser ?

C'est fait, et de toute façon, j'ai bidouillé sur machine virtuelle. Jour férié oblige je n'ai pas accès au serveur du collège

Bourrin mais efficace ! Merci…

Sauf qu'il y en a un certain nombre… je les change tous ?

find /usr/share/icons/Yaru/ -name emblem-readonly.png
/usr/share/icons/Yaru/8x8/emblems/emblem-readonly.png
/usr/share/icons/Yaru/256x256/emblems/emblem-readonly.png
/usr/share/icons/Yaru/32x32/emblems/emblem-readonly.png
/usr/share/icons/Yaru/16x16@2x/emblems/emblem-readonly.png
/usr/share/icons/Yaru/8x8@2x/emblems/emblem-readonly.png
/usr/share/icons/Yaru/256x256@2x/emblems/emblem-readonly.png
/usr/share/icons/Yaru/48x48@2x/emblems/emblem-readonly.png
/usr/share/icons/Yaru/24x24@2x/emblems/emblem-readonly.png
/usr/share/icons/Yaru/32x32@2x/emblems/emblem-readonly.png
/usr/share/icons/Yaru/24x24/emblems/emblem-readonly.png
/usr/share/icons/Yaru/16x16/emblems/emblem-readonly.png
/usr/share/icons/Yaru/48x48/emblems/emblem-readonly.png


En fait les "emblèmes" ne semblent pas être affichés en dehors du bureau :

Les deux fichiers ont les même droits

Ça laisse entrevoir une solution un peu bourinne mais réalisable