On se tutoie ?

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

Mot-clé - planet-libre

Fil des billets - Fil des commentaires

mardi, mai 26 2009

Utiliser plusieurs claviers avec des mapping différents sous X.org

Les deux techniques présentées sont différentes selon la version de X.org utilisée.
Les versions de X.org >= 1.5 supportent l'hotplugging, en passant par HAL ; les versions précédentes non.

Pour connaître sa version de X:

X -version

Avec HAL

Pour lister les périphériques détectés par HAL:

lshal

Copie le fichier /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi dans /etc/hal/fdi/policy/.

Voici mon fichier une fois modifié:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keymap">
      <append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
    </match>
 
    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.rules" type="string">base</merge>
 
      <merge key="input.xkb.model" type="string">keyboard</merge>
      <match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
             string="Linux">
        <merge key="input.xkb.model" type="string">evdev</merge>
      </match>
 
      <match key="info.product" string="TypeMatrix.com USB Keyboard">
              <merge key="input.xkb.variant" type="string">bepo</merge>
      </match>
      <match key="info.product" string="USB Multimedia Keyboard">
              <merge key="input.xkb.variant" type="string">latin9</merge>
      </match>
 
      <merge key="input.xkb.layout" type="string">fr</merge>
    </match>
  </device>
</deviceinfo>

La partie:

<match key="info.product" string="TypeMatrix.com USB Keyboard">
    <merge key="input.xkb.variant" type="string">bepo</merge>
</match>

spécifie que pour mon clavier TypeMatrix je souhaite une variante bépo.
Pour l'autre j'utilise du latin9.

Pour configurer ton fichier il faut reprendre les informations issues de lshal.
Les claviers sont repérables par leur info.capabilities qui contiennent 'input.keyboard'.

Une fois repérés il reste à récupérer la chaîne info.product (TypeMatrix.com USB Keyboard et USB Multimedia Keyboard dans mon cas) et configurer le fichier /etc/hal/fdi/policy/10-keymap.fdi avec.

Sans HAL:

Pour lister uniquement les périphériques d'entrée (souris, clavier, joystick...):

xinput list --short

On récupère l'identifiant du device qui nous intéresse et, par exemple:

setxkbmap -device 0 fr bepo
setxkbmap -device 1 fr latin9

L'inconvénient c'est que le changement n'est pas persistant lors de chaque redémarrage.

mardi, avril 28 2009

Clavier Typematrix et skin bépo.

J'ai reçu vendredi dernier mon clavier Typematrix que j'avais commandé avec la commande groupée sur clavier-dvorak.org.

À propos de l'installation

Sous Archlinux, la distribution que j'utilise, il suffit d'être à jour, X.org contient déjà la disposition bépo. Un petit setxkbmap fr bepo suffit. Sous OSX, il faut installer le layout qui va bien.

À propos du clavier

Mes pré-requis dans le choix du clavier était d'avoir un clavier assez compact, sans pavé numérique, avec un placement des touches en colonnes.

Voilà un peu la tête du monstre, je l'ai pris en dvorak-us de base:

typematrix-dvorak

Avec une skin bépo noire:

typematrix-bepo

Initialement on devait le reçevoir fin février mais il y a eu quelques complications, notamment dans la fabrication des skins. Malgré tout nous avons toujours été tenu au courant de l'avancé de la commande.

En terme de dimensions ce clavier est très fin et peu large ; il fait environ 1cm d'épaisseur pour une largeur égale à celle d'un portable 13"3.

Ce n'est pas un clavier sans fil mais usb ce qui, je trouve, est plutôt un avantage. Fini les contraintes de piles.
Et puis à moyen terme c'est typiquement le type de clavier que l'on peut emporter avec soit si on est amené à travailler sur un ordinateur autre que le sien.

À l'usage

Ce clavier est vraiment très confortable, et très silencieux. La frappe s'apparente à une frappe sur les claviers d'ordinateurs portables. La skin donne un aspect peau de pêche au toucher ; on aime ou pas.
Typematrix fabrique aussi des skins vierges, la classe quand on connaît son clavier par coeur :-).
D'ailleurs il y a une nouvelle commande groupée pour l'achat de skins.

Le premier avantage qui saute aux yeux à la main c'est que la souris est beaucoup plus accessible, grâce aux faibles dimensions du clavier.

