dimanche 27 décembre 2009

Plus de son

(Travail en cours ; toute la rédaction est à revoir...)

Carnet d'expédition archéologique au cœur du noyau Linux de Dapper Drake...

Heureux propriétaire d'une carte 'Hercules Smart TV-2 Stereo', je pouvais, il y a peu encore, regarder la télévision tout en m'occupant sur mon ordinateur... Tout allait bien sur ma Dapper Drake (juin 2006) jusque 2008, quand une mise à jour du noyau (kernel ChangeLog) (2.16.15-51-386 -> 2.16.15-52-386) m'a subitement privé du son. Après avoir passé un certain temps à sélectionner à la main le 'bon' noyau au démarrage, je me suis résolu à modifier /boot/grub/?. Et, je l'ai refait à chaque mise-à-jour du noyau jusqu'à il y a deux semaines où je me suis décidé à passer à Karmic Koala (octobre 2009, suite à un problème matériel sur mon ordinateur). Et là, ho rage, ho désespoir, le son ne fonctionne toujours pas et il n'est plus question de revenir à l'antique 'kernel', le standard de la distribution est 2.6.31-16...

(En fait j'aurais juste du mettre des options pour tvaudio en passant de -52 à -53; Le son fonctionne toujours sur ma dernière Dapper (janvier 2010; c'était une fausse piste donc)

La gestion des versions du driver de la carte appartient au projet v4l (video4linux sur http://LinuxTV.org). Tout l'historique des développements est accessible via un système Mercurial.

La gestion des versions du noyau sous Ubuntu s'effectue sur un système Git.

Et, si l'on en croit la configuration nécessaire pour le faire fonctionner (/etc/modprobe.d/bttv.conf) :

# http://doc.ubuntu-fr.org/carte_tv_pilote_bttv#carte_tv_hercules_smart_tv_2_stereo
#
alias char-major-89 i2c-dev
options bttv card=100 tuner=38
options tvaudio tda9874a=1 tda9874a_STD=8 tda9874a_AMSEL=1 tda9874a_SIF=2
options tda9887 port1=0 port2=0 pal=1

Cela se passe du côté de bttv, tvaudio et tda9887 que l'on peut facilement retrouver en quelques secondes parmi les dizaines de milliers de fichiers (31208 dans 2.6.31) du noyau grâce à des commandes du genre :

$ find /usr/src/linux/linux-source-2.6.31 |grep bttv

Du côté de video4linux...

Remarquons qu'il y a aussi de la documentation et qu'il suffit peut-être de choisir les bons paramètres lors de l'insmod (via la documentation bttv ou la commande 'modinfo bttv'). Le problème, c'est qu'il y a vraiment beaucoup de paramètres... À noter que le 'browser Mercurial' permet de rapidement voir si la documentation a changé début 2008 (en allant de 'parent' à 'parent' dans le fichier en question). (et noter qu'il n'y a pas d'option 'pal' pour le tda9887...)

Du côté du kernel

C'est là qu'il convient d'aller pour savoir quelles versions de v4l ont été utilisées dans les deux versions. Et, en fait, quelle est la politique de mise à jour. Parce que ''The Art of Kernel Maintenance'' ne semble pas être une activité triviale. Ils doivent maintenir plusieurs distributions (Dapper, Edgy, Festy, Hardy, Jaunty, Karmic...) avec plusieurs versions du noyau (2.6.15 .. 2.6.31). Quand passent-ils d'une version à l'autre? Probablement pas à l'intérieur d'une distribution. Comment font-ils évoluer les versions?... (voir par exemple la FAQ de Mark Shuttleworth ou le numéro de sous-version ABI)

Maintenant, comment générer l'arbre source du kernel 2.6.15.51-386 ou connaître la version de bttv.c qui y était incluse? That's the question. (en fait, la commande 'modinfo' sur le fichier ou sur le module actif donne un code 'srcversion' qui permet le localiser la source équivalente au binaire dans Mercurial).

