Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : Multimedia

Vim en moteur de slide - Vroom

Patrice Ferlet

Si vous suivez un peu mon blog, vous connaissez mon adoration pour le terminal de commande, vim et tout outil fonctionnant en mode console. J'ai toujours trouvé plus clair ce fonctionnement que de passer par des outils graphiques pour la moindre action. Aujourd'hui, c'est un outil de présentation (un slide si vous préférez) que j'ai découvert. Ça va vite, c'est pratique, c'est fonctionnel et ça marche avec Vim... En clair, ça a tout pour me plaire. Laissez-moi vous présenter "vroom"

Vroom est un package Perl installable aisément avec cpan. Il est fourni avec un exécutable qui va vous permettre de créer rapidement un slide fonctionnant en mode console. Ça peut paraitre fou de faire un slide en mode console, et pourtant l'intérêt est là. Car en ayant simplement du texte vous vous forcez à rendre "lisible" le slide.

Il est clair que ce genre de slide est plutôt ciblé pour les présentations de technologies de développement. Vroom a par ailleurs la possibilité d'exécuter du code contenu dans un slide, ce qui vous permet de montrer un petit bout de code et de l'exécuter afin de présenter le résultat.

Quoiqu'il en soit, commençons par l'installer.

Je vous l'ai dit, Vroom est un package Perl. De ce fait, on utilise CPAN pour installer le paquet:

su -c "cpan install Vroom"

Acceptez toutes les questions proposées à l'installation. En quelques secondes vous allez avoir l'outil installé sur votre poste.

Vous pouvez maintenant créer un répertoire quelque part, ici j'utiliserai "~/slidetuto/" pour des raisons pratiques. La suite logique est la suivante:

  • on créer un répertoire pour la présentation
  • on génère un template de slide
  • on édite le slide, on ajoute des entrées, on configure un peu...
  • on affiche le slide

Mais avant tout, vous devez modifier un fichier qui va permettre à Vim de lire une configuration spécifique qui sera créée par Vroom dans votre répertoire de slide. Ouvrez le fichier "~/.vimrc" et ajoutez quelque part (à la fin du fichier par exemple):

" for vroom
set exrc

Voilà, maintenant on y va... On commence par créer un template:

mkdir ~/slidetuto/
cd ~/slidetuto/
vroom -new

Un fichier est alors créé: "slides.vroom". C'est le fichier qui va avoir tout le contenu. Il y a pas mal de commentaires dans ce template. Pour le moment, on ne va pas le modifier et simplement lancer le slide:

vroom -vroom slides.vroom

Vim se lance, et le premier slide apparait. Pressez la touche Espace et vous passez au second slide, pressez une nouvelle fois Espace et vous voyez des lignes apparaitre au fur et à mesure. Arrivé au slide 5 vous allez voir un bout de code Perl. Pressez alors la séquence "RR" (Shift R R) et voilà le code exécuté.

