Informatique

Noyau Linux 3.0 et pilotes Realtek 8192e

Monday, 15 August 2011
|
Écrit par
Grégory Soutadé

En retard sur ma mise à jour (comme d'hab), me voici donc avec un noyau Linux 3.0 fraichement installé ! Comme d'habitude il faut recompiler le pilote graphique NVIDIA et le pilote Wifi Realtek (rtl8192e), sauf que le passage à la version 3.0 perturbe les scripts de compilation, même si les structures internes sont sensiblement identiques aux dernières 2.6.xx.

Les modifications à appliquer à HAL/rtl8192/Makefile sont :

  • Changer la vérification de version 2.6 en 3.0
-ifeq ($(shell uname -r|cut -d. -f1,2), 2.6) +ifeq ($(shell uname -r|cut -d. -f1,2), 3.0)
  • Le chemin de include/linux/autoconf.h a changé
-CONFIG_FILE := $(KSRC)/include/linux/autoconf.h +CONFIG_FILE := $(KSRC)/include/generated/autoconf.h
  • Le chemin de include/linux/modversions.h a changé
-CFLAGS += -DMODVERSIONS -DEXPORT_SYMTAB -include $(KSRC)/include/linux/modversions.h +CFLAGS += -DMODVERSIONS -DEXPORT_SYMTAB -include $(KSRC)/include/config/modversions.h
  • Changer la variable CFLAGS par EXTRA_CFLAGS


Le patch complet est disponible ici

Un petit make "clean && make && make install" et on peut de nouveau profiter du Wifi !

Le pilote rtl8192e est dans la branche stagging depuis 1 an et demi (noyau 2.6.32), ça serait bien qu'il intègre enfin la branche stable, on pourrait peut être enfin profiter d'un Wifi correct ...

KissCount 0.2

Saturday, 30 July 2011
|
Écrit par
Grégory Soutadé

La version 0.3 est sortie !

9 mois après la première version stable, voici la version 0.2 de KissCount. Pour rappel KissCount est un logiciel de comptabilité personnelle que j'ai commencé à développer voilà un peu plus de deux ans pour répondre à mes propres besoins : avoir un logiciel simple qui permet de rentrer ses opérations quotidiennes et pouvoir visualiser instantanément l'état du budget, contrairement à la majorité des logiciels sur le marché qui essaient de couvrir les besoins de tous les utilisateurs renforçant ainsi la complexité de l'interface.

Au final 9 mois c'est long pour ce qui a été fait. En réalité beaucoup de modifications ont été faites pour l' "ouverture" du logiciel et ne me concernent pas directement, donc j'ai vraiment dû me pousser pour implémenter tout ça !

Petite capture pour voir la nouvelle tête (à comparer à celle-ci) :

Si ça parait plus joli c'est surtout que j'ai (enfin) activé le moteur de rendu GTK...

Nouvelles fonctionalités

  • Meilleure interface (avec l'utilisation des sizers)
  • Ajout d'ascenseurs (c'est con, mais ça manquait)
  • Statistiques interne au mois
  • Opérations de groupe (Rennomage / changer la catégorie ou le compte)
  • Comptes virtuels et mode réel
  • Paquet Debian
  • Import XML (KissCount), OFX et Grisbi (expérimental)
  • Export XML (KissCount)
  • Mettre à jour les mois suivants
  • Pleins de bugs corrigés (et ajoutés :p)

Comptes virtuels et mode réel

Petite explication : Les comptes virtuels ont été crées pour pouvoir budgétiser une dépense, ce sont des comptes "virtuels" (comme leurs noms l'indique), c'est-à-dire que les transferts vers/depuis ces comptes sont fictifs (ils ne sont pas effectifs au niveau de la banque). Mais les opérations seront prisent en compte dans les statistiques.

Le compte virtuel le plus courant se nomme "Impôts". Je sais qu'à la fin de l'année j'aurais X € à débourser pour M. l'état. En début d'année je "vire" sur ce compte le montant à débourser (ne pas faire l'opération depuis le compte courant ...), qui se retrouve bloqué virtuellement pendant un an.

Naturellement cela "fausse" les valeurs si j'essaie de faire un rapprochement avec ce qu'indique mon relevé de banque. C'est pour ça qu'on peut passer en mode réel, ce qui aura pour effet de ne pas prendre en compte les opérations sur des comptes virtuels (ce que fait déjà le mode rapprochement).

Version Windows

Pour assurer une diffusion plus large de KissCount (pour l'instant 0...), il serait intéressant de réaliser une version pour Windows(tm)(r). En soit il ne s'agit presque que de la mise en place d'un compilateur croisée. Hélas le rendu de l'application est VRAIMENT laid (comme dans la première version), car les sizers ne sont pas pris en compte ...

L'avenir

Désormais je travaille (et j'utilise) la v0.3 du logiciel. La (grande) majorité des fonctionalités ont été implémentées (c'était déjà le cas pour la v0.1), donc sauf nouvelle idée ou correction de bug, il n'évoluera pas beaucoup. Le prochain changement majeur sera le passage à WxWidgets 2.9 et éventuellement une ré écriture du code.


D'autres captures d'écran sont disponibles dans la documentation française et anglaise

Support OVH : FOUTAISES !

Saturday, 30 July 2011
|
Écrit par
Grégory Soutadé

Voilà un an que je suis chez OVH (depuis l'achat du nom de domaine). Le choix d'OVH a été simple : connu, en France, prix attractifs. Bref tout se passait bien : pas de problème, l'interface d'administration est un peu foullie, mais on s'en sort quand même.

Puis vint l'étape du renouvellement (je vais squatter soutade.fr pendant encore au moins un an) :


J'effectue l'étape de renouvellement (nom de domaine + certificat SSL) le lundi 18 juillet. Concernant le certificat SSL, un mail est envoyé sur le serveur, mais il n'y a qu'un nombre limité d'adresses possible (admin, root, postmaster ...) : très pratique quand on n'a pas installé de serveur mail !! Le serveur mail était actif, mais l'utilisateur que j'ai sélectionné dans la précipitation ne l'était pas. Naturellement le mail s'est perdu, bloquant l'avancement de la commande (donc du renouvellement du nom de domaine expirant le lundi suivant) et aucun rappel n'est envoyé.

Je contacte donc le support par mail le mardi 19 au soir. 24h plus tard toujours pas de réponse, je "signale le mail" au manager en précisant que la réponse n'est pas assez rapide.

Jeudi 21 : toujours pas de réponse, je contacte le support technique. On me dit que le support SSL va traiter ma demande et qu'il me recontactera par mail : 7 minutes perdues en numéro surtaxé.

Vendredi 22 : toujours pas de réponse, j'envoie un nouveau message au support technique, je signale l'opération quelques heures plus tard, mais rien n'y fait. Nouvel appel au support technique dans la soirée : "Normalement le nom de domaine devrait être renouvelé, si lundi (date limite) il ne l'est pas, contactez le support commercial" : encore 13 minutes de perdues.

Lundi 25 : évidemment le nom de domaine n'a pas été renouvelé (mais il n'expire que dans la soirée). Je contacte le support commercial (c'est moins cher que pour le support technique). "Votre demande va être signalée au support SSL". 3h plus tard on répond enfin à mes demandes écrites et en une demie-heure l'affaire est réglée : commande validée, nouveau certificat SSL, nom de domaine renouvelé !!


OVH propose un joli graphique http://www.ovh.com/fr/support/ présentant le temps de réponse moyen (entre 2h et 3h), mais c'est de la fumisterie pure et simple ! C'est quand même scandaleux de devoir contacter le support commercial pour que les questions techniques soient prisent en compte. Et comme dans toutes les grandes boîtes : support technique/commercial externalisé, les personnes ne sont là que pour se faire taper dessus mais n'ont quasiment aucune connaissance technique ("- Un renouvellement SSL : ça doit prendre une semaine, peut être plus, peut être moins ..."). Bref on est peut être en période estivale, mais sur ce coup OVH manque cruellement de sérieux. J'espère que ceux qui ont un hébergement sont mieux servis niveau support ! Si ce n'était pas deux fois plus cher j'aurais déjà tout transféré chez Gandi.

Pas de son avec MPlayer sous Debian/e16

Sunday, 19 June 2011
|
Écrit par
Grégory Soutadé

Petit problème avec MPlayer sous Debian et enlightenment (e16). En effet il peut arriver d'avoir l'image, mais pas le son. En réalité c'est parce que le paquet MPlayer de Debian est configuré pour utiliser par défaut le backend audio de PulseAudio, mais si Pulse Audio n'est pas lancé, il n'y aura pas de son.
Pour régler ce problème il faut changer l'ordre de priorité dans le /etc/mplayer/mplayer.conf :

ao=pulse,alsa,sdl:aalib


en

ao=alsa,pulse,sdl:aalib

 

L'autre solution si ça ne fonctionne toujours pas est de sélectionner la carte son interne plutôt que la carte son externe via :

gnome-control-center sound

Problème de compilation avec le nouveau pilote NVIDIA

Sunday, 17 April 2011
|
Écrit par
Grégory Soutadé

En retard (comme d'habitude), j'ai mis à jour hier ma Debian Wheezy (testing). Je vois dans la liste qu'il y a un nouveau noyau (le 2.6.38), donc c'est une mise à jour périlleuse pour les périphériques qui ne sont pas directement supportés par le noyau, à savoir : le pilote rtl8192e pour le Wifi et le pilote NVIDIA GeForce 330M pour la carte graphique.

Généralement tout se passe bien, enfin généralement... Pour le wifi c'était OK (il suffit de recompiler les pilotes), mais pour la carte graphique, le serveur X ne voulait plus se lancer. C'est un problème fréquent, on retourne via l'ancien noyau sur le site de NVIDIA, on télécharge le nouveau pilote et les headers du noyau puis on redémarre pour le compiler.

Comme d'hab il y a la vérification de gcc qui se règle en préfixant la commande par CC="gcc-4.4", mais cette fois-ci la compilation échoue ! On va voir ce qui se passe dans /var/log/nvidia-installer.log :

kernel/nv.c:426: error: unknown field ‘ioctl’ specified in initializer

C'est la première fois que ça arrive. Ni une, ni deux, j'extraie les sources de NVIDIA-Linux-x86_64-256.53.run avec

./NVIDIA-Linux-x86_64-256.53.run -x

j'ouvre le fichier nv.c, tout semble correct. Sauf qu'en fait le champs ioctl de la structure file_operations a été supprimé depuis 6 mois à cause du BKL (Big Kernel Lock). Arf les bougres ! La modification à réaliser n'est pas compliquée :

--- a/NVIDIA-Linux-x86_64-256.53/kernel/nv.c 2011-04-17 10:22:22.861937886 +0200 +++ b/NVIDIA-Linux-x86_64-256.53/kernel/nv.c 2011-04-17 09:08:21.000000000 +0200 @@ -423,9 +423,10 @@ static struct file_operations nv_fops = { .owner = THIS_MODULE, .poll = nv_kern_poll, - .ioctl = nv_kern_ioctl, #if defined(HAVE_UNLOCKED_IOCTL) .unlocked_ioctl = nv_kern_unlocked_ioctl, +#else + .ioctl = nv_kern_ioctl, #endif #if defined(NVCPU_X86_64) && defined(HAVE_COMPAT_IOCTL) .compat_ioctl = nv_kern_compat_ioctl,

On déplace le champs ioctl dans un #else. On recompile et ça tourne ! Même binaire, les pilotes NVIDIA sont de très bonne qualité, c'est bizarre d'avoir laissé une telle erreur. Je viens de leur envoyer un message (dur de trouver un point d'entrée), j'espère que ce sera corrigé dans la prochaine version.