Jezz blog

Rafael Almeida vient de poster un poème sur debian-devel:

A ``patch'' rule for debian/rules there should always be
for I'd like to easily apply patches created by me
Don't worry I don't think of anything too hard
a simple standarization will ease my heart

Today ``debian/rules build'' is always a good match
but there's no mandatory ``debian/rules patch''
Is the ``build'' rule mandatory? I don't even know
it seems to work for most packages, though

Patches, it seems, are for ``configure'' rule to apply
but I want to make a script and I think it won't fly
That script I think of will install my own patches
to any installable package, from zopes to apaches

Configures can change too much
like config.h files and such
There should be one and only patch rule
and then I'll be able to build my tool

So geek!

On Laptop MSI CR600, device PNP0C0A (corresponding to battery) does not appear in /proc/acpi/battery nor in /sys/bus/acpi/drivers/battery/ with Linux 2.6.28.9.

Lire la suite

Buttons on MSI WindTop AE1900-WT (also called MS-6638) are currently not supported on Linux 2.6.28.9.

After long time of investigations, I found these buttons are handled by WMI. I wrote a WMI module for MSI.

Currently, there is an issue with interrupts. Buttons send between 25 and 30 interrupts when they are pressed. Kernel should forward only one event for each key press.

In add, this module should support Brightness.

Using Kernel 2.6.28.9, webcam BisonCam, NB Pro (5986:0241) on MSI WindTop AE1900-WT (also called MS-6638) is badly detected.

After some investigation, I found uvcvideo driver answers EIO when libv4l do VIDIOC_QUERYCTRL, with a particular id: 0x980903. This id seems correct and correspond to "Hue" control.

Also, dmesg says:

 uvcvideo: Failed to query (135) UVC control 6 (unit 5) : -32 (exp. 2).

Error 32 corresponds to EPIPE ("Stalled endpoint").

I wrote a workaround in libv4l :

--- libv4l-0.5.8.orig/libv4l2/libv4l2.c
+++ libv4l-0.5.8/libv4l2/libv4l2.c
@@ -740,0 +740,6 @@
+    // Jezz: Fix bug with '5986:0241 BisonCam, NB Pro'
+    if (request == VIDIOC_QUERYCTRL && result != 0 && errno == EIO) {
+      struct v4l2_queryctrl *queryctrl = arg;
+      if (queryctrl->id == 0x980903)
+        errno = EINVAL;
+    }

This workaround work fine, so problem exists only with this id.

Nevertheless, it is not a perennial solution. Laurent Pinchart wrote a better patch that I have adapted for 2.6.28.9.

Notice this problem seems specifics to this computer, not to this webcam. You can find there program I wrote to test this bug.

See also http://lists.berlios.de/pipermail/linux-uvc-devel/2009-May/004795.html

AdamW décrit sur son blog un nouveau périphérique pouvant s'apparenter à une carte graphique (et son écran) sur USB. C'est le chainon manquant que l'on attendait. Il y avait les claviers USB, les périphériques de stockage USB, les ports ethernet sur USB, les cartes son sur USB, il ne manquait que la carte vidéo. Avec la puissance des système embarqués qui ne cessent de grimper, bientôt, je pourrais brancher toute la tripaille de périphériques USB sur mon téléphone portable et m'en servir de machine de bureau.

Lorsque l'on touche au noyau, on se trouve rapidement confronté au problème de la distribution du noyau et de ses modules additionnels.

Je propose d'expliquer comment j'ai empaqueté le noyau 2.6.28.9 pour la société Substantiel. Il s'agit d'un cas complet avec des patch et des modules externes.

Lire la suite

I packed Microdia drivers for Debian. Direct link to source package

Bootsplash est un patch complètement obsolète pour avoir un démarrage graphique. Le développement s'est arrêté au noyau 2.6.21. Néanmoins, on a de temps en temps besoin des patch complètement obsolètes ;-). Donc, voici le patch porté sur le kernel 2.6.28.9. Notez que vous aurez besoin d'outils en userspace.

Je commence à véritablement détester les drivers propriétaires. Il y a toujours les arguments classiques: "C'est pas libre", "L'équipe kernel ne vous apportera aucune aide si vous avez un kernel "tainted"", etc ...

De mon point de vue, c'est surtout une catastrophe pour porter ces drivers d'une version à l'autre du noyau. Pas la peine de demander de l'aide à l'entreprise originaire du driver. Réponse classique: "On ne supporte que la version 2.6.4/gcc2.95 du noyau" ^[1]. Pire, parfois, vous n'avez qu'un .ko. Dans ce cas, il n'est mais pas envisageable de choisir un autre compilateur ou une autre version du kernel (ni certaines options de compilation). Evidement, rapidement, vous vous retrouvez sur votre système avec un driver qui ne fonctionne que en 2.6.8 et un autre que en 2.6.30. Il faut bien en porter un des deux. C'est généralement là que les choses se gâtent. On se rend compte que les auteurs ont gardé le code fermé, non pas pour préserver un soi-disant secret de fabrication, mais pour éviter qu'on les prennent pour des codeurs du dimanche ^[2]. Bref, porter un driver ça n'est pas forcément évident. Si il est mal codé, c'est pire: on risque de faire apparaitre des bugs "latents". Et si il vous n'avez ni les sources, ni les spécifications du matériel, ça devient un véritable casse-tête de comprendre les problèmes.