Vous pouvez revenir en arrière avec la touche Backspace (la touche d'effacement).

Bref, arrivé à la fin du slide, vous pouvez quitter en pressant QQ (encore une fois, avec la touche Maj enfoncée).

Si vous regardez dans le répertoire, vous voyez une série de fichiers qui a été générée. En fait, Vroom fait simplement une ouverture dans l'ordre de fichier, et passe de buffer en buffer via un map de commande (Espace mappé en ":n" pour passer au buffer suivant). C'est bête comme choux, mais ça marche.

Vroom

Regardons le fichier slides.vrooms.

En haut, une partie sert à la configuration du slide. Vous pouvez ici surcharger un comportement de vim (par exemple, pour ma part, je dois forcer "set nonumber" pour ne pas avoir de numéro de ligne) ou encore forcer les dimensions de slide. Une option intéressante est justement de permettre le calcul automatique de la taille en fonction du terminal. Il suffit de décommenter "auto_size: 1" et le tour est joué.

Du coup, vous pouvez changer la taille de police de votre terminal pour la rendre plus lisible sur un rétroprojecteur, et tout va se caller correctement.

Ensuite, chaque slide est séparé par 4 tirets sur une ligne "". Cette ligne peut aussi permettre de spécialiser un slide, par exemple vous voyez dans le template de base qu'un slide est utilisé pour lancer du Perl (et avoir la coloration syntaxique). Les slides de code permettent d'utiliser Perl, PHP, Python, Sh, Haskell, et quelques autres...

Un double égal (==) permet de définir le titre (qui sera centré). Et si une ligne commence par "+" alors elle n'apparaitra qu'après avoir pressé Espace.

C'est simple... et ça fonctionne.

Pour ceux qui comme moi avez déjà un .vimrc fourni, et qui vous demande d'avoir une configuration forcée, voici comment faire.

Dans la partie de configuration, en haut, ajoutez simplement:

vimrc: |
    set nonumber

Ou tout autres options dont vous avez besoin.

Il est possible d'exporter votre slide en HTML, en texte brut, et il existe même un bindings pour envoyer vos slides sur github.

Le seul défaut que j'ai trouvé est que si vous vous trompez dans la configuration de votre slide, la commande "vroom -vroom slides.vroom" ne vous donne aucune information... mais je pense que cela va évoluer.

Voilà, j'ai tout simplement trouvé ce système intéressant, je m'en sers de plus en plus pour faire des vidéos didacticiels, et je pense que vous pouvez avoir un intérêt à l'utiliser.

Vim en moteur de slide - Vroom

Patrice Ferlet

Si vous suivez un peu mon blog, vous connaissez mon adoration pour le terminal de commande, vim et tout outil fonctionnant en mode console. J'ai toujours trouvé plus clair ce fonctionnement que de passer par des outils graphiques pour la moindre action. Aujourd'hui, c'est un outil de présentation (un slide si vous préférez) que j'ai découvert. Ça va vite, c'est pratique, c'est fonctionnel et ça marche avec Vim... En clair, ça a tout pour me plaire. Laissez-moi vous présenter "vroom"

Vroom est un package Perl installable aisément avec cpan. Il est fourni avec un exécutable qui va vous permettre de créer rapidement un slide fonctionnant en mode console. Ça peut paraitre fou de faire un slide en mode console, et pourtant l'intérêt est là. Car en ayant simplement du texte vous vous forcez à rendre "lisible" le slide.

Il est clair que ce genre de slide est plutôt ciblé pour les présentations de technologies de développement. Vroom a par ailleurs la possibilité d'exécuter du code contenu dans un slide, ce qui vous permet de montrer un petit bout de code et de l'exécuter afin de présenter le résultat.

Quoiqu'il en soit, commençons par l'installer.

Je vous l'ai dit, Vroom est un package Perl. De ce fait, on utilise CPAN pour installer le paquet:

su -c "cpan install Vroom"

Acceptez toutes les questions proposées à l'installation. En quelques secondes vous allez avoir l'outil installé sur votre poste.

Vous pouvez maintenant créer un répertoire quelque part, ici j'utiliserai "~/slidetuto/" pour des raisons pratiques. La suite logique est la suivante:

  • on créer un répertoire pour la présentation
  • on génère un template de slide
  • on édite le slide, on ajoute des entrées, on configure un peu...
  • on affiche le slide

Mais avant tout, vous devez modifier un fichier qui va permettre à Vim de lire une configuration spécifique qui sera créée par Vroom dans votre répertoire de slide. Ouvrez le fichier "~/.vimrc" et ajoutez quelque part (à la fin du fichier par exemple):

" for vroom
set exrc

Voilà, maintenant on y va... On commence par créer un template:

mkdir ~/slidetuto/
cd ~/slidetuto/
vroom -new

Un fichier est alors créé: "slides.vroom". C'est le fichier qui va avoir tout le contenu. Il y a pas mal de commentaires dans ce template. Pour le moment, on ne va pas le modifier et simplement lancer le slide:

vroom -vroom slides.vroom

Vim se lance, et le premier slide apparait. Pressez la touche Espace et vous passez au second slide, pressez une nouvelle fois Espace et vous voyez des lignes apparaitre au fur et à mesure. Arrivé au slide 5 vous allez voir un bout de code Perl. Pressez alors la séquence "RR" (Shift R R) et voilà le code exécuté.

Vous pouvez revenir en arrière avec la touche Backspace (la touche d'effacement).

Bref, arrivé à la fin du slide, vous pouvez quitter en pressant QQ (encore une fois, avec la touche Maj enfoncée).

Si vous regardez dans le répertoire, vous voyez une série de fichiers qui a été générée. En fait, Vroom fait simplement une ouverture dans l'ordre de fichier, et passe de buffer en buffer via un map de commande (Espace mappé en ":n" pour passer au buffer suivant). C'est bête comme choux, mais ça marche.

Vroom

Regardons le fichier slides.vrooms.

En haut, une partie sert à la configuration du slide. Vous pouvez ici surcharger un comportement de vim (par exemple, pour ma part, je dois forcer "set nonumber" pour ne pas avoir de numéro de ligne) ou encore forcer les dimensions de slide. Une option intéressante est justement de permettre le calcul automatique de la taille en fonction du terminal. Il suffit de décommenter "auto_size: 1" et le tour est joué.

Du coup, vous pouvez changer la taille de police de votre terminal pour la rendre plus lisible sur un rétroprojecteur, et tout va se caller correctement.

Ensuite, chaque slide est séparé par 4 tirets sur une ligne "". Cette ligne peut aussi permettre de spécialiser un slide, par exemple vous voyez dans le template de base qu'un slide est utilisé pour lancer du Perl (et avoir la coloration syntaxique). Les slides de code permettent d'utiliser Perl, PHP, Python, Sh, Haskell, et quelques autres...

Un double égal (==) permet de définir le titre (qui sera centré). Et si une ligne commence par "+" alors elle n'apparaitra qu'après avoir pressé Espace.

C'est simple... et ça fonctionne.

Pour ceux qui comme moi avez déjà un .vimrc fourni, et qui vous demande d'avoir une configuration forcée, voici comment faire.

Dans la partie de configuration, en haut, ajoutez simplement:

vimrc: |
    set nonumber

Ou tout autres options dont vous avez besoin.

Il est possible d'exporter votre slide en HTML, en texte brut, et il existe même un bindings pour envoyer vos slides sur github.

Le seul défaut que j'ai trouvé est que si vous vous trompez dans la configuration de votre slide, la commande "vroom -vroom slides.vroom" ne vous donne aucune information... mais je pense que cela va évoluer.

Voilà, j'ai tout simplement trouvé ce système intéressant, je m'en sers de plus en plus pour faire des vidéos didacticiels, et je pense que vous pouvez avoir un intérêt à l'utiliser.

Typescript to gif - convertir une capture terminal vers un gif animé

Patrice Ferlet

Comment utiliser la commande "script" et un peu de bash + imagemagick pour en faire une animation en GIF (ou pourquoi pas une vidéo par la suite)

Cette semaine, un administrateur système m'a montré une commande que je ne connaissais pas du tout... "script". Ce petit utilitaire permet d'enregistrer le flux terminal vers un fichier afin d'être relu. En grattant dans le "man" j'ai découvert deux options intéressantes, l'une d'elle permet de garder les "temps" de commande + le nombre de caractères à lire... On peut alors utiliser "scriptreplay" pour relire la session ou bien, comme moi, jouer avec et créer une animation

Prenons le temps de comprendre. Si je tape la commande:

script --timing=/tmp/timing /tmp/script

alors commence une session enregistrée dans le fichier /tmp/script.

Tapons alors des commandes, par exemple

echo "hello world"

Puis pressez CTRL+D. La session "script" s'arrête. Vous pouvez rejouer la session (qui ne va pas rejouer les commandes, mais les afficher avec les résultats de l'époque...) en utilisant "cat"

cat /tmp/script

Or... on a besoin de voir "à la replay" la commande. Soit:

scriptreplay -t /tmp/timing /tmp/script

Et là, c'est déjà plus joli. Mais voilà, pour partager une capture de ce genre en vidéo (ou en gif animé) ce format ne nous convient pas encore. On va donc réfléchir recréer une belle vidéo de tout ce beau monde.

Première option, on fait un screencast (avec ffmpeg) mais bon... la souris peut apparaître... et puis pour en faire un gif c'est pas encore ça.

Seconde option, celle qu'on va mettre en place, est de faire ceci: - relire le fichier /tmp/timing - prendre séquence par séquence le texte depuis le typescript (fichier généré par la commande script) - afficher ça dans le terminal et faire une capture du terminal avec la commande "import" - relire une fois de plus le timing et cette fois ci: lire les temps d'attente - utiliser "convert" avec l'option -delay pour mettre frame à frame les images dans le gif animé.

Voilà... bon je vais pas passer par 4 chemins, le but n'est pas de vous apprendre à faire du bash mais au moins vous parler des "soucis" que j'ai dut régler: - lire un fichier d'un certain endroit à un autre: on utilise "dd" - créer des images numérotées avec 5 chiffres pour être à l'aise: printf

Le reste coule presque de source... Voilà le script:

#!/bin/bash
 
TIMING=$1
SCRIPT=$2
W=$WINDOWID
 
rm -rf /tmp/script-replay-gifs/
mkdir /tmp/script-replay-gifs/
 
t=$(mktemp)
cp $SCRIPT $t
 
#remove first line
sed -i '1d' $t
 
#clear screen
clear
 
#read timing file one by one
curr=0
i=0
while read line
do
    #capture time and chars to read
    cols=($line)
    chars=${cols[1]}
 
    #read from current char the number of chars to read
    dd if=$t bs=1 skip=$curr count=$chars 2>/dev/null
 
    #convert to gif frame with a nice frame-number
    n=$(printf "%010d" $i)
    import -window $WINDOWID /tmp/script-replay-gifs/$n.gif
 
    #and move to next position
    curr=$((curr+chars))
    i=$((i+1))
done <$TIMING
rm -f $t
 
#now, set gif with delay per frame
i=1
while read line
do
    cols=($line)
    timing=${cols[0]}
    #get next image
    file=$(ls -1 /tmp/script-replay-gifs/ | head -n $i | tail -n 1)
    timing=$(echo "$timing*100" | bc -l | awk '{print int($0)}')
    command=$command" -delay $timing /tmp/script-replay-gifs/$file"
 
    i=$((i+1))
done < $TIMING
 
convert $command /tmp/anim-notoptim.gif
convert /tmp/anim-notoptim.gif -coalesce -layers Optimize /tmp/anim.gif
 
rm -f /tmp/anim-notoptim.gif
rm -rf  /tmp/script-replay-gifs/

Ce script est très très lent à cause de "import" qui prend près d'une seconde par capture... de ce fait pour le moment c'est pas un modèle du genre... et en plus, vous ne pouvez pas quitter le bureau dans lequel vous être pour créer l'animation sous peine de messages d'erreur. Notez que ce n'est un qu'un petit test

Cela donne: Animation terminal

Pour le coup, j'ai quand même posé un petit coup de "gimp" pour optimiser le gif animé. Je vous laisse maître de me faire des remarques et pourquoi pas (si vous le demandez) je créerai un dépôt git quelque part pour qu'on le fasse évoluer.

Update: j'ai ajouté une opération d'optimisation de taille à la fin du script

Typescript to gif - convertir une capture terminal vers un gif animé

Patrice Ferlet

Comment utiliser la commande "script" et un peu de bash + imagemagick pour en faire une animation en GIF (ou pourquoi pas une vidéo par la suite)

Cette semaine, un administrateur système m'a montré une commande que je ne connaissais pas du tout... "script". Ce petit utilitaire permet d'enregistrer le flux terminal vers un fichier afin d'être relu. En grattant dans le "man" j'ai découvert deux options intéressantes, l'une d'elle permet de garder les "temps" de commande + le nombre de caractères à lire... On peut alors utiliser "scriptreplay" pour relire la session ou bien, comme moi, jouer avec et créer une animation

Prenons le temps de comprendre. Si je tape la commande:

script --timing=/tmp/timing /tmp/script

alors commence une session enregistrée dans le fichier /tmp/script.

Tapons alors des commandes, par exemple

echo "hello world"

Puis pressez CTRL+D. La session "script" s'arrête. Vous pouvez rejouer la session (qui ne va pas rejouer les commandes, mais les afficher avec les résultats de l'époque...) en utilisant "cat"

