Ma vie rêvée

Ma Logitech Performance MX commençait a fatiguer après seulement 3 ans de service (hors garantie bien sur), clics manquants, clics doubles intempestifs, etc. Je suis partie chercher une remplaçante.

[C'est a priori un problème de conception du pressoir qui fini par se tordre.  Ce qui a tendance a m'agacer sur un matériel de cette gamme de prix.]

Ne jouant plus beaucoup, j'ai laissé de côté les souris gamers et mon choix s'est porté sur la souris sans-fil EssentielB ergo XL vu qu'elle a plein de boutons, est de taille respectable (j'ai des grandes mains) et n'est pas trop chère (~30€).

Evidemment, aucune info sur le support sous GNU/linux mais bon c'est une souris usb, ça devrait aller, hein ?

Ben en fait oui, ça va. Branchement sans difficulté, reconnaissance sans problème par le système, clic droit, gauche, milieu, molette, précédent, suivant, tout ça fonctionne sans difficulté.

Reste les 3 derniers boutons : un à gauche du clic gauche, et 2 sous le pouce en dessous des précédent/suivant.

Pas de soucis, on sort xev pour récupérer la valeur du bouton et là, c'est le drame (en fait non mais c'est pour l'effet) :

keycode 180 (keysym 0x1008ffa9, XF86HomePage)

En fait, les 3 boutons ne sont pas détectés comme boutons de souris mais comme des touches de clavier. Ce qu'on confirme avec xinput :

