Bien re-bonjour à tous,
suite à une discussion sur le blabla je me suis lancé dans l'installation et la configuration de DirectFB sur une Debian (pour ajouter un fond d'écran sur un ou plusieus ttys). Seulement après quelques tests en machine virtuelle et sur une Ubuntu 10.04, je me heurte à quelques problèmes:

Tout d'abord, la version des paquets relatifs à DirectFB disponibles dans les dépôts de Squeeze et de Lucid Lynx est la 1.2.8, or sur le site ( http://directfb.org/downloads/Core/ ), la dernière en date est la 1.5. Dans tous les cas, pour les raisons que j'énoncerai plus bas, je ne peux pas utiliser la version des dépôts car elle n'est pas compilée correctement pour ce que je veux en faire, mais je voulais avoir votre avis:
Dois-je compiler la version 1.2 ou la 1.5, sachant que j'ai testé la 1.5 et que la compilation ne pose pas de problèmes ? Y a-t-il une raison particulière qui pourrait expliquer que les dépôts ne proposent que la .2 à l'heure actuelle à votre avis ?

Deuxième soucis, pour utiliser dfbg (l'utilitaire associé pour configurer l'image/couleur de fond du framebuffer), il est dit dans le man que mon DirectFB doit avoir le "multi-application core". Après lecture du readme dans les sources, j'ai vu que ça consiste en trois étapes:

-Compiler DirectFB en ayant précisé l'option --enable-multi lors de la configuration (aucun problème de ce côté, sinon le choix de version)

-Installer le module "linux-fusion" (enfin fusion tout court): je l'ai trouvé en *.deb, jusque là j'ai rien eu à faire, dkms s'est occupé de le compiler et soit-disant de l'installer pour moi, sauf qu'il l'a laissé dans /var/lib/dkms/(...), ce qui fait que je ne peux le lancer qu'avec insmod -f pour le moment: j'aimerais savoir si je peux l'ajouter manuellement dans /lib/modules/`uname -r`/ ou s'il y a moyen de faire ça plus proprement (enfin bon déplacer un *.ko je vois pas 15 façons de le faire)... En prime, j'ignore dans quel sous répertoire le placer (kernel ou build )

-Monter un tmpfs nommé /dev/shm, ça c'est pas dur (ils fournissent même la commande dans le readme), seulement dans le cadre d'une utilisation automatique j'aimerais bien qu'ça se fasse tout seul, je voulais donc savoir si je peux ajouter une entrée dans ma fstab au même titre que les autres fs du système ?

Bien voilà, désolé pour le gros pudding de questions, mais je préfère tout poser d'un coup plutôt que de revenir 15 fois en pleurant parce que ça marche pas D'ailleurs j'espère bien que ça va finir par marcher, ça va faire quelques semaines que je cherche un fichtre-moyen de mettre un fond d'écran dans mon malheureux tty
d'avance

[Désolé pour le double post]

Je me disais bien que j'oubliais un truc: toujours sur Lucid, j'ai donc compilé DirectFB 1.5, j'ai installé libdirectfb en 1.5 aussi (en trichant un peu, elle existe qu'en *.rpm donc j'en ai fait un *.deb avec alien, arrêtez-moi si j'ai fait un crime mais a priori c'est proprement installé), j'ai ajouté le module fusion à la main (puis `lsmod |grep fusion`, il est bien chargé), j'ai monté le tmpfs (il est bel et bien présent dans /dev/ aussi)...
Et quand je teste, que ce soit pour changer la couleur de fond ou ajouter une image, j'ai cette erreur qui revient à chaque fois:
"(!) DirectFB/FBDev: Could not set gamma ramp --> Invalid argument"
Et puis là ben, rien, retour case départ.
En plus de cette erreur, quand je tente d'afficher une image en fond j'ai la suivante juste après:
"(!!!) *** WARNING [still objects in 'GraphicsState Pool'] *** [object.c:239 in fusion_object_pool_destroy()]"
Celle là je sais pas ce qu'elle vaut, d'intuition j'aurais tendance à dire que c't'une conséquence de la première, à vous d'en juger

Voilà, en espérant que vous pourrez m'aider

« arrêtez-moi si j'ai fait un crime » au nom de la loi, je vous arrête !

alien ça ne devrait plus exister :
1. Debian fait partie des distros qui ont le plus de paquets,
2. les conventions de nommages n'ont rien à voir entre RedHat/Mandriva et Debian donc la gestion des dépendances est à chier.

De mémoire, on peut très bien faire joujou avec directfb 1.2.8 qui est une bonne version. Par contre, je viens d'essayer sur ma machine et dfbg marche très bien … comme utilitaire à XDirectFB (ou équivalent). Comprendre par là que si tu lances dfbg tout seul, ça va changer le fond d'écran… puis comme plus personne n'utilise le framebuffer, celui-ce retrouve réinitialisé.
Peut-être qu'en lançant un DFBterm en même temps tu pourrais arriver au résultat escompté.