cat /tmp/script

Or... on a besoin de voir "à la replay" la commande. Soit:

scriptreplay -t /tmp/timing /tmp/script

Et là, c'est déjà plus joli. Mais voilà, pour partager une capture de ce genre en vidéo (ou en gif animé) ce format ne nous convient pas encore. On va donc réfléchir recréer une belle vidéo de tout ce beau monde.

Première option, on fait un screencast (avec ffmpeg) mais bon... la souris peut apparaître... et puis pour en faire un gif c'est pas encore ça.

Seconde option, celle qu'on va mettre en place, est de faire ceci: - relire le fichier /tmp/timing - prendre séquence par séquence le texte depuis le typescript (fichier généré par la commande script) - afficher ça dans le terminal et faire une capture du terminal avec la commande "import" - relire une fois de plus le timing et cette fois ci: lire les temps d'attente - utiliser "convert" avec l'option -delay pour mettre frame à frame les images dans le gif animé.

Voilà... bon je vais pas passer par 4 chemins, le but n'est pas de vous apprendre à faire du bash mais au moins vous parler des "soucis" que j'ai dut régler: - lire un fichier d'un certain endroit à un autre: on utilise "dd" - créer des images numérotées avec 5 chiffres pour être à l'aise: printf

Le reste coule presque de source... Voilà le script:

