Lancement d'une commande au démarrage de Gnome

Bonjour,

Je suis entrain de faire avec l’aide de Scorpio810 un petit How-To dans “Trucs et Astuces”

Je recherche un moyen de lancer une commande avec Gnome…

Dans Préférences > Sessions > Programmes au démarrage, j’ai donc ajouter la commande :
"xset dpms 180 180 180 " (Celle que je veux lancer…)
Je redémarre l’interface graphique, et puis il y a un pseudo blocage du splash screen de Gnome…
Il reste affiché jusqu’a ce qu’on clique dessus, alors qu’avant il partait tout seul…
La commande “xset dpms…” par contre c’est bien lancée…

J’ai aussi testé en faisant un renvoi vers un fichier texte contenant la commande. J’ai aussi essayé avec la commande sleep pour reporter l’exécution de la commande le tant que le splash screen se ferme mais en vain…
J’ai aussi testé par le fichier init, mais il faut absolument que l’interface graphique soit ouverte avant d’utiliser la commande, sinon ca renvoie une erreur…

J’ai donc 2 questions :

:arrow_right: Est-ce que quelqu’un peut faire le test et me dire s’il tombe sur le même résultat que moi ?

:arrow_right: Avez-vous une solution au problème ?

Merci

Lightning

J’ai placé la commande à l’endroit voulu, j’ai relancé xorg (ALT - CTRL BackSpace) : redémarrage normal.
J’ai redémarré : tout se passe normalement.
Pour info : tout en sid, noyau 2.6.20-1-k7, xorg 7.2.3, pilote vidéo nv
Aucun blocage. Peut-être est-ce différent avec un autre noyau ou un autre pilote graphique ?

Tout d’abord merci à toi de m’aider. C’est pas la première fois que tu me files un coup de main, alors merci. :slightly_smiling:

Si ca marche dans ton cas, alors c’est parfait : Je vais pouvoir faire mon tutorial.

Le problème doit venir comme tu le précises des versions utilisées. Dans mon cas :

Debian Etch
2.6.18-4-486 i686
Gnome 2.14.3

Je pense que ca vient de Gnome, mais j’en suis pas sur…

sid, donc gnome 2.18.1
Comme il s’agit d’une commande pour X, peut être que cela peut aussi venir de la version de x ? Je ne suis pas assez compétant pour pouvoir répondre … Désolé .

@Lightning
je ne me sers plus de cette commande j’avais le problème a l’époque sur dapper kubuntu et au début de ma migration vers debian on etait encore en kde 3.5.4 je crois , depuis kde 3.5.5 ,et maintenant kde 3.5.6 je n’ai plus ce bug , il existe sur gnome encore ?

toutes mes machines sont sur debian unstable et se portent bien
mais ça peut etre utile pour ceux qui ont se probleme sur les anciennes stables

hs
@ginkgo biloba sur ta sid avec le kernel 2.6.20 as tu pu faire marcher module-assistant pour creer le module nvidia-kernel-2.6.20

Il semblerait que la version Gnome de “Etch” comporte ce bug à moins que ce ne soit Xorg…

Faudrait savoir ce qui se passe réellement quand on ajoute une commande au démarrage grâce à Gnome ou à KDE : Qui execute la commande : Gnome ou Xorg ???

En passant sur “Sid” ca semble ne pas poser de problèmes selon ginkgo biloba.

quote="Lightning"
Faudrait savoir ce qui se passe réellement quand on ajoute une commande au démarrage grâce à Gnome ou à KDE : Qui execute la commande : Gnome ou Xorg ???
(…)[/quote]Ni l’un ni l’autre. C’est au nom de l’user qui ouvre la session que tout s’execute (il est d’ailleurs le seul à avoir accés au serveur x)

Bon bah alors comme ca on est fixé… :laughing:

Mais maintenant pour savoir d’ou vient le problème, ca ne va pas être une mince affaire !..

Light’ :wink:

Oui et non :laughing:
Non avec mon PC principal en sid 32 (avec une 7300 LE et un AMD X2) et oui avec une sid 64 (avec une nv5500 AGP et un AMD).
Il y a un problème cité dans les messages d’erreurs en sid 32 :[quote]
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol ▒
│ ‘paravirt_ops’[/quote]
Sur un post, quelqu’un a résolu le problème en compilant le noyau et en virant une option (de mémoire).

j’ai essaye de virer la paravirtualisation du kernel j’ai pu ensuite creer le module nvidia adapté a mon noyau (2.6.20-k7) installer les legacy en version 71xx dessus , les 96xx j’y suis pas arrivé
reset du serverX ok , reboot ok sauf sur la session monitor activé =screen black
retour sur les nv

alors que sur une autre machine en sid aussi mais en 64 bits je suis en nvidia 75xx et ça roule

tu parlais de ça ?

[quote]my workaround was to disable paravirtualization in kernel
(paravirt_ops have EXPORT_SYMBOL_GPL in Module.symvers and I think this
couses the problem)
I’ve done this, more or less, that way:

  1. Install linux-source-2.6.20-1-686
  2. Uncompress /usr/src/linux-source-2.6.20-1-686.tar.bz2
  3. delete symlink /lib/modules/2.6.20-1-686/build and make new (ln -s
    /usr/src/linux-source-2.6.20 /lib/modules/2.6.20-1-686/build)
  4. copy .config from headers to sources (cp
    /usr/src/linux-headers-2.6.20-1-686/.config /usr/src/linux-source-2.6.20)
  5. in sources dir ‘make menuconfig’ and disable paravirtualization in
    ’processor features’
  6. make prepare
  7. make scripts
  8. now i could compile and install nvidia kernel drive[/quote]

Oui, cela ressemblait à cela.
Pour la sid64, c’est la version 9755-1 ne nvidia-glx qui tourne avec un noyau 2.6.20-1-amd64.
La version 9755-1 de nvidia-glx tourne en sid avec le noyau 2.6.18-4-k7

bon ça marche sur mon autre k7 avec le nvidia-kernel-legacy-1.0.9631-2
et le kernel 2.6.20-k7 modifie (sans la paravirtualisation )

Pour la sid64, c’est la version 9755-1 ==> pareil pour moi sauf kernel 2.6.20-amd64