Au passage, jète un coup d'œil au (décédé ?) projet ByzantineOS qui, si ma mémoire est bonne, est un liveCD proposant une interface graphique entièrement basée sur Directfb.

Bah pour alien j'me disais bien que c'est pas propre comme truc, mais coup de bol pour moi la librairie concernée n'avait aucune dépendance (sinon j'imagine bien qu'avec des paquets plus "standards" ça doit être très folklorique ). Et c'est vrai qu'ya beaucoup de raisons de se contenter des dépôts Debian (c'est la première fois que ce dont j'ai besoin n'y est pas d'ailleurs )

"Comprendre par là que si tu lances dfbg tout seul, ça va changer le fond d'écran… puis comme plus personne n'utilise le framebuffer, celui-ce retrouve réinitialisé."
J'suis pas sur de saisir là, en théorie getty et bash utilisent bien le framebuffer sur la vraie console non ?
(et dans mon cas précis je soupçonne l'histoire de "could not set gamma [...]" de causer l'arrêt net du processus...
Tu utilises XDirectFB comme interface graphique ? Et tu veux dire qu'ya pas moyen d'utiliser dfbg sans lui ou DFBterm à côté si j'ai bien compris ?

Non parce que de mon côté j'suis allé chercher ledit DFBTerm qui dépend de LiTE, donc j'ai tenté de compiler LiTE (dernière version, 0.8.10), sauf que pendant la compil' j'ai quelques joyeusetés en sortie (je veux dire en plus de toutes les belles choses qu'un compilateur peut avoir à raconter)... donc je lance `#make check` comme dit dans le guide d'installation, au début RàS jusqu'à cette étape:

"Making check in examples
make[1]: entrant dans le répertoire « /home/julien/Téléchargements/LiTE-0.8.10/examples »
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -D_REENTRANT -I/usr/local/include/directfb
-DEXAMPLESDATADIR=\"/usr/local/share/LiTE/examples
\" -Wall -O3 -pipe -Werror-implicit-function-declaration -MT dfbspy.o -MD -MP -MF .deps/dfbspy.Tpo -c -o dfbspy.o dfbspy.c
dfbspy.c:94: error: ‘stat’ redeclared as different kind of symbol
/usr/include/sys/stat.h:453: note: previous definition of ‘stat’ was here
make[1]: *** [dfbspy.o] Erreur 1
make[1]: quittant le répertoire « /home/julien/Téléchargements/LiTE-0.8.10/examples »
make: *** [check-recursive] Erreur 1"

Donc voilà, il doit y avoir une malédiction qui pèse sur moi, ma mauvaise langue a envie de dire que c'est un vice dans la source de LiTE (j'essaierai les versions antérieures dans le courant de l'aprèm ), mais je suis sûr de rien à ce propos

« c'est la première fois que ce dont j'ai besoin n'y est pas d'ailleurs » parce que tu n'as pas vraiment besoin de ce dont tu crois avoir avec besoin en fait.

« J'suis pas sur de saisir là, en théorie getty et bash utilisent bien le framebuffer sur la vraie console non ? » plutôt non. getty et bash ça utilise stdout et stderr. Le fait que ces flux se transforment en caractères affichés à l'écran via la couche de framebuffer c'est un problème du noyau… pas des applis.

Ce qui se passe, c'est que ton dfbg demande de prendre possession du framebuffer, obtient la permission, fait son changement, puis rend la main au noyau… qui récupère le framebuffer pour le gérer à sa sauce.

Tu utilises XDirectFB comme interface graphique ? » nop, je n'ai jamais réussi à la faire tourner correctement sur ma Debian (lenny/unstable la dernière fois que j'ai essayé).

« Et tu veux dire qu'ya pas moyen d'utiliser dfbg sans lui ou DFBterm à côté si j'ai bien compris ? » je n'en suis pas certain. Il faut plutôt voir ça comme une hypothèse que je formule suite à l'expérience que j'ai de directFB.

Pour DFBterm, c'était même de l'ordre de la piste à creuser. J'ai jamais essayé de le faire tourner lui. En tout cas, vu les erreurs, il va falloir mettre la main dans le code et nettoyer si tu veux arriver à quelque chose.

À l’époque (2007), sous Gentoo, je faisais ce genre de truc avec fbsplash/fbcondecor. Je suis probablement complètement has-been vu que le kms est passé par là depuis mais ça peut être une piste demandant moins de mettre les mains dans la mouise.

Sankukai Je me suis déjà orienté vers fbsplash/fbcondecor après lecture de topics sur d'autres forums, le soucis c'est qu'à part sur Gentoo (et mon objectif serait de le faire sous Debian ), c'est pas vraiment proprement implémenté ces choses là j'ai l'impression. Et comme d'hab on lit de tout, certains qui proposent gentiment de recompiler le noyau, d'autres qui viennent prêcher pour Arch en disant qu'on peut justement télécharger un noyau configuré pour fbcondecor depuis l'AUR...

Chris Le soucis c'est que je n'ai honnêtement pas encore le niveau (la route est longue ) pour revoir intégralement un code de cette envergure écrit par quelqu'un d'autre... après j'peux toujours essayer mais j'vais déjà voir si ça passe avec une autre version de LiTE à tout hasard (celles disponibles dans la section "Old" satisfont quand même la dépendance de DFBterm).
Et sinon juste en passant, c'est avec quelle interface que dfbg fonctionne sur ta machine Si c'est un truc stable & léger ça peut m'intéresser pour mon laptop, j'vais bientôt y mettre Debian aussi (et j'ai qu'un chipset dessus donc j'y perdrais pas trop en perfs je pense...)

C'est clair que tu t'attaques à un gros morceau là. Cela dit, recompiler son noyau c'est loin d'être dantesque. Si tu sais où est la bonne case à cocher pour arriver à tes fins, c'est même tout juste l'affaire de 15 minutes.

« c'est avec quelle interface que dfbg fonctionne sur ta machine » je te résume ma manip:
ctrl+alt+F2
login en chris
$ dfbg -c 00FF0000
oh tiens, ça clignotte en rouge et ça redevient comme avant.

Ah ok, donc pareil que moi quoi :3

Pour le noyau, c'est pas la première fois qu'on me dit que c'est largement faisable, j'ai même un bouquin (qui date, mais bouquin quand même) qui me semble-t-il explique la démarche générale (et puis Google est là pour ça au pire )

Bon je regarde un peu du côté du code tout de même, comme dit dans l'erreur que j'ai citée, le problème vient du fichier dfbspy.c situé dans le sous-dossier examples... et ya une histoire de "‘stat’ redeclared as different kind of symbol".
J'hésite à faire un pastebin du fichier en cas (techniquement le monsieur dit que j'ai le droit tant que je laisse son commentaire en introduction ), je sais pas si quelqu'un se sentirait de voir ce qui colle pas à la ligne 94 (enfin je sais pas si ça se limite vraiment à "une" ligne, vu que c'est une histoire de déclaration à tous les coups l'erreur se prolonge dans toute la suite du code )

Sinon après bah il me restera l'alternative du noyau à recompiler ... Je me demande juste s'il est utilisable par n'importe quelle distro en fait.

cf la seconde partie de https://www.jeuxvideo.com/forums/1-38-7665853-165-0-1-0-0.htm#message_7696781 aussi.

Merci

de quoi occuper mes prochaines nuits

Sinon euh, j'ai (théoriquement) corrigé l'erreur dans ledit fichier ( http://pastebin.com/DVZ5E6jn ), toujours d'après make la variable "stat" était déjà définie dans /usr/include/stat.h, donc j'ai improvisé une méthode qui a apparemment marché: j'ai renommé toutes les occurrences de ladite stat en "foo" (original, je sais ), maintenant c'est compilé et (mal?) installé.

`dfbterm` "dfbterm: error while loading shared libraries: liblite.so.3: cannot open shared object file: No such file or directory"

:fuuuuu: . Devine en quel format elle est disponible :alien: ...

En fait le noyau c't'une meilleure idée effectivement

Bon je crois que l'aventure avec DirectFB va s'arrêter là pour moi, j'ai installé liblite.so.3, maintenant dfbterm se lance mais j'ai droit à un bon gros bug sauce moutarde (les entrées au clavier qui comptent double, j'ai même plus envie de savoir ce qui peut causer ça de toutes façons ).

Merci pour votre aide en tout cas, ça m'aura permis d'apprendre pas mal de trucs (au moins le temps passé sur ce genre de choses n'est jamais totalement perdu )

En même temps, ton liblite.so.3 tu n'as presque aucun moyen de savoir ce qu'il y a dedans.

Je me cite :
« 2. les conventions de nommages n'ont rien à voir entre RedHat/Mandriva et Debian donc la gestion des dépendances est à chier. »
Ce n'était PAS une remarque de l'ordre du détail.

Je sais que c'est sale mais c'était ma dernière cartouche, maintenant c'est direction poubelle
C't'un peu dommage parce qu'a priori ça avait l'air faisable (enfin on lit rarement des manpages mentionnant le contraire faut dire ), m'enfin bon .
Et j'ai viré alien aussi, c'est pas le genre de trucs dont j'irai me servir sur un système que je veux maintenir stable