#!/bin/bash

TIMING=$1
SCRIPT=$2
W=$WINDOWID

rm -rf /tmp/script-replay-gifs/
mkdir /tmp/script-replay-gifs/

t=$(mktemp)
cp $SCRIPT $t

#remove first line
sed -i '1d' $t

#clear screen
clear

#read timing file one by one
curr=0
i=0
while read line
do
    #capture time and chars to read
    cols=($line)
    chars=${cols[1]}
   
    #read from current char the number of chars to read
    dd if=$t bs=1 skip=$curr count=$chars 2>/dev/null

    #convert to gif frame with a nice frame-number
    n=$(printf "%010d" $i)
    import -winow $WINDOWID /tmp/script-replay-gifs/$n.gif

    #and move to next position
    curr=$((curr+chars))
    i=$((i+1))
done <$TIMING
rm -f $t

#now, set gif with delay per frame
i=1
while read line
do
    cols=($line)
    timing=${cols[0]}
    #get next image
    file=$(ls -1 /tmp/script-replay-gifs/ | head -n $i | tail -n 1)
    timing=$(echo "$timing*100" | bc -l | awk '{print int($0)}')
    command=$command" -delay $timing /tmp/script-replay-gifs/$file"

    i=$((i+1))
done < $TIMING

convert $command /tmp/anim-notoptim.gif
convert /tmp/anim-notoptim.gif -coalesce -layers Optimize /tmp/anim.gif