Par conséquent, pour avoir retarder le développement de certains de mes projets, je délationne : Fglrx, Nvidia (bien que le suivis du mainstream soit suffisament proche pour qu'il y ait peu de problèmes), DVS (fabriquant de cartes d'acquisition vidéo), Intel Poulsbo (Libre, mais personne n'est capable de comprendre ce qu'il fait), TrueFFS (Disk On Chip), etc...

Je me dis toujours qu'il faudrait un système de paquet pour les systèmes embarqués. Builtroot est trop monolithique et reste une suite de binaires. Il y a bien le système OpenEmbedded avec ipkg, mais il reste très monolithique dans sa manière de gérer les sources. Une Debian cross-compilée (avec scratchbox par exemple) donne un excellent système, mais même une installation minimale utilise plusieurs dizaines de mégas.

Pour bien faire, il faudrait partir d'une Debian. Le plus important serait de supprimer les dépendances avec perl et ne laisser que busybox comme interpréteur. Il faudrait avoir la possibilité d'utiliser µlibc. Lorsque l'on (corss-)compile, les paquets -dev, -doc, -dbg doivent être produit pour l'architecture hôte. Il faudrait aussi que le répertoire /use/share/doc soit supprimé. Et enfin, il faudrait pouvoir désinstaller apt/dpkg lors de la mise en production du système.

J'en rêvais, emDebian l'a fait. L'uniformité et la QA de Debian appliqué à l'embarqué... Formidable!

Bref, un projet à suivre de près.

How to add this kind of behavior to zsh:

 $ = 2 +4
 2 + 4 = 6

First, we need a command to do calculus. Personnaly, I love qalc command, so I use it as calculator. Nevertheless, it is not a standard command, so it is usefull to have a fallback. Zsh arithmetic expansion is great, we could use it:

 function myCalculator() {
   echo $(($*))
 }

Now, we need to add an alias to = command. But, alias doesn't accept syntax alias ==myCalculator. So we have to edit manualy aliases has table:

 $ # Be sure zsh/parameter module is loaded
 $ zmodload zsh/parameter
 $ aliases[=]=myCalculator

To use it, don't forget you need to type a space between = and your expression

Currently, I havn't find any solution for bash

Peut-on contrôler 8 périphériques RS422 à partir d'un bus CAN (avec du temps réel souple)? Je suis confronté au problème. J'ai une carte avec un contrôleur CAN et quelques I/Os. Evidement, je n'ai pas 8 ports RS422.... Mais j'ai un USB. J'utilise donc un hub USB sur lequel je connecte 8 convertisseurs USB/RS422 ^[1]. Les normes de RS422 étant ce qu'elles sont, je suis obligé de fabriquer des convertisseurs entre le pin-out utilisé par mes périphériques et celui de mes convertisseurs. Pour compléter le problème, je me rends compte qu'il y une erreur de conception sur notre carte et que notre port USB délivre du 3.3V. Il faut couper la piste d'alimentation (pour éviter le court-circuit entre notre carte et le hub) et rehausser le signal en utilisant un hub à alimentation externe.

Ouf... Voilà pour le hard. Maintenant coté soft. Il nous tout d'abord compiler notre driver usbserial, puis créer les devices appropriés. Maintenant, il faut être certain que le noyau ne nous joue pas des tours ^[2]. La commande suivante permet d'obtenir un bon paramétrage (sur le device /dev/ttyUSB0 avec en prime le paramétrage de la vitesse de transmission à 115200bps):

 stty -F/dev/ttyUSB0 115200 raw min 0 time 0 -echo

Bien entendu, nous sommes à la merci des buffers matériels. A priori, à notre échelle (20ms), ça devrait bien se passer.

Maintenant, il ne reste plus qu'à écrire un programme traduisant nos données CAN en données séries. Et au final, ça marche et c'est en production.

J'ai lu récemment cet article sur eyeOS. Ca me donne une impression de déjà vu. Vous ne souvenez pas de ce bon vieux serveur X distant? Je pense que l'on sous-estime sa puissance. Je vous rappelle ses avantages:

• pas de récriture des applications
• simplicité de mise en oeuvre du serveur
• technologie éprouvée
• portable sous Windows, Mac, Linux, BSD, SGI, etc... (Je rappelle les problèmes de portabilité entre les différentes machines virtuelles (autrefois, on avait des navigateurs) auxquels est confronté eyeOS)
• nécessite seulement un client léger
• parfaitement adapté aux environnement réseaux complexes

Lire la suite

Le serveur de sysmic.org héberge désormais aussi le célèbre site xulfr. La migration s'est bien passé. Le serveur tiens la charge. Je suis fier de pouvoir donner ma petite contribution à la communauté de Xul.

Je viens de m'apercevoir que la syntaxe suivante fonctionnait parfaitement en shell :

 true && foo() { echo ok; } || foo() { echo ko; }

Je ne sais pas si je dois trouver ça beau ou pas. Ca a un arrière goût de fonctionnel, mais pas assez pour que ça soit utilisable.