Les Gits des kernels sont accessibles via le web : http://kernel.ubuntu.com/git et, cela semble se passer ici, mais c'est bien mystérieux... Ou, ici? où il se passerait quelque chose du côté de linux-headers-2.6.15-51? C'est quoi ce binaire Google(0xeecd5cab bttv_get_cardinfo)? (l'adresse de bttv_get_cardinfo()?)

Un petit tour par la documentation?

Si je cherche bttv dans Ubuntu Linux 2.6 Git, j'obtiens un historique des changements dans le coin que je peux consulter individuellement via commitdiff. Par exemple : une modification à bttv-card.c (sauf que la date sur la page de la modif ne correspond pas à celle de la liste?! 25aug2006/25jan2008 ...bizarre). Cela me donne accès à la version du fichier à l'époque. Le problème, c'est qu'ils semblent beaucoup y avoir travaillé début janvier 2008. Mais, est-ce que tout ça est backporté sur Dapper 2.6.15.52? (dans le Git de Tim Gardner, il parle de modifier Hardy en Dapper, mais je ne comprends pas encore ce qu'il a fait...)

En fait, je peux naviguer dans l'arbre des sources du kernel et consulter tous l'historique de tous les fichiers (on avance! :-). (mais, je ne sais toujours pas comment ils font pour générer un kernel particulier...)

Le problème est de trouver le bon endroit...

En principe d'après Current Git Trees, je dois utiliser Ubuntu-Dapper.git

/* Il faut vérifier que je suis dans le bon Git pour la suite... */

Le SHA-1 identifie de manière unique un sous-arbre particulier (ou un fichier) à un instant donné.

* Snapshot ubuntu-dapper-2.6.15.51-65/drivers/media 1fc7d77b7bbdd1b020236a3387ac7c154aca1cc4
* Snapshot Ubuntu-dapper-2.6.15-52-68/drivers/media 1fc7d77b7bbdd1b020236a3387ac7c154aca1cc4

Les fichiers dans /drivers/media de 15-51 et 15-52 sont identiques! Il va falloir vérifier que le problème apparaît à cet instant précis ou trouver autre chose...

Cela ne doit pas être le bon Git, si je consulte l'historique de /drivers dans Ubuntu/Linux-2.6, je vois qu'il n'a pas été modifié depuis le 22oct2007...

ici, peut-être... (cela ne semble pas être un kernel complet)

----
En fait, dans /etc/boot de ma Dapper, je trouve une série de fichiers dont

-rw-r--r-- 1 root root 266619 2006-05-23 18:56 abi-2.6.15-23-386
-rw-r--r-- 1 root root 266619 2006-06-14 14:15 abi-2.6.15-25-386
-rw-r--r-- 1 root root 266735 2006-09-08 23:51 abi-2.6.15-26-386
-rw-r--r-- 1 root root 266735 2006-12-08 20:34 abi-2.6.15-27-386
-rw-r--r-- 1 root root 266735 2007-07-19 01:36 abi-2.6.15-28-386
-rw-r--r-- 1 root root 266735 2007-09-24 19:58 abi-2.6.15-29-386
-rw-r--r-- 1 root root 266735 2008-02-12 18:32 abi-2.6.15-51-386
-rw-r--r-- 1 root root 266735 2008-10-22 22:50 abi-2.6.15-52-386
-rw-r--r-- 1 root root 266735 2009-01-26 02:01 abi-2.6.15-53-386
-rw-r--r-- 1 root root 266735 2009-08-18 20:25 abi-2.6.15-54-386
-rw-r--r-- 1 root root 266735 2009-12-01 19:41 abi-2.6.15-55-386

Mais, bien évidemment, la gestion de la carte TV se passe dans /lib/modules

drwxr-xr-x 7 root root 4096 2006-06-19 12:13 2.6.15-25-386
drwxr-xr-x 7 root root 4096 2006-06-19 14:01 2.6.15-23-386
drwxr-xr-x 7 root root 4096 2006-10-05 08:58 2.6.15-26-386
drwxr-xr-x 2 root root 4096 2007-02-13 16:24 2.6.15-28-686
drwxr-xr-x 8 root root 4096 2007-02-13 16:28 2.6.15-27-386
drwxr-xr-x 7 root root 4096 2007-07-22 04:59 2.6.15-28-386
drwxr-xr-x 7 root root 4096 2008-01-01 12:59 2.6.15-29-386
drwxr-xr-x 7 root root 4096 2008-02-14 06:22 2.6.15-51-386
drwxr-xr-x 7 root root 4096 2008-10-28 09:42 2.6.15-52-386
drwxr-xr-x 7 root root 4096 2009-01-29 07:36 2.6.15-53-386
drwxr-xr-x 7 root root 4096 2009-08-20 06:56 2.6.15-54-386
drwxr-xr-x 7 root root 4096 2009-12-05 11:09 2.6.15-55-386

qui ne fait pas, à proprement parler du kernel... (c'est l'ABI qui fait le lien). C'était généré par un 'make modules' dans l'arborescence du kernel...

Cuurieusement,

xof@xof-desktop:/media/a328b179-c140-49cb-9aeb-1adcfba04ed2/lib/modules$ ls -l 2.6.15-51-386/kernel/drivers/media/
total 20
drwxr-xr-x 2 root root 4096 2008-02-14 06:21 common
drwxr-xr-x 12 root root 4096 2008-01-17 05:59 dvb
drwxr-xr-x 2 root root 4096 2008-02-14 06:21 em8300
drwxr-xr-x 2 root root 4096 2008-02-14 06:21 radio
drwxr-xr-x 7 root root 4096 2008-02-14 06:21 video
xof@xof-desktop:/media/a328b179-c140-49cb-9aeb-1adcfba04ed2/lib/modules$ ls -l 2.6.15-52-386/kernel/drivers/media/
total 20
drwxr-xr-x 2 root root 4096 2008-10-28 09:42 common
drwxr-xr-x 12 root root 4096 2008-06-20 07:21 dvb
drwxr-xr-x 2 root root 4096 2008-10-28 09:42 em8300
drwxr-xr-x 2 root root 4096 2008-10-28 09:42 radio
drwxr-xr-x 7 root root 4096 2008-10-28 09:42 video

dvb n'a pas la même date que les autres. Est-ce moi qui jouais avec un tuner DVB-S Pinnacle?


Après quelques chipotages, la compilation de v4l se passe bien...

$ hg clone http://linuxtv.org/hg/v4l-dvb
$ cd v4l-dvb
$ cp /boot/config-`uname -r` v4l/.config (voir ici)
$ make
$ sudo make install

Voir aussi:
* kernel-modules sur Lea-Linux
* Tout savoir sur les modules kernel (ubuntu-fr)
* v4l2 driver FAQ
Toujours pas de son et

[ 12.614382] tda7432 1-0045: chip found @ 0x8a (bt878 #0 [sw])
[ 12.631258] tda7432 1-0045: I/O error, trying tda7432_set
[ 13.388297] tda7432 1-0045: I/O error, trying (write 3 0x20)
[ 13.396637] tda7432 1-0045: I/O error, trying (write 4 0x20)
...

----------------
Sur Dapper Drake Live-CD

Après avoir recopié ~/.xawtv et /etc/modprobe.d/bttv et installé xawtv (universe) via synaptics, cela fonctionne. J'ai sauvegardé les /var/log/* avec debug; je regarderai demain...
(En rebootant sur Karmic sans éteindre, le son est +/- préservé, mais il y a des parasites et la commande mute/unmute ne fonctionne pas)

Le log me donne un tda9874h/a mais pas de tda7432, je rajoute donc '.no_tda7432 = 1,' pour que bttv-cards.c n'aille pas s'y perdre et utilise tvaudio qui est censé gérer le bon. Mais, cela ne fonctionne pas encore et j'ai des

[ 4912.476706] i2c-adapter i2c-1: sendbytes: NAK bailout.
[ 4912.476736] tda9887 1-004b: i2c i/o error: rc == -5 (should be 4)

ce qui mène à cette discussion sur les modifs i2c dans le kernel... (j'en profite pour charger i2c-tools...)
----------------

# modprobe i2c-dev
# i2cdetect -l
i2c-0 unknown SMBus Via Pro adapter at e800 N/A
i2c-1 unknown bt878 #0 [sw] N/A
# i2cdetect 1
[...]blabla
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- UU -- -- -- -- -- -- -- -- -- 4b 4c 4d -- --
50: 50 -- -- -- -- -- -- -- 58 -- -- -- -- -- -- --
60: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

...Je devrais pouvoir envoyer les bonnes commandes pour router le son dans la carte avec i2cset (?)...
----------------
Une idée, comparer le numéro de version que l'on trouve via modinfo...

/lib/modules/2.6.15-51-386/kernel/drivers/media/video/tvaudio.ko
srcversion: 5B62BEA5D9DCEF52F88D4F6

et pas de chance, c'est le même

/lib/modules/2.6.15-52-386/kernel/drivers/media/video/tvaudio.ko
srcversion: 5B62BEA5D9DCEF52F88D4F6

et même aussi pour bttv.ko (BED2FF73EA54562245EF4EA)...

En fait, il n'y a aucun module v4l différent entre les deux collections de modules

find /lib/modules/2.6.15-51-386/ -name "*.ko" -exec modinfo \{} \; -exec echo srcxx \{} \; |grep src > /tmp/core.51.txt

donne une poignée de différences avec *52* mais aucune dans drivers/media...

Pour l'anecdote (cela n'a en principe rien à voir), les modules suivant diffèrent :

kernel/sound/core/seq/oss/snd-seq-oss.ko
kernel/sound/core/snd-page-alloc.ko
kernel/sound/usb/usx2y/snd-usb-usx2y.ko

----------------
Là, il ne reste plus qu'à retester sur la Dapper que c'est bien la transition 51->52 qui a foiré... Hé bien non!, c'est probablement 52->53 (52 Ok; 54 Ko)

$ ls -l 2.6.15-5[1234]-386/kernel/drivers/media/video/tvaudio.ko
-rw-r--r-- 1 root root 29255 2008-02-12 18:32 2.6.15-51-386/kernel/drivers/media/video/tvaudio.ko
-rw-r--r-- 1 root root 29255 2008-10-22 22:50 2.6.15-52-386/kernel/drivers/media/video/tvaudio.ko
-rw-r--r-- 1 root root 29687 2009-01-26 02:00 2.6.15-53-386/kernel/drivers/media/video/tvaudio.ko
-rw-r--r-- 1 root root 29687 2009-08-18 20:25 2.6.15-54-386/kernel/drivers/media/video/tvaudio.ko
/lib/modules$ modinfo 2.6.15-5[1234]-386/kernel/drivers/media/video/tvaudio.ko |grep srcve
srcversion: 5B62BEA5D9DCEF52F88D4F6
srcversion: 5B62BEA5D9DCEF52F88D4F6
srcversion: 8C7BC315B1D8D6A59F0B263
srcversion: 8C7BC315B1D8D6A59F0B263
/lib/modules$ modinfo 2.6.15-5[1234]-386/kernel/drivers/media/video/bttv.ko |grep srcve
srcversion: BED2FF73EA54562245EF4EA
srcversion: BED2FF73EA54562245EF4EA
srcversion: BED2FF73EA54562245EF4EA
srcversion: BED2FF73EA54562245EF4EA
/lib/modules$ modinfo 2.6.15-5[1234]-386/kernel/drivers/media/video/bt878.ko |grep srcve
modinfo: could not find module 2.6.15-5[1234]-386/kernel/drivers/media/video/bt878.ko
/lib/modules$ lsmod |grep bt
bt878 10552 0
bttv 164304 2 bt878
video_buf 22148 1 bttv
i2c_algo_bit 9608 1 bttv
v4l2_common 6016 1 bttv
btcx_risc 5128 1 bttv
tveeprom 15248 1 bttv
videodev 9856 2 bttv
i2c_core 21904 9 i2c_acpi_ec,tuner,tda9887,tvaudio,tda9875,bttv,i2c_algo_bit,tveeprom,i2c_viapro
/lib/modules$ modinfo 2.6.15-5[1234]-386/kernel/drivers/media/video/bt878.ko |grep srcve
/lib/modules$ find 2.6.15-54-386 -name bt878.ko
2.6.15-54-386/kernel/drivers/media/dvb/bt8xx/bt878.ko
/lib/modules$ modinfo 2.6.15-5[1234]-386/kernel/drivers/media/dvb/bt8xx/bt878.ko |grep srcve
srcversion: 7688453D8D873E5C1865FDF
srcversion: 7688453D8D873E5C1865FDF
srcversion: 7688453D8D873E5C1865FDF
srcversion: 7688453D8D873E5C1865FDF

---------------
Oups!, en fait, il fallait ajouter la ligne tvaudio dans /etc/modprobe.d/bttv (qui ne contenait que la ligne bttv...)... -53 fonctionne. et -55 aussi! En fait, je n'ai (aurais) jamais dû avoir de problème sur Dapper... si j'avais résolu le problème quand il est apparu.

C'était donc une fausse piste.
---------------
Après m'être aperçu que la boîte métallique du tuner comprenait un TDA9801T dont la pin 9 (AF) sort de l'audio, je me suis résolu à souder les deux fils comme proposé par Genicus. Et, ça fonctionne. En connectant le fil sur le connecteur AUX de ma carte Asus (A7V8X-X). Je peux enfin entendre la TV avec la commande :

$ aplay /dev/dsp

---------------
Ce mail mène à ce diff
---------------
(à suivre)

dimanche 21 décembre 2008

Cycles de Spot-4


Spot-4 est sensé faire un 'cycle' de 369 révolutions en 26 jours, mais les TLEs donnent 14.2003151391 révolutions par jour et non 369/26=14.1923076923... La position du satellite ne semble pas dûe au hasard, elle est maintenue avec grand soin. Et cette histoire de 'cycle' n'est pas non plus approximative : on veut que le satellite passe (si possible) exactement au même endroit régulièrement pour pouvoir comparer les mesures...

Pourquoi diable? Où est l'astuce? (J'avais le même problème avec MetOp-A (412/29 ne correspond pas à la valeur donnée par les TLEs)...)

...À suivre.

NB: pour Envisat, on a un cycle 501/35 et ...c'est la même chose.

501/35 = 14.314285714 et la moyenne des TLEs donne 14.3224877034.
(les rapports mesures/fractions sont 1.0005729932 (Envisat) et 1.0005642103 (Spot); ça n'a pas l'air d'être un hasard non plus...)
----
Par comparaison, ISS est beaucoup moins régulé :

----
----
Solution : en fait, c'est parce que la période utilisée dans les TLEs est la période anomalistique (entre deux périgées) tandis que la période des cycles est la période draconitique (nodale, entre deux noeuds ascendant (ou descendant)). À cause de la précession due au 'bourrelet équatorial', elles sont distinctes. (voir, par exemple : p.105, "Satellites : orbites et missions" de Michel Capderou (2002))

On peut calculer la période draconitique en fonction de la période anomalistique au moyen des formules suivantes :



Pour Envisat, a = 7159.496 km, i = 98.55°, e = 0.001165

(R = 6378.137 km à l'équateur (6356.752 km aux pôles))

(J2 = 1.08262622070 10-3, l'effet du bourrelet)

Cela donne quelque chose comme

Td = 1.000572674 * Ta

(...Ce qui correspond assez bien. :-)