[jules@tue-amour ~]$ xinput list
⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                  id=4    [slave  pointer  (2)]
⎜   ↳ Compx 2.4G Receiver                         id=9    [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ Power Button                                id=6    [slave  keyboard (3)]
    ↳ Power Button                                id=7    [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard                id=10    [slave  keyboard (3)]
    ↳ Compx 2.4G Receiver                         id=8    [slave  keyboard (3)]
    ↳ Compx 2.4G Receiver                         id=11    [slave  keyboard (3)]

Ici, Compx 2.4G Receiver est la souris, on voit bien qu'elle déclare une souris et 2 claviers (un seul est utilisé en fait).

Pour rappel (et en résumé), le matériel émet un signal pour chaque événement (ex : je clic un bouton), c'est le scancode, celui-ci est traduit par le noyau en un code numérique, le keycode (cf /usr/include/linux/input-event-codes.h ) qui contrairement au premier ne dépend plus du matériel. Le serveur X va ensuite traduire ce keycode en une instruction utilisable par les applications le keysym (cf par ex /usr/xhare/X11/xkb/symbols/inet). Enfin, chaque keysym sera consommé par les applications pour réaliser une action (afficher une lettre, valider une boite, lancer un menu, etc.)

Nos trois boutons ont donc pour keysyms XF86HomePage, XF86AudioRaiseVolume et XF86AudioLowerVolume, ce qui me pose un soucis étant donné que j'ai un clavier multimédia utilisant déjà ces touches là d'une part, et que j'aime bien paramétrer mes boutons de souris de façon précise d'autre part.

Après avoir cherché quelques heures sur le grand nain ternet mondial quelle était la meilleure solution, j'en suis arrivé à la conclusion qu'il me fallait modifier les keycodes émis par le noyau.

L'utilitaire setkeycodes que j'utilise pour mon clavier branché en PS/2 ne marche pas avec l'usb. Il faut directement aller expliquer à udev qu'il doit changer ça. La procédure n'est pas très compliquée :

• trouver le scancode, ça se fait avec l'utilitaire evtest (paquet python-evdev sous mageia 6), on lance, on clique et on regarde ce qui s'affiche. Il s'agit de la valeur MSC_SCAN. Chez moi, il s'agissait de 786979, 786665 et 786666 respectivement.
• Créer un fichier .hwdb dans /etc/udev/hwdb.d/ avec les instructions qui vont bien :

  $less /etc/udev/hwdb.d/99-keyboard.hwdb
  evdev:input:b0003v25A7pFA61*
   KEYBOARD_KEY_C00E9=f23
   KEYBOARD_KEY_C00EA=f22
   KEYBOARD_KEY_C0223=f21
  

  La première ligne désigne la souris, b0003 c'est l'usb, v25A7pFA61 le vendor id et product id qu'on obtient via lsusb. Les trois lignes suivantes correspondent aux réattributions des touches, KEYBOARD_KEY_XXXXX est la touche actuelle avec la valeur précédente convertie en hexadécimal et la partie de droite après le signe égal est le nouveau keycode que l'on veut, ici les touches F21 à F23 dont je n'ai pas l'usage.
• Une fois le fichier correctement fait, on lance systemd-hwdb update pour mettre à jour la base de donnée suivit de udevadm trigger pour la prendre en compte. Plus qu'à vérifier avec xev. Si ça ne marche pas, augmentez le niveau de log de udevadm (man udevadm option control) et regarder dans le journal (journactl -f).

Quand on regarde maintenant, les keycodes sont donc différents et de nouveaux keysyms ont été attribués, dans mon cas XF86TouchpadToggle, XF86TouchpadOn, XF86TouchpadOff. Je suis satisfait, n'ayant pas de touchpad sur cette machine.

Maintenant, plus qu'à modifier mon fichier .xbindkeysrc pour prendre en compte ces nouvelles touches et leur attribuer l'action que je veux. Par exemple, pour la touche en bas du pouce, j'aime bien l'utiliser pour recharger un onglet (ctrl+R) :

"xvkbd -xsendevent -text "\Cr""
 m:0x10 + c:200
#Mod2 + XF86TouchpadOn

xbindkeys peut utiliser directement le keycode (ligne 2) ou le keysym (ligne 3), pour avoir la syntaxe, xbindkeys --key est bien pratique. La première ligne est la commande éxécutée lorsque le bouton/touche est pressé, ici, xvkbd qui envoie le signal ctrl+R.

Il est possible de faire plein d'autres choses (cf xdotool ou xte), y compris générer le clic d'un bouton de souris depuis une touche de clavier qui est en fait un bouton de souris reconnue comme un clavier. :D

L'ANSM a mis en ligne il y a quelques temps un site web qui recense les notices et RCP des médicaments commercialisés en France.

Comme ça manquait, j'ai créé deux plugins de recherche pour navigateur qui permettent de l'utiliser directement, l'un pour les spécialités (Doliprane, Advil etc.), l'autre pour les DCI (nom de la molécule, par exemple paracétamol).

Ils sont dispos sur Mycroft et devraient fonctionner dans tout navigateur moderne tel que firefox/chrome/etc. (peut-être pas IE cela dit).

Presque une dizaine d'année plus tard, c'est finalement assez simple. Install de wine, et wine Warcraft3.exe

voilà

Trouvé sur le planet de KDE, une page écrit Par Adrian de Groot et qui compare les licences un peu dans la même veine que mon tableau (cf colonne de gauche) sauf qu'il le fait nettement mieux que moi et est beaucoup plus complet.

Le lien : http://www.bionicmutton.org/ade/licenses/

Pour ceux que l'anglais rebute voici une traduction rapide des différentes items utilisés :

• fs : licence de logiciel libre ou non
• src : accès au code source quelle que soit la forme de distribution utilisée (source ou binaire)
• C inversé : les versions modifiées du logiciel doivent être distribuées sous la même licence
• C inversé avec flèche : un logiciel utilisant les fonctionnalités de celui couvert par la licence doit être lui aussi couvert par cette même licence
• sigle réseau --l- : si le logiciel est utilisé depuis le réseau, le code source doit être accessible
• téléphone : embarquer le logiciel impose des obligations (cette ligne permet d'éviter qu'un logiciel libre embarqué ne puisse être modifié par l'utilisateur via par exemple une interdiction de démarrer si le logiciel n'est pas signé par l'éditeur)
• patent : la licence inclus une autorisation d'utilisation de brevets logiciels. Les termes précis sont à lire attentivement dans la licence
• /!\ : la licence contient des termes peu courants ou étranges (encore plus que d'habitude) et auxquels il faut faire attention

Ça commence à devenir une habitude mais je change de distribution une fois par an à l'occasion de la sortie des versions spring de mandriva. Cette année, c'était donc la version 2009.1 et ma foi, c'est un très bon cru. Petit résumé.

Installation

Quand on ne fait pas l'idiot et qu'on vérifie les médias d'installation, ça marche plutôt bien. J'avais initialement prévu d'utiliser le DVD free pour faire une mise à jour mais mon DVD était un peu corrompu et je me suis retrouvé avec des erreurs sur quelques paquets mineurs comme dash-static, le noyau et mkinitrd, ce qui m'a posé quelques problèmes.

Au final, j'ai téléchargé et gravé le CD dual-arch depuis la machine de mon épouse et j'ai effacé ma partition / ce qui m'a pris quelques minutes.

Comme toujours depuis quelques années, mon matériel a été directement reconnu et configuré sans aucun problème et sans option particulière.

J'ai ensuite monté l'iso de mon DVD en loopback pour installer une partie de ce que j'avais besoin. Tout ça a été plié en moins d'une heure.

Configuration

Pas grand chose à dire, j'ai une sblive et pas de gros besoins donc j'ai encore désactivé pulseaudio, il suffit de cocher une case à l'installation et c'est fait.

Tout le reste a été parfaitement détecté et configuré, à l'exception de mon bi-écran étant donné que le pilote nv ne le gère pas. J'aurais pu utiliser Nouveau prépackagé mais j'ai préféré l'installer par moi-même par la suite.

Xfce 4.6 s'est installé comme un charme, il faut juste penser à supprimer la conf dans le dossier personnel sinon ça donne de drôle de résultat.

Conclusion

Cette version est presque ennuyeuse tellement il n'y a aucun défi à l'installer ou à la configurer. A recommander sans état d'âme.

Depuis quelques semaines, le support des codecs realvideo 3.0 et 4.0 ( http://fr.wikipedia.org/wiki/RealVideo ) a été complété et activé dans ffmpeg et donc dans tous les lecteurs qui l'utilisent (donc mplayer). Il n'est donc plus nécessaire d'utiliser les codecs binaires de chez Real. Encore un maillon propriétaire de moins sur mon système :).

Mon fils a un RGO, le médecin lui a donc prescrit de l'oméprazole (Mopral*) et il faut donc trouver le moyen de lui faire ingurgiter. Voilà quelques conseils.

Il est assez fréquent de rencontrer sur les forums de discussion des intervenants s'étonnant de la quantité affolante de mémoire consommée par leur système tournant sous Linux.

La plupart du temps, cet étonnement vient d'une méconnaissance de la gestion de la mémoire par ledit système. Je vais donc tenter, assez grossièrement, d'expliquer comment ça marche. Il faut comprendre que de la mémoire inutilisé est de la mémoire inutile. C'est à dire que tant qu'il peut (c'est à dire tant qu'une application n'en a pas besoin), le système va essayer d'utiliser la mémoire pour faire quelque chose d'utile (un cache disque par exemple). Une partie de la mémoire est consommée mais reste disponible dès qu'un programme en a besoin.
Certains outils (comme top) vont par défaut afficher la mémoire consommée et par les applications et par le système, d'où l'étonnement ci-dessus.

Prenons, un exemple pour bien comprendre. Au moment où j'écris, J'ai sur ma machine 2Go de RAM physique et quelques programmes ouverts.

Voici le résultat de top :

Mem:   1997536k total,  1624688k used,   372848k free,   245772k buffers
Swap:   843372k total,        0k used,   843372k free,   501948k cached

D'après lui, 1,6Go de mémoire est occupé (arrgh), 350Mo est libre, 250Mo est dans les tampons et 500Mo est de la mémoire cache (je passe sous silence le swap qui n'est pas utilisé).

Si on fait la somme de ses valeurs, on arrive à bien plus que 2Go, ce qui est normal puisqu'en réalité, les tampons et les caches sont à déduire de la mémoire utilisée. Ce que fait automatiquement l'outil free :

             total       used       free     shared    buffers     cached
Mem:          1950       1586        364          0        240        490
-/+ buffers/cache:        856       1094

cette fois-ci la mémoire consommée est redescendue à 856Mo. Ce qui est déjà plus raisonnable mais quand même toujours important.

En réalité, la mémoire réellement consommée par les programmes n'est pas si importante. L'outil free ne prend pas en compte tous les caches existant et en particulier ceux se trouvant en espace noyau.

Pour cela, on peut utiliser l'outil slabtop (classé par consommation mémoire) :

 Active / Total Objects (% used)    : 1179886 / 1181585 (99.9%)
 Active / Total Slabs (% used)      : 131149 / 131149 (100.0%)
 Active / Total Caches (% used)     : 57 / 66 (86.4%)
 Active / Total Size (% used)       : 496560.55K / 496815.30K (99.9%)
 Minimum / Average / Maximum Object : 0.01K / 0.42K / 4.00K

 OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   

480555 480537  99%    0.75K  96111        5    384444K ext3_inode_cache
505153 505145  99%    0.20K  26587       19    106348K dentry
18669  18666  99%    0.55K   2667        7     10668K radix_tree_node
190051  90009  99%    0.10K   2309       39      9236K buffer_head
3105   3100  99%    0.77K    621        5      2484K shmem_inode_cache
37376  37282  99%    0.06K    584       64      2336K kmalloc-64
3794   3791  99%    0.55K    542        7      2168K inode_cache
7728   7703  99%    0.17K    336       23      1344K vm_area_struct
 916    912  99%    1.00K    229        4       916K kmalloc-1024
1326   1319  99%    0.59K    221        6       884K proc_inode_cache
0965  10965 100%    0.08K    215       51       860K sysfs_dir_cache
4389   4346  99%    0.19K    209       21       836K kmalloc-192
 368    344  93%    2.00K     92        4       736K kmalloc-2048
 172    167  97%    1.97K     43        4       344K task_struct
  96     93  96%    2.06K     32        3       256K sighand_cache
 286    275  96%    0.69K     26       11       208K sock_inode_cache

Ainsi, on voit que le cache des inodes (les références vers les fichiers) fait 384Mo, celui des noms de dossiers (dentry) fait 100Mo.

Il suffit alors de soustraire ces 2 valeurs pour arriver à quelques choses de plus réaliste en terme de mémoire occupée, ici autour de 380Mo.
On est bien loin des 1,6 Go initiaux, ouf ;).

Toutes ces données sont également directement disponible dans le fichier /proc/meminfo (regarder notamment la ligne Sreclaimable qui fait le total des caches récupérables dans le noyau)

Voilà, c'est fini pour cette courte explication du mythe de la consommation de mémoire avec Linux. N'hésiter pas à corriger ou compléter en commentaire, je suis loin d'être un expert sur le sujet.

PS : A noter que dans mon cas, mon pilote graphique se réserve une zone mémoire importante en RAM, sans pour autant l'utiliser constamment.
Elle n'en est pas moins considérée occupée par les différents outils et je n'ai pas trouvé comment la mettre en évidence.

Suite à un comportement très bizarre de mon hébergeur (pages persos free.fr), j'ai du me résoudre à déplacer ce blog. La nouvelle adresse est donc http://mjules.littleboboy.net/carnet.
Je vous invite à mettre à jour vos marques-pages et abonnements RSS/atom. Il y a une redirection vers le nouveau site mais il n'y a aucune garantie qu'elle persiste dans le temps :).

En attendant, un grand merci à mon nouvel hébergeur qui m'a gentiment fait une place ici :).