cévhé a écrit 448 commentaires

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

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 ?

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 :

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

Testé rapidement, avec seulement l'écran du portable (pas de vidéoproj sous la main, le collège est fermé pour les vacances, j'essayerai avec la télé quand elle sera disponible)

xrandr --output eDP-1 --scale-from 1440x900
déforme l'image à l'écran. Elle semble bien faire 1440x900 mais occupe tout l'écran : donc déformée et la résolution est moche.

J'aimerai garder le DPI correct de l'écran et donc avoir un truc comma ça :

Avec une image réduite mais de qualité correcte, de même dimensions que le VP.

Bin oui minoritaire ne devrait pas être un problème.
Excepté ici, les linuxiens sont généralement des minoritaires, non ?

Pourtant ils ont quand même raison…

De toute façon, il ne répond plus

Vécu par fiston qui avait changé d’opérateur. Bug évident dès le premier jour : impossible de recevoir des mms. Ticket, relance, rien pendant plus de 15j
Il veut rechanger d’opérateur (faut pas pousser quand même), demande son RIO et … « bonjour c’est le support technique de SFR »

En fait ça n'a pas l'air trop méchant… donc je suspends ma demande pour essayer tout seul.

Et si ça marche pas je reviens ;-)

Je suis assez « pseudonymé » ici (mais en deux clics on trouve mon nom et mon établissement) pour raconter ce que je fais dans mon bahut (avec l’accord de la cheffe quand même)

Je remplace progressivement des ordinateurs de 2018 Windows 10 pour les passer sous Linux. Connexion internet, intégration au domaine et montage des partages compris. Mais c’est quand même ce qu’Alexis appelle des « shadow Linux »
Je profite en fait d’un déconnage du serveur wsus qui plante ces machines et avec toute ma mauvaise foi la comparaison ne peut que être en faveur de Linux…
Mais comme le tech de la collectivité n’arrive pas à réparer, il faut bien trouver des solutions, non ?