rm -f /tmp/anim-notoptim.gif
rm -rf  /tmp/script-replay-gifs/

Ce script est très très lent à cause de "import" qui prend près d'une seconde par capture... de ce fait pour le moment c'est pas un modèle du genre... et en plus, vous ne pouvez pas quitter le bureau dans lequel vous être pour créer l'animation sous peine de messages d'erreur. Notez que ce n'est un qu'un petit test

Cela donne: Animation terminal

Pour le coup, j'ai quand même posé un petit coup de "gimp" pour optimiser le gif animé. Je vous laisse maître de me faire des remarques et pourquoi pas (si vous le demandez) je créerai un dépôt git quelque part pour qu'on le fasse évoluer.

Update: j'ai ajouté une opération d'optimisation de taille à la fin du script

Radeon et Blender font mauvais ménage

Patrice Ferlet

En fait, ce n'est pas seulement pour Blender que je vais parler, mais certaines applications 3D qui peuvent avoir tendance à planter misérablement en utilisant une carte ATI (AMD) sur notre Fedora 15... Car voilà, depuis mon passage à Fedora 15, tout se passe bien sauf un truc: travailler sous Blender. J'ai tout tenté: passage à Xfce pour éviter Mutter, recompilation de Blender, debugage, ... et rien n'y faisait. Après quelques minutes, un plantage et pas moyen de trouver une solution. Sauf que j'ai trouvé un tour de passe-passe qui permet, pour le moment, de palier le souci.

