cévhé a écrit 454 commentaires

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 :
capture
Les deux fichiers ont les même droits

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

C'est XFCE.

J'ai aussi pensé à bidouiller ces « symboles » pour en mettre des transparents à la place mais (sans avoir testé) je suppose que cela sera aussi pris en compte pour des affichages plus légitimes comme pour l'affichage des fichiers dans thunar.

Peut-être qu'en en mettant des beaucoup plus petits, ça passerait mieux. Au pire...

Merci ça marche !

Reste un détail cosmétique : l'icône est affublée de l'attribut visuel des liens symboliques et de la lecture seule, ce qui n'est pas très élégant. Est-ce possible de ne pas les afficher ?
Titre de l'image

Merci je vais étudier tout ça...

J'ai l'impression que le titre de ton commentaire ne reflète pas tout à fait son contenu...

Je progresse (pas tout seul, merci à ceux qui se sont penchés là dessus ici et à Abdelkarim sur un salon tchap)

Je suis arrivé à obtenir le résultat escompté, pour mémoire (et plus de clarté j'espère) c'est ceci :
Titre de l'image

Résultat obtenu en tâtonnant, il me faut 4 lignes de commande :

xrandr --output HDMI-1 --mode 1360x768 --output eDP-1 --mode 1920x1080 --same-as HDMI-1
xrandr --output HDMI-1 --panning 1360x768
xrandr --output eDP-1 --panning 1360x768
xrandr --output eDP-1 --fb 1360x768 --transform 1,0,-280,0,1,-156,0,0,1
Je l'ai testé avec mon portable (eDP-1 1920x1080) et une télé (HDMI-1 1360x768), je retesterai en vrai avec un VP et l'ordinateur prévu à la rentrée.

Il me reste une question : peut-on regrouper ces 4 lignes en une seule ? Toujours en tâtonnant, je n'y suis pas arrivé :-(

Testé avec ma télé (HDMI-1 1360x768) comme deuxième écran :

xrandr --output eDP-1 --fb 1360x768 --transform 1,0,-280,0,1,-156,0,0,1 --output HDMI-1 --mode 1360x768 --same-as eDP-1
renvoie le même genre de message d'erreur :

xrandr: specified screen 1360x768 not large enough for output eDP-1 (1920x1080+-280+-156)
X Error of failed request: BadMatch (invalid parameter attributes)
 Major opcode of failed request: 140 (RANDR)
 Minor opcode of failed request: 29 (RRSetPanning)
 Serial number of failed request: 39
 Current serial number in output stream: 39

l'écran du portable passe bien au format attendu mais la sortie HDMI-1 ne s'active pas (vérifié avec arandr)

:-(

Merci ! Ça semble marcher (écran seul mais au moins ça donne le résultat escompté).

Néanmoins, xrandr laisse quand même des messages d'erreurs que je ne comprend pas :

~$ xrandr --output eDP-1 --fb 1440x900 --transform 1,0,-240,0,1,-90,0,0,1
xrandr: specified screen 1440x900 not large enough for output eDP-1 (1920x1080+-240+-90)
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 140 (RANDR)
Minor opcode of failed request: 29 (RRSetPanning)
Serial number of failed request: 39
Current serial number in output stream: 39

« not large enough » bin si, c'est le but

mais les deux autres erreurs ??