AzBlog

Aller au contenu | Aller au menu | Aller à la recherche

Informatique

Fil des billets

dimanche, octobre 7 2007

qjoypad, ubuntu gutsy et occupation CPU à 100%

UPDATE 03/2009: Take a look at http://rejoystick.sourceforge.net/ ! :)

QJoypad est un utilitaire extra qui permet de mapper les touches d'un joypad en évènements clavier ou souris. C'est un équivalent à joy2key, sauf qu'il permet de configurer les touches de manière graphique, et qu'il s'applique à toutes les fenêtres X (et non une seule sélectionnée au préalable comme joy2key)
Je m'en sers pour programmer mon Saitek Pro Gamer Command Unit et ainsi émuler des actions claviers sous World of warcraft.
L'installation sous feisty était relativement simple:

  • Récupération du package rpm sur le site de l'auteur
  • debianisation du package à l'aide de alien


Mais voila, depuis mon passage en gutsy, qjoypad me mange 100% du cpu, paralysant ainsi le système. N'écoutant donc que mon courage, je me suis lancé dans le déboguage à grand coups de /* */ pour isoler la partie cpuvore.
Résultat: la modification d'une ligne usleep(1) en usleep(10000), qjoypad ne mange plus de cpu et reste toujours aussi réactif aux évènements du joypad

--- loop.cpp.orig       2007-10-07 13:32:01.000000000 +0200
+++ loop.cpp    2007-10-07 12:16:13.000000000 +0200
@@ -31,7 +31,7 @@
 
        //sleep for a moment. This is just to keep us from throwing all the
        //available processer power into madly checking for new events.
-       usleep(1);
+       usleep(10000);
 
        //now we can let QT process all of its events, like GUI events and timers.
        return QEventLoop::processEvents(AllEvents);


J'en ai profité également pour découvrir checkinstall, un petit programme permettant de créer un package de manière simple: on prépare les sources comme d'habitude et on invoque checkinstall au moment du make install

Le résultat se trouve ici: qjoypad_3.4.2-1_i386.deb

dimanche, septembre 9 2007

bug ? non, feature :)

ou comment résoudre un problème en exploitant un bug.

Cela se passe sur Ubuntu Gutsy: à chaque lancement, je me retrouvais avec une session X reconfigurée automatiquement en vesa (le mode failsafe), au lieu de ma session utilisant les derniers drivers nvidia_new. Le dmesg était très clair:

Sep 9 01:06:47 tonio-pc kernel: [ 18.952000] NVRM: loading NVIDIA Linux x86 Kernel Module 1.0-7185 Mon Apr 2 18:29:54 PDT 2007

C'est une des versions du driver fournie par le paquet linux-restricted, mais bien sur pas la bonne version de nvidia_new (100.14.11)

En cherchant sur le launchpad, je tombe sur ça: DISABLED_MODULES="nv" doesn't stop nvidia_new.ko from loading

En clair, en ajoutant nv dans le fichier indiqué, aucun driver nvidia ne devrait se lancer (cela évite de gêner un driver installé manuellement). Seulement le script ne bloque que les modules nvidia et nvidia_legacy, et laisse donc nvidia_new se charger tranquillement.

Évidemment, le problème va se reproduire si ce bug est corrigé, et donc il vaut mieux chercher un peu plus. En attendant, ça m'évite quand même tout un tas de commandes shell pour lancer mon pc (déchargement/rechargement de gdm et du module nvidia)

Update du 7/10/07: le bug est corrigé, j'ai donc du refaire des recherches sur ce comportement problématique. j'ai trouvé ça https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/136838 avec quelques solutions en bas de page. A essayer donc.