gilloraymondo wrote:Bonjour
Avec une faible résolution (800x480), je ne peux pas voir le bas de plein de fenêtres.
Un solution est de se servir de xrandr, en "panning" avec une résolution virtuelle de 800x730
J'ai donc créé, avec geany, un fichier "45x11-xrandr" dans /etc/X11/Xsession.d
Dans ce fichier j'ai écrit :
#!/bin/sh
xrandr --output LVDS1 --mode 800x480 --panning 800x730
Puis, en allant dans Rox, j'ai surligné le fichier 45x11-xrandr", puis clic droit, et clic sur "permissions", clic sur "silencieux" puis sur "oui"
A condition de refaire l'opération plusieurs fois, ça finit par marcher.... mais ce serait mieux de ne pas avoir à répéter l'opération car, au redémarrage, il faut tout recommencer !!!!
Il y a une façon de faire pour "fixer" cette résolution virtuelle de façon à ce que ça fonctionne automatiquement à chaque redémarrage ?
Merci
Salut, gilloraymondo.
Intelligent, le monsieur !!!
Mais c'est pas là que va ton script. Enfin... peut-être. ( « C'est flou dans ma tête. »
Et comme Cyrano, y a juste moi qui ai le droit de dire ça !!!!)
Sérieusement : Place-z-en une copie (je dis bien « une copie », et non pas un lien
symbolique) dans /etc/init.d sous le nom < start_45x11-xrandr > et rends ce fichier
< start_45x11-xrandr > exécutable.1
Le contenu de /etc/init.d est exécuté à chaque démarrage à froid, avant xwin, avant
.xinitrc et avant le contenu de /root/Startup. En particulier les scripts dont le nom
porte la mention « start_ ». À l'inverse, les scripts dans ce répertoire portant la
mention « stop_ » ne sont exécutés qu'à la fermeture de la session.
Comme exemple, voici le contenu de mon répertoire /etc/init.d :
Code: Select all
[/etc/init.d]>ls -x
00sys_logger* 10alsa* cups*
dbus* dbus-machine-id-gen* distmp3*
frisbee.sh* gpm* javaif.sh*
messagebus@ minidlna rc.acpi*
rc.firewall* rc.pcmcia* rc.samba
rc.umntshares* rc.yassm* README.txt
rsync* saned* setserial*
start_cpu_freq* start_ntp-sync.sh* stop_ramdisk-0.1*
sysfsutils* usb-modeswitch*
La plupart sont des scripts de Puppy par défaut. J'ai cependant un script là pour un
disque virtuel (« ramDisque ») que je me suis fait, et ça fonctionne comme un moine.
D'expérience, je te dirai qu'une restriction qu'on doit s'imposer pour ce répertoire (il y
en a peut-être d'autres, la doc est quasi inexistante pour cette caractéristique) est de
ne pas y placer des scripts qui
dépendent d'une synchronisation de temps.
Comme tu vois, j'ai aussi dans ça mon script < start_ntp-sync.sh >. Celui-là est
bien à sa place, parce que c'est le script « maître » pour définir le temps sur mon
ordi. (Ma pile BIOS étant DCD...) Par contre, si je voulais voir un calendrier ou un
emploi du temps au démarrage, je mettrais son script de démarrage dans
/root/Startup, avec un délai de quelques secondes (10 ? ... selon la vitesse de ton
ordi) au début pour donner à < ntp-sync > le temps de finir son boulot.
Alors, voilà. Pas de garantie, je n'ai jamais essayé de mettre un script xrandr dans
/etc/init.d. Mais « qui n'essaye rien n'a rien », pas vrai !?
Avant que tu poses la question : ce n'est pas dangereux, pour des trucs comme
xrandr ou ntp-sync ou zram. Le pire qui puisse arriver est que ça ne marche pas et
que l'exécution de ton script soit ignorée, tout simplement.2
Donne-nous-en des nouvelles ?
~~~~~~~~~~~~~
Note 1) Pour « fixer » la permission d'exécuter un script, en console, on tape
. Mais qu'on le fasse en console ou avec ROX, le résultat
devrait être le même, et permanent. Curieux, ton phénomène...
Note 2)
(Ou encore quand « Jean-Baptiste » a commis une erreur dans son code !!! Je le
mentionne parce que, étant donné que ces commandes sont exécutées très en
amont, en aveugle, pour ainsi dire (pour l'utilisateur humain, en tout cas), elles sont
très difficiles à déboguer. On ne peut pas inclure une commande < set -xe > au
début du script et une commande < set +xe > à la fin du script pour en voir
l'exécution. Étant donné la position, on ne voit rien de toute façon et
< set -xe > figerait le processus de mise en place du Puppy s'il y avait une
erreur sérieuse, parce que < set -xe > arrête tout à la première erreur. Alors,
il vaut mieux ne pas enclencher le débogueur et tester, tester, tester... à la main.)