Mais le plus gros changement est l'alignement des touches en colonnes. Je ne sais pas si c'est parce que je change de disposition en même temps ou non mais je trouve qu'on s'y habitue très vite (et on n'a pas envie de revenir en arrière).

Ça limite énormément les fautes de frappes, car ça donne l'impression que la touche que l'on cherche « tombe » sous le doigt.

Ca peut paraître anodin mais ça change beaucoup de choses par rapport au positionnement des doigts.
Chacun des 8 doigts positionné (les 2 pouces se trouve sur la barre espace) a facilement accès à sa touche, la touche du dessus et celle du dessous alors qu'en azerty on a potentiellement deux touches en dessous et deux touches au dessus du fait du non-alignement.
Du coup chaque doigt a ses touches bien définies et ne risque pas de faire des km inutiles.

À propos du mapping

    J'avais depuis longtemps en tête de changer de disposition mais je voulais que ça s'accompagne d'un changement de clavier physique pour ne passer céder à la tentation de revenir en arrière.
Pour être honnête, c'est difficile de changer de mapping du jour au lendemain. Je suis passé d'un peu plus de 300 caractères minutes à ~50-60…laisse moi te dire qu'une lettre par seconde c'est très lent.

Concernant mon choix de disposition je souhaitais trouver le meilleur compromis entre une disposition facilitant le développement et une disposition facilitant l'écriture en français. J'ai éliminé d'emblée le qwerty qui ne possède pas les accents de façon native et je ne trouvais pas pratique d'avoir les chiffres en accès direct.
L'azerty n'étant vraiment pas réputé pour la disposition judicieuse de ses touches il restait le dvorak-fr et le bépo.

Finalement j'ai chosi la disposition bépo car elle me semble la plus logique et la plus productive.
En effet le bépo n'utilise pas de touche morte, contrairement au dvorak-fr.
De plus le placement des signes me semble plein de bon sens ; par exemple on a toutes les opérandes mathématiques à la suite les unes des autres (+-/*=%), les deux parenthèses sont elles aussi côte à cote avec les crochets en alt.

Pour le développement le $@,. et () sont en accès direct, mais pas les {}, et |.

L'apprentissage

Passer d'un azerty à touches non alignées à un bépo en touches en colonnes est assez…frustrant quand on commence à taper.

La disposition des touches en elle même va très vite à apprendre, du fait qu'on peut facilement « déduire » le placement des touches.

Grosso modo, et à quelques exceptions prêt on a d'un côté les voyelles et la ponctuation (à gauche) et de l'autre les consonnes.

Mais c'est là qu'on se rend compte que ce n'est pas le fait de connaître l'emplacement des touches qui nous rend rapide mais les automatismes que l'on a acquis.

Je ne connais pas la disposition azerty par coeur, même si je pense que je serais capable de la retrouver, alors que je connais déjà celle du bépo après seulement quelques jours.
Pourtant je suis, pour le moment, plus rapide en azerty.

J'ai décidé d'essayer d'apprendre de la meilleure des manières, c'est à dire en ne regardant pas le clavier et plaçant correctement mes dix doigts, ce que je n'ai jamais fait en azerty.

Je me suis fait un petit papier en dessous de l'écran mais une fois la disposition apprise ce n'est pas très utile.

À l'usage on se rend compte que les mains ne bougent quasiment pas. Une fois l'index gauche calé sur l'ergot de la touche 'e' et l'index droit sur celui de la touche 't' on a facilement accès à tout (excepté le w sur le typematrix, saleté d'auriculaire trop court :-)).

La deuxième impression que l'on a en tapant est un sentiment de frustration.
Savoir où sont les touches et avoir quelquechose à taper en étant désespérement lent c'est réellement frustrant.
J'essaie d'utiliser le clavier au maximum pour m'y accoutumer mais en terme de productivité il m'est impossible de l'utiliser toute la journée sinon mes clients risquent de me taper dessus :-).

Les avantages

  • Les touches shift sont grandes et de même taille de chaque côté du clavier. Sur mon azerty je n'utilisais que le shift de gauche, pas pratique quand on veut mettre en majuscule une lettre juste à côté de ce shift.
  • Les touches backspace et suppr n'ont pas le même comportement, la touche backspace supprime le contenu précédant le curseur et la touche suppr celui suivant le curseur.
  • Ces deux touches, en plus de la touche entrée, sont au milieu du clavier et peuvent donc être atteintes indifféremment par la main gauche ou droite.
  • Plus besoin de combinaisons à trois doigts pour faire des caractères accentués majuscules (ÀÉÈÇ), qui ont leur place dans la langue de molière.
  • Avec la disposition bépo j'ai l'impression que les mains gauches et droites travaillent beaucoup plus à tour de rôle, lettre par lettre, tandis qu'en azerty il me semble que les mains s'alternent par séquences.

Les inconvénients

  • Le principal que j'ai relevé pour le moment c'est la difficulté d'accès au 'w'. Un peu dommage car le 'w' est utile pour fermer des fenêtres notamment. En azerty le C-w est un raccourci très rapide à exécuter.
  • Quand on positionne bien ses mains je trouve qu'il est facile d'accèder aux touches du dessus mais beaucoup moins à celle du dessous, ça oblige à replier son doigt vers l'intérieur, je ne sais pas si c'est une question d'habitude ou non.
  • Certains touches ne fonctionnent pas sous Mac. Les lanceurs d'applications courriels, calculette, browser ne fonctionnent pas. Plus gênant les très pratiques copier - coller n'ont aucun effet non plus. Le problème c'est qu'elles ne sont même pas reconnues, donc on ne peut pas les utiliser dans des triggers avec Quicksilver par exemple.
  • Il est difficile de s'adapter au fait qu'il y a ait « encore » une ligne en dessous de la ligne espace. Au début on cherche systématiquement la touche ctrl en bas à gauche alors que c'est la touche fn qui s'y trouve. La touche ctrl est juste au dessus.
  • Apprendre une nouvelle disposition demande beaucoup d'efforts, dont on ne peut pas voir l'intérêt à court terme, il est très tentant de se décourager.

Question(s)

Oublie t-on complètement sa disposition précédente quand on apprend une nouvelle ?
Pas du tout, en tout cas pas pour le moment. Je pense que comme pour tout, si on ne pratique pas on risque de perdre ses automatismes mais ce n'est pas l'affaire de quelques heures ni jours.

Conclusion

C'est un vrai challenge de changer de disposition de clavier et j'espère vraiment y arriver.
Je me donne un mois pour ne plus utiliser du tout mon autre clavier et 3 pour atteindre la même vitesse de frappe.
Concernant le clavier je le recommande chaudement, il est vraiment très agréable.

jeudi, janvier 29 2009

Mettre à jour son statut twitter en shell

Je partage mon petit morceau de code pour ceux que ça intéresse:

twitter() {
  local email="you@example.com"
  local length=140
  echo "Enter password:"
  stty -echo
  read password
  stty echo
  echo "Enter status:"
  read status
  if [ ${#status} -le $length ]; then
    echo "Posting..."
    wget --user=$email --password=$password --post-data="status=$status" http://twitter.com/statuses/update.xml > /dev/null 2>&1
  else
    echo "Status is too long, max length is $length, current length is ${#status}."
  fi
} #twitter

La seule petite subtilité c'est le

stty -echo

qui désactive l'affichage de la saisie dans le terminal, et qui évite donc que notre mot de passe s'affiche à l'écran.
Tu n'as plus qu'à modifier ton email :-)

lundi, décembre 8 2008

Adhésion et soutien à l'APRIL et au Téléthon

J'ai toujours trouvé que la donation était un bon système de financement, à la fois non contraignant et juste, dans le sens où chacun peut donner en fonction de ses moyens et au moment où il le souhaite (ou le peut).

Dans ce sens je m'étais toujours promis de donner aux projets qui me tiennent à cœur.

J'aimerai pouvoir me vanter d'y avoir pensé tout seul mais il faut bien dire que c'est le contexte qui m'a poussé à donner, à la fois pour l'APRIL et pour le téléthon.
Pour ceux qui ne connaissent pas, l'APRIL est une association de soutien au logiciel libre.

J'y ai adhéré en tant qu'entreprise.

J'en fais un billet car cela incitera peut être quelqu'un d'autre à faire un don.

vendredi, mai 23 2008

Garder son serveur GNU / Linux à l'heure atomique

Rester dans les temps

C'est une bonne idée de conserver son serveur à l'heure, surtout quand celui ci doit communiquer avec le reste du monde.

Sous GNU / Linux il existe ntpdate qui permet de réajuster l'heure à un moment donné en se basant sur des serveurs de temps.
Ce paquet est pratique pour une utilisation ponctuelle et réfléchie.

Toutefois c'est une mauvaise idée d'utiliser ntpdate dans un cron pour conserver sa machine à l'heure.
En effet les décalages de temps, même minces, risque d'entraîner des perturbations (parfois invisible) au niveau des processus en cours.

Nombreux sont les programmes qui utilisent des timestamp ou se base sur l'horloge système pour planifier d'autres tâches.
Si un programme planifie une tache à n+1 et qu'à la prochaine mise à jour de temps ton serveur passe à n+2, certaines tâches ne seront pas éxécutées.

Le programme dovecot par exemple, s'arrête complètement à chaque mise à jour de temps avec ntpdate.

Utiliser un démon pour garder l'heure à jour

Pour garder sa machine à l'heure il existe un programme qui tourne en tache de fond : ntpd (paquet ntp).
Ntp ne se contente pas de réajuster l'heure avec les risques que cela comprend.
Lorsque le serveur est en retard il accélère l'horloge système afin de rattraper son retard.
Le temps va donc passer plus vite mais sans perte.
À l'inverse il va décélérer l'horloge si la machine est en avance.

Pour l'installer il te suffit d'utiliser ton gestionnaire de paquet favoris, par exemple :

aptitude install ntp

ou d'utiliser le paquet qui va bien sur le site officiel.

Une fois installé le serveur se lance en démon.
J'ai juste changé les serveurs du /etc/ntp.conf de n.debian.pool.ntp.org vers n.fr.pool.ntp.org pour avoir les serveurs de temps les plus proches.

mardi, janvier 22 2008

Utiliser le même ssh-agent entre plusieurs shells.

La problématique : se connecter entre ses différents machines, en ssh et sans mot de passe

Lorsqu'on commence à avoir des machines dans tous les coins on aime pouvoir y accèder facilement, et de partout.

Souvent on se retrouve avec un petit réseau local contenant plusieurs machines partageant un seul point d'accès à internet. C'est à partir de cette IP publique que l'on peut se connecter à son réseau interne de l'extérieur.

Le problème c'est que tant qu'IPv6 ne sera pas établi (et que ou l'on pourra disposer de plusieurs adresses publiques sans sourciller) on en est réduit à une seule adresse et on se retrouve avec une machine qui sert de passerelle pour rebondir dans son réseau interne.

Machine externe -> Passerelle -> Machine interne

Une solution basique : un jeu de clés privée / publique

Imaginons que l'on souhaite se connecter depuis la passerelle sur la machine interne. On va générer un jeu de clé :

$ ssh-keygen -t dsa

On peut utiliser le fichier par défaut, par contre il faut mettre une passphrase. Une fois notre paire de clés générée on va copier notre clé publique sur la machine sur laquelle on souhaite se connecter :

$ ssh-copy-id -i ~/.ssh/key.pub login@interne

Cela aura pour effet d'aller copier notre clé publique dans le fichier authorized_keys de la machine interne. Dès lors quand on voudra se connecter sur la machine interne depuis la passerelle c'est la passphrase qui sera demandée.

À ce niveau on peut penser avoir juste déplacé le problème : toujours un mot de passe à taper.

Toutefois, pour ne pas avoir à retaper sa passphrase à chaque connexion on peut utiliser ssh-agent.
Pour cela on rattache ssh-agent à un processus sur la passerelle, par exemple ssh-agent /bin/bash.

Cela aura pour effet de lancer un nouveau shell auquel sera rattaché l'agent.
Ensuite on peut rajouter les clés privées à gérer par notre agent : ssh-add ~/.ssh/id_dsa.

ssh-add va nous demander la passphrase, une fois entrée c'est lui qui interceptera les demandes de passphrases de ssh.

Dès lors je peux me connecter de ma passerelle vers ma machine interne sans mot de passe.

Aller un peu plus loin : utiliser le même agent pour faciliter les rebonds ssh

Soit, mais si je connecte depuis la machine externe vers la passerelle, et que depuis la passerelle je souhaite rouvrir une connexion vers la machine interne ma passphrase sera re-demandée.

Pourquoi ? Parce que notre agent est associé à notre shell (ssh-agent /bin/bash). En dehors de ce shell le problème est le même.

Si on y regarde de plus près, comment cela fonctionne t-il vraiment ?

Au lancement du ssh-agent une socket est créée dans le /tmp, du genre /tmp/ssh-xxxpiddushell/agent.piddushell
En fait le ssh-agent est un processus fils du shell nouvellement créé. En plus de ça notre commande génére plusieurs variables d'environnements qui ne sont accessibles qu'à l'intérieur du nouveau shell.

Regardons ça de plus près :

$ env | grep -i ssh

Deux variables nous intéressent :

SSH_AGENT_PID=22659
SSH_AUTH_SOCK=/tmp/ssh-WgkOE22658/agent.22658

Récupérer l'environnement de notre agent, et l'exporter dans le nouveau shell

On le voit ces informations sont facilement accessibles. Partant de là si on se connecte depuis la machine externe vers la passerelle et que l'on fait un export de ces variables dans le nouveau shell alloué lors de notre connexion ssh on peut parfaitement se reconnecter sur la machine interne sans taper de mot de passe :

$ export SSH_AGENT_PID=22659
$ export SSH_AUTH_SOCK=/tmp/ssh-WgkOE22658/agent.22658
$ ssh interne

L'idée c'est d'alouer automatiquement ces variables, en réalisant l'export ... dans notre .bashrc
En fait il y a deux façons de faire : soit on force le nom de la socket, avec un ssh-agent -a, soit on récupère les informations dynamiquement.

Je penche pour la deuxième qui m'évite de penser à passer cette option lorsque que je lance mon agent (et oui, geek == fainéant). En plus il faudra toujours récupérer l'id du pid.

Pour ça deux commandes à mettre dans le .bashrc :

export SSH_AGENT_PID=$(ps aux | grep -v 'grep' | grep ssh-agent | grep $(env | grep "USER" | sed s/USER=// | head -n 1) | head -n 1 | awk '{print $2}')

if [ "" != "$SSH_AGENT_PID" ]; then
  export SSH_AUTH_SOCK=$(find /tmp -iname "agent.$(ps -p $SSH_AGENT_PID -o ppid=)")
fi

Explications :


  • ps aux liste les processus
  • grep -v fait une recherche inverse c'est à dire qu'il exclut les résultats demandés. En l'occurence je demande à grep de s'exclure lui même, sinon la commande apparait dans la liste des résultats
  • grep ssh-agent fait ce qu'on lui demande, il recherche les lignes qui matchent.
  • grep $(env | grep "USER" | sed s/USER=// | head -n 1) fait un grep sur le nom de l'utilisateur. En effet il peut y avoir plusieurs agents sur la machine, appartenant à des utilisateurs différents.
  • head -n 1 renvoie la première ligne uniquement
  • awk '{print $2}' permet de splitter la ligne selon les espaces ou tabulations. Ici on renvoie le deuxième bloc qui contient le pid. On pourrait aussi utiliser cut.
if [ "" != "$SSH_AGENT_PID" ]; then
        export SSH_AUTH_SOCK=$(find /tmp -iname "agent.$(ps -p $SSH_AGENT_PID -o ppid=)")
fi

Explications :

Cette commande recherche la socket correspond à ce ssh-agent s'il existe (présence du pid).
La socket est nommée dans un format spécial : agent.pidduparentdel'agent ; il nous faut donc récupérer le pid parent du pid de l'agent, celui du shell donc.
C'est ce que réalise cette commande : ps -p $SSH_AGENT_PID -o ppid=

Ensuite c'est un find tout bête qui nous renvoie le full path de la socket.

Une fois ces commandes dans votre .bashrc c'est fini, lors de la connexion de externe vers passerelle, un shell est alloué, le bashrc sourcé et les variables d'environnements disponibles, on peut donc se connecter à la machine interne sans soucis.

Bien sûr pour faciliter le tout on peut utiliser un jeu de clés entre la machine externe et la passerelle.

Une pincée de sécurité en plus : empêcher les connexions ssh par mot de passe

Une fois tout ça en place pourquoi ne pas désactiver l'authentification par password ? Dans le fichier /etc/ssh/sshd_config :

PasswordAuthentication no

et au passage :

PermitRootLogin no

Ainsi on est sûr que seules les machines dont la clé publique se trouve sur la machine hôte pourront se connecter.
Toutefois il vaut mieux avoir au moins 3 machines pour utiliser ce système, ou conserver ses clés en lieu sûr, sinon au premier plantage votre machine distante devient inaccessible.
Dommage quand on n'a pas d'accès physique à celle-ci ...

jeudi, janvier 10 2008

Nouveau logo pour Archlinux

Suite au concours, le gagnant du concours a été désigné par un système de votes.

La simplicité du design colle bien à la philosophie de la distribution à mon goût. L'autre logo The minimalist était lui aussi très abouti.

Y a pu qu'à intégrer tout ça comme on dit.

lundi, novembre 26 2007

Driver nvidia et kernel 2.6.23

En possession d'une carte graphique nvidia GeForce 7300 GS, je suis confronté aux bugs des drivers propriétaires NVIDIA depuis un moment.
Le dernier driver fonctionnel en date est le 1.0-9755 pour ma carte, les autres faisant systématiquement freezer mon système ; rien que ça.

A chaque changement de noyau, le package nvidia est mis à jour dans la foulée, afin d'éviter aux utilisateurs d'avoir à recompiler leur driver manuellement.
De mon côté j'essaie donc toujours le nouveau driver quelques temps avant de m'apercevoir qu'il me fait toujours freezer.

Mais ce n'est d'habitude pas très gênant puisque j'ai gardé une copie du driver 9755, que je recompile à la mano et ça roule. Normalement.
Sauf qu'en 2.6.23 l'API du kernel a changé, et n'est plus compatible avec les anciens drivers, impossible donc de le recompiler.

Heureusement une bonne âme a patché ce driver afin de faire correspondre les prototype des fonctions du driver avec ceux du kernel.
Tu peux rebuilder les packages si tu n'as pas confiance sinon prends les deux tarball et installe les.

Sous Arch c'est trivial :

# pacman -U nvidia-100.14.09-1-i686.pkg.tar.gz
# pacman -U nvidia-utils-100.14.09-1-i686.pkg.tar.gz

Une fois les deux drivers installés tu n'es pas forcément encore au bout de tes peines. De mon côté j'ai viré l'ancien driver nvidia et recharger le nouveau :

# depmod -a 

Pour vérifier les dépendances des modules du noyau.

# modprobe -r nvidia

Pour virer l'ancien driver nvidia.

# modprobe nvidia

Pour charger le nouveau.

Ensuite j'ai tenté un startx en user, mais ça ne fonctionnait pas, j'ai eu droit à un message de la sorte : "The xorg server ABI is newer than the driver version and so X will not open."

Comme suggéré plus loin dans le message j'ai donc tenté de lancer mon serveur X sans cette option :

$ startx -- -ignoreABI

Ça fonctionne mais les plantages reviennent. J'ai donc décidé de downgrader mon serveur X.
Du package xorg-server 1.4-4 (dans le dépôt extra) je suis passé au 1.2.0-5 (dans le dépôt current).

Avant que cela ne fonctionne pour de bon, j'ai aussi downgradé les packages xf86-input-keyboard en version 1.1.1 et xf86-input-mouse en 1.2.1.

Dorénavant ça fonctionne mais plus question d'utiliser le module glx, qui est indispensable pour compiz entre autre. J'essaierai de chercher pourquoi plus tard car l'exposé me manque déjà :-)

Pour éviter de trembler à chaque mise à jour, j'ai décidé d'arrêter de mettre à jour mon X et les drivers nvidia empaquetés, au moins pendant quelques temps.
Pour ce faire sous Arch, il faut ajouter la variable IgnorePkg dans le pacman.conf de la sorte :
IgnorePkg = nvidia nvidia-utils xorg-server

En espérant que ce billet permette à quelqu'un de perdre moins de temps que moi à résoudre ce désagrément.

jeudi, septembre 27 2007

Fetcher son gmail

Comme je n'aime ni l'interface web de gmail, ni le fait d'avoir 15 boîtes à fetcher, j'ai décidé de configurer mon gmail dans mon .fetchmailrc. La seule “difficulté” c'est que gmail n'autorise que les connexions SSL.

Plutôt que de paraphraser voilà un lien vers un HOWTO.

jeudi, mai 10 2007

Remote sous linux : beucoup de lirc et un peu de magie

Tombé du lit vers 4h30 ce matin, je me suis demandé à quoi j'allais bien pouvoir m'attaquer avant de me souvenir qu'il restait une chose que je n'avais pas configuré depuis ma migration de kubuntu vers arch : ma télécommande.

Configuration :

  • Arch Linux 0.8 (Voodoo)
  • Noyau : 2.6.21-ARCH
  • Alsa : version 1.0.14rc2
  • Lirc : 0.8.1-6

La télécommande est, comme toute chose inutile, indispensable.

Côté matériel j'utilise donc la télécommande livrée en standard avec ma carte son Audigy platinum 2 zs pro, qui à l'époque valait son pesant d'or.

Il y a en fait deux sources d'événements différents : le hub qui possède 3 boutons en façades et la télécommande en elle même qui en possède 33.
Le fonctionnement de cette télécommande est 'simple'. Lorque que vous appuyez sur un bouton, un signal est envoyé au hub qui le transfère à la carte son par une interface midi.
Dans un premier temps il faut vérifier la présence de cette interface midi, qui a été créée par alsa si celui ci a été installé.

$ ls -l /dev/snd/ | grep midi

  • crw-rw 1 root audio 116, 8 mai 10 2007 midiC0D0
  • crw-rw 1 root audio 116, 9 mai 10 2007 midiC0D1
  • crw-rw 1 root audio 116, 10 mai 10 2007 midiC0D2
  • crw-rw 1 root audio 116, 11 mai 10 2007 midiC0D3

L'interface midi est donc bien présente. Le C0 désigne la carte son 0 et le port midi qui nous intéresse est le 1. Puisque tout est en ordre, on commence donc par installer lirc qui permet de décoder les signaux infrarouges de la plupart des télécommandes.

Sous arch, lirc se trouve dans le dépôt extra, qu'il faudra donc activer si ce n'est pas encore le cas (dans /etc/pacman.conf). Si vous ne souhaitez pas activer ce dépôt, vous pouvez compiler lirc à la main, ce qui vous permettra entre autres de choisir le driver dont vous avez besoin (livedrive_midi) pendant la phase de configuration, évitant ainsi l'ajout de tous les drivers inutiles.

  1. pacman -S lirc lirc-utils

Une fois lirc installé, nous allons le configurer par le biais du fichier /etc/conf.d/lircd :

LIRC_DEVICE="/dev/snd/midiC0D1"
LIRC_DRIVER="livedrive_midi"
LIRC_EXTRAOPTS=""
LIRC_CONFIGFILE=""

Nous avons donc spécifié le device et le driver à utiliser. Avant de se jeter à l'eau et de lancer lircd pour tester il faut noter que certaines personnes doivent lancer une chaine d'initialisation au périphérique midi afin que celui ci soit opérationnel :

$ echo -e '\360\000\040\041\141\000\000\000\177\000\367' > /dev/snd/midiC0D1

Si vous avez besoin de cette chaine, pensez à automatiser le processus car il faudra l'envoyer à chaque redémarrage. Lancons maintenant lircd :

/etc/rc.d/lircd start

Logiquement lircd se lance mais nous prévient qu'il n'a pas trouvé le fichier de configuration /etc/lircd.conf :

lircd: could not open config file '/etc/lircd.conf' lircd: No such file or directory

Ce fichier comportera le binding des événements correspondant à notre remote. En fait il est tout à fait possible de le générer nous même via irrecord :

$ irrecord -d /dev/snd/midiC0D1 -H livedrive_midi /tmp/binding

Mais nous pouvons nous en passer car un fichier fonctionnel pour cette remote existe déjà, autant donc s'en servir. Copier donc le contenu suivant dans /etc/lircd.conf :

begin remote

   name        rm1500
   flags       SPACE_ENC|CONST_LENGTH
   bits        32
   eps         30
   aeps        100
   header      9000 4500
   one         563  1687
   zero        563  562
   gap         108000
   toggle_bit  0
   repeat      9000 2250
   frequency   38000
   duty_cycle  33
   begin codes
       1       0x83228B74
       2       0x83228F70
       3       0x8322906F
       4       0x83228A75
       5       0x8322847B
       6       0x83227887
       7       0x83228976
       8       0x8322837C
       9       0x83227788
       0       0x8322807F
       stop    0x8322857A
       play    0x83227986
       pause   0x83227986
       slow    0x83227D82
       step    0x83227E81
       prev    0x83227F80
       next    0x83227A85
       mute    0x83226E91
       vol-    0x8322639C
       vol+    0x8322629D
       eax     0x83228C73
       options 0x8322827D
       display 0x83227689
       return  0x83228E71
       start   0x83228877
       close   0x83227C83
       up      0x83227B84
       down    0x83228D72
       left    0x83228778
       right   0x8322758A
       ok      0x8322817E
       power   0x8322619e
       cmss    0x8322718e
       record  0x8322738c
   end codes

end remote begin remote

   name        audigy_io_hub
   flags       SPACE_ENC|CONST_LENGTH
   bits        32
   eps         30
   aeps        100
   header      9000 4500
   one         563  1687
   zero        563  562
   gap         108000
   toggle_bit  0
   repeat      9000 2250
   frequency   38000
   duty_cycle  33
   begin codes
       mute    0x80000040
       vol+    0x80008080
       vol-    0x80008082
       cmss    0x80000080
   end codes

end remote

Vous pouvez constater la présence du hub et de la remote. Une fois le fichier pasté, on relance lircd. Si tout s'est bien passé on lance un irw :

$ irw

En appuyant sur les boutons de la remote ou en triturant les boutons du hub vous devriez voir apparraitres des choses du style :

0000000080008080 00 vol+ audigy_io_hub
0000000080008080 01 vol+ audigy_io_hub
0000000080008082 00 vol- audigy_io_hub
0000000080008082 00 vol- audigy_io_hub
0000000083228b74 00 1 rm1500
0000000083228f70 00 2 rm1500
000000008322906f 00 3 rm1500

Magnifique, tout fonctionne au poil. Que faire maintenant de ces signaux ? Grâce à ce fichier de configuration nous allons pouvoir réaliser des actions correspondantes aux différentes touches. Pour cela on se crée un fichier .lircrc dans son home et on le remplit de la sorte, pour la touche display par exemple :

begin

 prog = irexec 
 button = display
 config = /opt/kde/bin/amarok &

end

On le voit c'est irexec qui fait la correspondance entre lirc et les commandes de lancement, seulement irexec n'est pas encore lancé actuellement, alors n'attendons plus, lançons le en démon :

$ irexec -d

Maintenant l'appui sur la touche display devrait lancer amarok. N'oubliez pas de faire un petit script qui s'éxécutera au démarrage et lancera irexec en tâche de fond. Si vous êtes un peu flemmard pour configurer un à un chacun des boutons dans le fichier .lircrc sachez que irkick peut le faire pour vous. Il s'agit d'un soft kde qui vous permet de configurer vos boutons via une IHM.

La part de magie :

Lorsque j'ai voulu installer et que j'ai effectué les opérations que je viens de décrire cela n'a pas fonctionné. D'ailleurs le voyant rouge du hub ne s'allumait même pas lorsque j'appuyais sur un des boutons de la remote. Pourtant tout semblait bien configuré, mais au lancement d'irw aucun des pottards n'avait le moindre effet. J'ai donc commencé à me poser des questions et à sérieusement me demander si le matériel était toujours opérationnel.

Et puis dans un dernier espoir j'ai voulu tester avec un live cd de kubuntu. J'ai donc booté rapidement, installé lirc, lirc-x et lirc-modules-source et ré-itérer les étapes précédentes et la bingo : le voyant s'est allumé, ça a fonctionné directement. Déjà content que ça marche quelquepart j'ai voulu réessayer sur mon arch et la boum ça a fonctionné aussi, sans rien retoucher.

Note : le seul bouton qui ne fonctionne pas est celui qui permet de régler l'amplification du micro. Vu son intérêt limité je ne me suis pas penché en détail sur le pourquoi du comment.

- page 1 de 2