Bon avant toutes chose, un petit tour vers le rapport de bug que j'ai commenté: libllvmcore-2.8.so.debug has no usable debug info Ça donne pas envie hein... En fait pour faire court, un souci bien dégoûtant apparaît avec le pilote radeon et en plus de cela on a pas les infos de débogage pour notre problème. Raaa la rage m'envahissait et comme je voulais finir un boulot sur Blender, me fallait vite une solution.

Et bien j'ai finis par y aller "bourrin"... en utilisant une compilation du pilote "gallium". C'est en fait une compilation "grotesque" qui va me permettre d'utiliser une librairie openGL très épurée. Donc certes je vais perdre l'antialiasing et certainement avoir une visu assez moche dans Blender, mais au moins ça ne plantera pas. Et pour vous rassurer, seule la vue 3D est impactée, le rendu et le traitement image/vidéo ne sont pas impactés.

Bon et bien voici la méthode:

#on va dans notre répertoire perso
cd ~
#on clone le dépot mesa
git clone git://anongit.freedesktop.org/git/mesa/mesa
cd mesa

#on compile le driver gallium, donc pas de DRI pour radeon et consorts
make  linux-x86-64 -j4
#make  linux-x86-32 -j4 pour les cpu 32 bits

#si vous avez un core i7, vous pouvez mettre -j8 au lieu de -j4
#on attend un peu la fin de la compilation puis
cd lib64 #ou cd lib si vous êtes sur un pc 32 bits

#à faire avant de lancer blender...
export LD_LIBRARY_PATH=~/mesa/lib64
#puis on lance blender
cd ~/blender-2.58
./blender -w

Deux choses, d'une part évitez le mode plein écran, perso ça fait un truc tout bizarre sur mon pc... et secondo, utilisez l'option "-w" comme spécifié, ça évitera des ennuis de bordure que j'ai vu sur mon poste.

Si vous avez des soucis, passez de Gnome à Xfce. Ca limitera les appels OpenGL et les court-circuits d'affichage. Toujours est-il que ça marche, ça marche même pas mal du tout... c'est moins beau, oui, mais ça marche.

Aussi, pour couper l'herbe sous les pieds des trolls qui vont arriver en commentaire: oui, ATI sur linux c'est pas bien, je sais, mais j'ai pas le choix pour deux raisons: d'une j'ai un laptop (ordinateur portable) et le prix était intéressant avec cette carte, et secondo j'utilise de temps en temps un kernel RT qui ne marche pas avec les pilotes nvidia. Donc je sais, j'ai pas une bonne config, mais je suis pas le seul. Et quand bien même, un matériel ne doit pas engendrer un souci de ce genre alors qu'il est récent.

Soit dit en passant, bien que le bug soit là, on apprécie tout de même d'avoir utilisé des logiciels libres. Car si tout ce que j'utilise était propritaire, je n'aurai pas de solution pour contourner le problème. Là, encore une fois, en suivant quelques indications, on arrive à se dépêtrer d'un gros problème parce que nous pouvons compiler et/ou modifier des sources.

Alors dans notre malheur, vous et moi qui avons des soucis avec cette radeon, réjouissons nous de pouvoir travailler en mode dégradé grâce à la philosophie du logiciel libre, et de ne pas rester coincé !

Radeon et Blender font mauvais ménage

Patrice Ferlet

