Si vous avez activé le compositing de Xfwm/Xfce pour avoir de jolies ombres et effets de transparence appliqués à vos fenêtres (ce qui est le cas par défaut sous Xubuntu), vous avez peut-être remarqué que cela entraine un effet de tearing lors de la lecture de vidéos, ou lors d’un défilement de page dans Firefox.
Qu’est-ce que le tearing ? C’est lorsque l’image affichée par votre moniteur change alors qu’il est en train de l’afficher ; on peut à ce moment voir un bout de la nouvelle image en haut de l’écran et un bout de l’ancienne image en dessous. Cela produit un décalage horizontal visible lors des scènes où la caméra bouge beaucoup dans les films, ou dans les jeux.
Pour résoudre ce problème, j’ai désactivé le compositing de Xfwm et installé Compton à la place. En bonus, j’ai maintenant un très agréable effet de fondu lors de l’ouverture ou la fermeture des fenêtres, ainsi que lors du passage d’un workspace à un autre.
Pour désactiver le compositing de Xfwm, tapez cette commande dans un terminal :
xfconf-query -c xfwm4 -p /general/use_compositing -s false
Pour installer Compton, vous pouvez sous Arch Linux utiliser le package compton-git de l’AUR, ou sous Xubuntu taper ces lignes dans un terminal :
sudo add-apt-repository ppa:richardgv/compton
sudo apt-get update && sudo apt-get install compton
(Source : http://lubuntublog.blogspot.com.es/p/compton.html )
Ensuite il suffit de taper cette commande :
compton -c -f -o 1.0 -I 0.1 -O 0.1 -C -i 0.95 -z --vsync opengl --unredir-if-possible --shadow-exclude "! name~=''" -b
Et hop :
Explication rapide des paramètres :
-c -C -o 1.0 : active les ombres
-f -I 0.1 -O 0.1 : active l’effet de fondu lorsqu’une fenêtre s’ouvre ou se ferme
-i 0.95 -z : rend les fenêtres inactives légèrement transparentes
--vsync opengl : supprime le tearing
--unredir-if-possible : optimisation pour les fenêtres plein écran
--shadow-exclude "! name~=''" : corrige le problème de fenêtre noire lors de l’utilisation de alt-tab (ça désactive l’ombre pour toutes les fenêtres sans nom)
Pour que Compton soit lancé à chaque démarrage, il faut ajouter cette commande dans ~/.xinitrc (sous Arch), ou dans ~/.xsession sous Xubuntu (je
n’ai pas testé). Vous pouvez aussi utiliser les options de session et
démarrage qui sont accessibles dans le gestionnaire de préférences.
Je peux maintenant regarder des vidéos avec VLC sans avoir à désactiver le compositing auparavant, et ça c’est top.
Mise à jour du 13 avril : Il y a encore de temps en temps un léger tearing avec la méthode que j’utilise ("--vsync opengl" ou "--vsync drm"). Pour complètement le supprimer, vous pouvez essayer "--backend glx --vsync opengl-swc --paint-on-overlay" à la place ; mais personnellement je reste sur "--vsync opengl" car le backend glx (opengl) entraîne un ralentissement de l’affichage sur mon Core i3 de première génération.
Mise à jour du 14 avril : Avec "--backend glx --vsync opengl-swc --paint-on-overlay --glx-no-stencil", l’affichage se fait à nouveau en 60 fps et il ne semble y avoir qu’une seule frame de retard à l’affichage.
dimanche 7 avril 2013
samedi 23 février 2013
SDL : Unable to open a console terminal
Un petit post pour aider ceux qui pourraient avoir le même souci que moi : après avoir compilé la lib SDL 1.2.15 dans une machine virtuelle Ubuntu 10.04 (dans le but d’en faire une version qui fonctionne sur la plupart des distributions récentes), je la teste sous Arch Linux et j’obtiens un résultat étrange :
- X disparait pour afficher à la place un TTY…
- je dois presser Ctrl-alt-F2 puis Ctrl-alt-F1 pour revenir à X
- mon programme affiche dans le terminal ce mystérieux message d’erreur :
Après des recherches web ne retournant ni explication ni solution, je cherche le message d’erreur dans les sources de la SDL et vois qu’il provient du fichier video/fbcon/SDL_fbevents.c. fbcon ? Pourquoi est-ce que la SDL essaye d’utiliser une framebuffer console au lieu d’ouvrir une fenêtre sous X ??
J’essaye de forcer l’utilisation du pilote X11 :
export SDL_VIDEODRIVER=x11
./MonJeu
… et j’obtiens cet autre message d’erreur :
Conclusion : sous Ubuntu ou Debian, installez libxext-dev avant de compiler la libSDL, sinon elle ne gérera pas l’ouverture de fenêtres sous X. Sous Arch Linux, vous avez probablement déjà le package libxext installé.
*en fait, non, ça ne marche toujours pas, mais le message d’erreur a disparu et la fenêtre de mon jeu s’ouvre brièvement. J’ai juste d’autres problèmes à corriger…
- X disparait pour afficher à la place un TTY…
- je dois presser Ctrl-alt-F2 puis Ctrl-alt-F1 pour revenir à X
- mon programme affiche dans le terminal ce mystérieux message d’erreur :
Error initializing video: Unable to open a console terminalPourtant j’ai compilé la libSDL avec exactement les mêmes options que dans le PKGBUILD sdl d’Arch Linux, et mon jeu fonctionne très bien avec la lib d’Arch !
Après des recherches web ne retournant ni explication ni solution, je cherche le message d’erreur dans les sources de la SDL et vois qu’il provient du fichier video/fbcon/SDL_fbevents.c. fbcon ? Pourquoi est-ce que la SDL essaye d’utiliser une framebuffer console au lieu d’ouvrir une fenêtre sous X ??
J’essaye de forcer l’utilisation du pilote X11 :
export SDL_VIDEODRIVER=x11
./MonJeu
… et j’obtiens cet autre message d’erreur :
Error initializing video: No available video deviceQuelqu’un dans le canal #SDL sur IRC me demande si le ./configure affiche que X est supporté ou non, et je relance donc la VM pour voir ça. Mon script de compilation installe automatiquement deux packages qui, curieusement, ne m’avaient pas été nécessaires pour compiler la version 64 bit de la SDL, mais étaient requis en 32 bit : libxext-dev et x11proto-xext-dev. Et lorsque je teste à nouveau mon jeu sous Arch avec la nouvelle version de la lib 64 bit, ça fonctionne !*
Conclusion : sous Ubuntu ou Debian, installez libxext-dev avant de compiler la libSDL, sinon elle ne gérera pas l’ouverture de fenêtres sous X. Sous Arch Linux, vous avez probablement déjà le package libxext installé.
*en fait, non, ça ne marche toujours pas, mais le message d’erreur a disparu et la fenêtre de mon jeu s’ouvre brièvement. J’ai juste d’autres problèmes à corriger…
mardi 20 novembre 2012
Utiliser Git pour patcher un projet open-source sous svn
J’ai commencé il y a quelques mois à modifier pour mon usage personnel un logiciel open-source. Son code étant hébergé dans une base Subversion (svn) sur SourceForge, j’avais tout simplement fait un « svn checkout » du projet et commencé à taper dans le code pour faire mes modifications.
Et puis un jour j’ai voulu soumettre un patch aux développeurs. Problème : si je fais un « svn diff », j’obtiens tous mes changements en vrac. Comment faire ? Éditer le diff à la main n’est pas très pratique et source d’erreurs. Faire un deuxième checkout et y copier-coller à la main ce que je veux intégrer au patch est fastidieux.
J’ai donc décidé d’utiliser Git et sa supériorité écrasante (si si, il parait) dans la gestion des branches pour créer mes futurs patchs. L’idée est de créer une nouvelle branche pour chaque patch. Ensuite un simple diff entre deux branches permet de générer le patch souhaité.
Voici comment ça marche :
Ça peut prendre très longtemps car ça récupère tout l’historique du projet. Dans mon cas, ça a pris dans les 2 heures pour environ 5500 révisions svn.
Cette opération crée automatiquement une branche nommée « master » dans laquelle on ne fera jamais de commit. Ça sera la branche de référence permettant de générer les patchs.
- pour voir les fichiers modifiés :
- pour vérifier ce qu’on a changé avant de commiter :
- pour commiter :
Si le patch est intégré au code source officiel du projet, vous pouvez alors supprimer la branche :
La méthode est au final assez simple et je peux confirmer que les développeurs n’ont aucun souci avec les patchs créés par git ;-).
Il y a tout de même quelques autres commandes à connaitre :
D’abord mettre à jour la branche master :
Puis mettre à jour la branche sur laquelle vous travaillez :
Il peut arriver qu’il y ait des conflits à cette étape, mais je n’ai pas d’instructions détaillées à proposer dans ce cas de figure. Git indique lui-même les commandes à taper pour annuler ou continuer la mise à jour.
Notez que si vous avez compilé la branche my-great-patch avant de passer à la branche my-other-great-patch, il faudra probablement faire un « make clean » pour effacer tous les fichiers générés du projet avant de le recompiler (utilisez ccache pour gagner du temps !).
Notez également qu’une pression sur TAB complete tout seul les noms de branche git (sous zsh / Arch Linux). Très pratique :-). Il est également possible de configurer son prompt pour qu’il affiche le nom de la branche courante (je vous laisse chercher comment ; je ne l’ai pas fait).
(C’est totalement indépendant de la branche git courante.)
Si en attendant que vos patchs soient acceptés vous voulez les utiliser en local, il peut être intéressant de créer une branche combinant toutes les autres… À priori le plus simple est d’utiliser « git merge » :
Voilà pour cette fois. Have fun ;-).
Et puis un jour j’ai voulu soumettre un patch aux développeurs. Problème : si je fais un « svn diff », j’obtiens tous mes changements en vrac. Comment faire ? Éditer le diff à la main n’est pas très pratique et source d’erreurs. Faire un deuxième checkout et y copier-coller à la main ce que je veux intégrer au patch est fastidieux.
J’ai donc décidé d’utiliser Git et sa supériorité écrasante (si si, il parait) dans la gestion des branches pour créer mes futurs patchs. L’idée est de créer une nouvelle branche pour chaque patch. Ensuite un simple diff entre deux branches permet de générer le patch souhaité.
La méthode pas à pas
Voici comment ça marche :
1) Récupérer le projet
git svn clone https://…
Ça peut prendre très longtemps car ça récupère tout l’historique du projet. Dans mon cas, ça a pris dans les 2 heures pour environ 5500 révisions svn.
Cette opération crée automatiquement une branche nommée « master » dans laquelle on ne fera jamais de commit. Ça sera la branche de référence permettant de générer les patchs.
2) Créer une branche dédiée à notre premier patch
git checkout -b my-great-patch master
3) Coder le patch… et faire autant de commits que l’on souhaite
- pour voir les fichiers modifiés :
git status
- pour vérifier ce qu’on a changé avant de commiter :
git diff
- pour commiter :
git commit -a -m "Description du commit."
4) Générer le patch
git diff master >my-great-patch.diff
5) L’envoyer aux développeurs
6) Supprimer la branche
Si le patch est intégré au code source officiel du projet, vous pouvez alors supprimer la branche :
git checkout master git branch -d my-great-patch
La méthode est au final assez simple et je peux confirmer que les développeurs n’ont aucun souci avec les patchs créés par git ;-).
Autres commandes
Il y a tout de même quelques autres commandes à connaitre :
- Récupérer la dernière version du code source officiel
D’abord mettre à jour la branche master :
git checkout master git svn rebase
Puis mettre à jour la branche sur laquelle vous travaillez :
git checkout my-great-patch git rebase master
Il peut arriver qu’il y ait des conflits à cette étape, mais je n’ai pas d’instructions détaillées à proposer dans ce cas de figure. Git indique lui-même les commandes à taper pour annuler ou continuer la mise à jour.
- Voir les branches existantes et savoir sur laquelle on se trouve
git branch
- Passer d’une branche à une autre
git checkout my-other-great-patch
Notez que si vous avez compilé la branche my-great-patch avant de passer à la branche my-other-great-patch, il faudra probablement faire un « make clean » pour effacer tous les fichiers générés du projet avant de le recompiler (utilisez ccache pour gagner du temps !).
Notez également qu’une pression sur TAB complete tout seul les noms de branche git (sous zsh / Arch Linux). Très pratique :-). Il est également possible de configurer son prompt pour qu’il affiche le nom de la branche courante (je vous laisse chercher comment ; je ne l’ai pas fait).
- Voir le log des révisions svn
git svn log
(C’est totalement indépendant de la branche git courante.)
- Voir le log des commits de la branche courante
git log
Combiner tous les patchs
Si en attendant que vos patchs soient acceptés vous voulez les utiliser en local, il peut être intéressant de créer une branche combinant toutes les autres… À priori le plus simple est d’utiliser « git merge » :
git checkout -b all-my-patches master git merge my-great-patch git merge my-other-great-patch
Voilà pour cette fois. Have fun ;-).
mardi 4 septembre 2012
Comment savoir si systemd est lancé
Vous utilisez Arch Linux et pendant que vous faites des tests, vous aimeriez savoir dans un script de démarrage si votre système a démarré avec systemd ou avec initscripts ?
Facile :
Pour savoir simplement si systemd n’est pas lancé :
Facile :
if systemd-notify --booted ; then
# systemd
else
# pas systemd :-)
fi
Pour savoir simplement si systemd n’est pas lancé :
if ! systemd-notify --booted ; thenÀ noter que ça marche très bien si systemd n’est pas installé et que la commande « systemd-notify » n’existe pas.
# pas systemd
fi
dimanche 29 juillet 2012
Faire marcher une clef wifi rtl8192cu sous Linux 3.4
Ma petite clef wifi ayant parfois des soucis de connexion, j’ai récemment acheté une autre clef disposant d’une véritable antenne, une « Digitus DN-70440 » équipée d’un chip RTL8188CUS et utilisant sous Linux le pilote rtl8192cu.
Le packaging indiquait que la clef fonctionnait sous Linux, chose assez rare pour que je me décide à l’acheter sans faire plus de recherche à son sujet sur le web :-).
Manque de pot, elle ne marchait en fait pas. Impossible de me connecter au réseau wifi WPA. Elle a fonctionné un jour, je ne sais pas pourquoi, mais plus jamais après ça.
Après moultes recherches, il s’avère que la solution la plus simple est d’utiliser le pilote fourni par Realtek à la place de celui de Linux 3.4. Mais celui-ci aurait des soucis de compilation sous Linux 64 bit, et il faut donc utiliser une version modifiée du pilote rtl8192cu.
Sous Arch Linux, il existe un package AUR permettant d’installer facilement ce pilote rtl8192cu. Ce package doit être recompilé et réinstallé à chaque mise à jour du kernel.
Il faut également blacklister le pilote du kernel, en rajoutant la ligne suivante dans le fichier /etc/modprobe.d/blacklist.conf :
Une fois ceci fait, il ne reste plus qu’à rebooter, ou bien à changer de driver « à la main » :
(Ou encore : débrancher la clef, faire le modprobe -r, et rebrancher la clef.)
Depuis que j’ai installé ce nouveau pilote, mon indicateur de signal wifi indique en permanence 100%, et la connexion se fait sans problème au démarrage de l’ordinateur (sous Linux 3.4.6 actuellement). Bon, ça ne fait que deux jours de tests, mais j’ai bon espoir que ça dure ;-).
J’en profite tout de même pour signaler un petit défaut de ce « WIRELESS 150N USB 2.0 ADAPTER » : sa forme arrondie peut bloquer un port USB situé à côté de celui dans lequel on le branche, dans le cas où les prises sont l’une au dessus de l’autre.
Mise à jour du 23 février 2013 : le pilote cité ci-dessus ne fonctionne plus depuis le passage au kernel 3.7. Il faut utiliser cet autre package AUR : dkms-8192cu. Je ne connais pas bien le fonctionnement de dkms, mais j’ai dû taper cette commande pour compiler et installer le pilote : sudo dkms autoinstall.
Le packaging indiquait que la clef fonctionnait sous Linux, chose assez rare pour que je me décide à l’acheter sans faire plus de recherche à son sujet sur le web :-).
Manque de pot, elle ne marchait en fait pas. Impossible de me connecter au réseau wifi WPA. Elle a fonctionné un jour, je ne sais pas pourquoi, mais plus jamais après ça.
Après moultes recherches, il s’avère que la solution la plus simple est d’utiliser le pilote fourni par Realtek à la place de celui de Linux 3.4. Mais celui-ci aurait des soucis de compilation sous Linux 64 bit, et il faut donc utiliser une version modifiée du pilote rtl8192cu.
Sous Arch Linux, il existe un package AUR permettant d’installer facilement ce pilote rtl8192cu. Ce package doit être recompilé et réinstallé à chaque mise à jour du kernel.
Il faut également blacklister le pilote du kernel, en rajoutant la ligne suivante dans le fichier /etc/modprobe.d/blacklist.conf :
blacklist rtl8192cu
Une fois ceci fait, il ne reste plus qu’à rebooter, ou bien à changer de driver « à la main » :
sudo modprobe -r rtl8192cu sudo modprobe 8192cu
(Ou encore : débrancher la clef, faire le modprobe -r, et rebrancher la clef.)
Depuis que j’ai installé ce nouveau pilote, mon indicateur de signal wifi indique en permanence 100%, et la connexion se fait sans problème au démarrage de l’ordinateur (sous Linux 3.4.6 actuellement). Bon, ça ne fait que deux jours de tests, mais j’ai bon espoir que ça dure ;-).
J’en profite tout de même pour signaler un petit défaut de ce « WIRELESS 150N USB 2.0 ADAPTER » : sa forme arrondie peut bloquer un port USB situé à côté de celui dans lequel on le branche, dans le cas où les prises sont l’une au dessus de l’autre.
Mise à jour du 23 février 2013 : le pilote cité ci-dessus ne fonctionne plus depuis le passage au kernel 3.7. Il faut utiliser cet autre package AUR : dkms-8192cu. Je ne connais pas bien le fonctionnement de dkms, mais j’ai dû taper cette commande pour compiler et installer le pilote : sudo dkms autoinstall.
samedi 26 mai 2012
Changer les couleurs de Klavaro
Klavaro est un logiciel libre d’apprentissage de la frappe au clavier que j’ai utilisé pour me mettre au bépo et que je ressors encore de temps en temps pour voir si je tape plus vite qu’avant :).
Par défaut, le texte est affiché en noir sur fond blanc, mais depuis sa version 1.9.4 de janvier 2012, Klavaro permet enfin de modifier les couleurs du texte et de l’arrière-plan, ce qui est fort appréciable quand on utilise un thème sombre comme moi !
Il suffit d’éditer le fichier « preferences.ini » (dans ~/.config/klavaro sous Linux) et d’y rajouter ces lignes :
Par défaut, le texte est affiché en noir sur fond blanc, mais depuis sa version 1.9.4 de janvier 2012, Klavaro permet enfin de modifier les couleurs du texte et de l’arrière-plan, ce qui est fort appréciable quand on utilise un thème sombre comme moi !
Il suffit d’éditer le fichier « preferences.ini » (dans ~/.config/klavaro sous Linux) et d’y rajouter ces lignes :
[colors]Grâce à ça, j’ai pu gagner 5 mots par minute en un jour ! Effet garanti ! ;-)
text_intro_bg=#222222
text_intro_fg=#dddddd
char_untouched_bg=#222222
char_untouched_fg=#dddddd
char_correct_bg=#222222
char_correct_fg=#339933
char_wrong_bg=#222222
char_wrong_fg=#ff0044
char_retouched_bg=#222222
char_retouched_fg=#bb8800
cursor_blink_bg=#666666
cursor_blink_fg=#dddddd
samedi 10 mars 2012
Comment rendre Firefox 10 utilisable
J'avais testé Firefox 4 à sa sortie mais il avait quelques défauts gênants qui m'avaient fait rester avec Firefox 3.6 jusqu'à il y a peu :
Au final, peu de changements par rapport à Firefox 3.6. Ça a l'air d'être un poil plus rapide, mais c'est tout. Aucune amélioration à l'horizon niveau ergonomie.
J'ai évidemment aussi une floppée d'extensions ainsi que quelques réglages spécifiques dans about:config, mais j'en parlerai une autre fois :).
- Les pages flashaient en blanc au début du chargement (très désagréable quand on a un thème sombre).
- Deux de mes addons essentiels ne fonctionnaient plus : CS Lite (gestionnaire de cookies) et un autre que j'ai oublié.
- La disparition de la barre de statut, partiellement remplacée par le désagréable truc blanc qui apparait en retard en bouffant une partie de l'affichage quand on place le pointeur sur un lien.
- Plus de bouton RSS !?
- Les pages ne flashent plus en blanc ! Youpi.
- Un des deux addons a été mis à jour, et j'ai remplacé CS Lite par Cookie Controller. Je ne suis pas très satisfait du remplaçant car les options et menus sont nombreux et peu clairs, mais ça fonctionne... À noter aussi que tous mes cookies semblent avoir été effacés lors de la mise à jour.
- On peut retrouver la barre de statut avec l'extension Status-4-Evar ! Celle-ci a plein de réglages que je vous laisse explorer, qui permettent notamment de supprimer l'horrible "URL Bar" blanche pour afficher les URLs dans la barre de statut comme avant, et de réduire le délai avant qu'elles s'affichent.
- On peut rajouter un bouton RSS dans la toolbar en faisant un clic droit dessus et en sélectionnant "Customize...".
- J'ai également repassé la toolbar en haut de la fenêtre, au dessus des onglets, car sinon elle disparait lorsqu'on est par exemple sur la page des Addons, ce qui empêche de lancer une recherche Web sans d'abord sélectionner un autre onglet.
Au final, peu de changements par rapport à Firefox 3.6. Ça a l'air d'être un poil plus rapide, mais c'est tout. Aucune amélioration à l'horizon niveau ergonomie.
J'ai évidemment aussi une floppée d'extensions ainsi que quelques réglages spécifiques dans about:config, mais j'en parlerai une autre fois :).
Inscription à :
Articles (Atom)