En fait, ce n'est pas seulement pour Blender que je vais parler, mais certaines applications 3D qui peuvent avoir tendance à planter misérablement en utilisant une carte ATI (AMD) sur notre Fedora 15... Car voilà, depuis mon passage à Fedora 15, tout se passe bien sauf un truc: travailler sous Blender. J'ai tout tenté: passage à Xfce pour éviter Mutter, recompilation de Blender, debugage, ... et rien n'y faisait. Après quelques minutes, un plantage et pas moyen de trouver une solution. Sauf que j'ai trouvé un tour de passe-passe qui permet, pour le moment, de palier le souci.

Bon avant toutes chose, un petit tour vers le rapport de bug que j'ai commenté: libllvmcore-2.8.so.debug has no usable debug info Ça donne pas envie hein... En fait pour faire court, un souci bien dégoûtant apparaît avec le pilote radeon et en plus de cela on a pas les infos de débogage pour notre problème. Raaa la rage m'envahissait et comme je voulais finir un boulot sur Blender, me fallait vite une solution.

Et bien j'ai finis par y aller "bourrin"... en utilisant une compilation du pilote "gallium". C'est en fait une compilation "grotesque" qui va me permettre d'utiliser une librairie openGL très épurée. Donc certes je vais perdre l'antialiasing et certainement avoir une visu assez moche dans Blender, mais au moins ça ne plantera pas. Et pour vous rassurer, seule la vue 3D est impactée, le rendu et le traitement image/vidéo ne sont pas impactés.

Bon et bien voici la méthode:

#on va dans notre répertoire perso
cd ~
#on clone le dépot mesa
git clone git://anongit.freedesktop.org/git/mesa/mesa
cd mesa

#on compile le driver gallium, donc pas de DRI pour radeon et consorts
make  linux-x86-64 -j4
#make  linux-x86-32 -j4 pour les cpu 32 bits

#si vous avez un core i7, vous pouvez mettre -j8 au lieu de -j4
#on attend un peu la fin de la compilation puis
cd lib64 #ou cd lib si vous êtes sur un pc 32 bits

#à faire avant de lancer blender...
export LD_LIBRARY_PATH=~/mesa/lib64
#puis on lance blender
cd ~/blender-2.58
./blender -w

Deux choses, d'une part évitez le mode plein écran, perso ça fait un truc tout bizarre sur mon pc... et secondo, utilisez l'option "-w" comme spécifié, ça évitera des ennuis de bordure que j'ai vu sur mon poste.

Si vous avez des soucis, passez de Gnome à Xfce. Ca limitera les appels OpenGL et les court-circuits d'affichage. Toujours est-il que ça marche, ça marche même pas mal du tout... c'est moins beau, oui, mais ça marche.

Aussi, pour couper l'herbe sous les pieds des trolls qui vont arriver en commentaire: oui, ATI sur linux c'est pas bien, je sais, mais j'ai pas le choix pour deux raisons: d'une j'ai un laptop (ordinateur portable) et le prix était intéressant avec cette carte, et secondo j'utilise de temps en temps un kernel RT qui ne marche pas avec les pilotes nvidia. Donc je sais, j'ai pas une bonne config, mais je suis pas le seul. Et quand bien même, un matériel ne doit pas engendrer un souci de ce genre alors qu'il est récent.

Soit dit en passant, bien que le bug soit là, on apprécie tout de même d'avoir utilisé des logiciels libres. Car si tout ce que j'utilise était propritaire, je n'aurai pas de solution pour contourner le problème. Là, encore une fois, en suivant quelques indications, on arrive à se dépêtrer d'un gros problème parce que nous pouvons compiler et/ou modifier des sources.

Alors dans notre malheur, vous et moi qui avons des soucis avec cette radeon, réjouissons nous de pouvoir travailler en mode dégradé grâce à la philosophie du logiciel libre, et de ne pas rester coincé !

keytouch-2.3.0-1

Xavier Lamien

rpm_icone
Une nouvelle version de keytouch est disponible pour Fedora

Lire la suite