Utilisateur:Pini

GTA04A4 + Debian + QtMoko

Archives des notes : 2008 2009.

Journal

08/10/2012

QtMoko sur Debian Wheezy armhf

Adieu armel, vive armhf ! Quatre heures de cross-compilation pour QtMoko. Six heures et demi sous qemu pour le noyau...

Mais ça marche, pratiquement out of the box. Et le GTA04 y gagne en réactivité, en particulier pour la lecture vidéo.

Prochaine étape : réussir à cross-compiler QtMoko avec Qt 4.8.

17/09/2012

GTA04

[ Eh non, suis pas mort ;P ]

9 mois que je l'attendais, mon GTA04, et je l'ai enfin reçu il y a 8 jours.

Après le stress du montage, avec récupération de l'écran de feu mon FreeRunner, l'exitation de la nouveauté, puis une semaine de grosse déprime car le son plantait salement sur les appels entrant et sortant. J'ai finalement convergé sur une configuration stable et fonctionnelle (mais sans sonnerie) :

• Suppression pure et simple du device Headset Jack pour éviter que QtMoko me passe systématiquement en mode casque (pas pratique quand on en a pas, de casque)
• Mode Réunion pour éviter la sonnerie et le plantage du routage son qui va avec.

À part cette galère, y'a pas photo pas rapport au FreeRunner. Ce qui me change la vie c'est une 3G fonctionnelle, avec le tethering en prime. Très pratique dans le train avec un notebook.

Je vais maintenant m'employer à raccrocher les wagons concernant la compilation maison de QtMoko. Ça n'est pas si mal parti que ça!

Un GRAND MERCI à Golden Delicious pour nous permettre de continuer l'aventure \o/

13/11/2011

Paramètres de boot glamo

Le noyau 2.6.39 proposé sur la liste pkg-fso ne fonctionnait bizarrement pas avec ma carte SDHC. J'ai fini par avoir l'idée d'essayer d'utiliser les paramètres de boot glamo_mci.sd_max_clk et glamo_mci.sd_drive qui - si j'ai bien compris - sont relatif respectivement à la fréquence d'horloge max du chipset et la puissance d'écriture sur la carte SD. Je me rappelais les avoir vu recommandés pour certaines cartes récalcitrantes, et avoir essayé sans succès sur ma Kingston 4Go il doit bien y avoir deux ou trois ans.

Voici ce que j'ai trouvé comme explications pour sd_max_clk et sd_drive.

Après de multiples essais, je m'arrête sur ce paramétrage, qui boot le 2.6.39 avec succès et de façon reproductible :

rootwait glamo_mci.sd_max_clk=12500000 glamo_mci.sd_drive=0

Du coup j'ai reporté cette configuration sur ma QtMoko v35 de tous les jours, et le téléphone est maintenant bien plus stable ; plus de problème de carte SD remontée en read-only sur erreur plusieurs fois par jour.

03/11/2011

QtMoko on Debian from scratch

Mon retour d'expérience de QtMoko sur carte SD est mitigé. J'ai un bug très ennuyeux qui fait que de temps à autre la carte est remontée en read-only. Cela peut arriver plusieurs fois par jour, et le seul moyen de s'en tirer est de rebooter salement le téléphone. Mis à part ce petit détail, ça marche plutôt bien...

Mais une vraie Debian, sur laquelle le système est mis à jour au fur et à mesure au lieu d'être complètement réinstallé à chaque nouvelle version, me manque. Alors j'ai repartitionné précautionneusement ma carte SD pour avoir grosso modo deux partitions de 4Go chacune. Sur la première, je laisse QtMoko v35. Sur la seconde, j'ai installé Debian sans Zhone ni FSO. J'ai également installé qi-menu pour gérer facilement le multi-boot.

Le but est d'avoir l'usage de tous les jours (QtMoko v35) tout en jouant à reconstruire QtMoko de toute pièce à partir des sources pour obtenir un paquet installable sur la partition Debian.

Et après avoir pas mal galéré sur la cross-compilation, j'ai pu installer aujourd'hui mon premier QtMoko cross-compilé sur une Debian Wheezy amd64 avec uniquement des outils (em)Debian. Cinq heures de compilation !

Le résultat n'est pas encore utilisable (pas de son) mais prometteur : QtMoko est globalement fonctionnel, les SMS et les appels fonctionnent (même sans son, je peux appeler et décrocher) et le suspend n'est pas pire qu'avec QtMoko v35. Autre souci mineur, le service bluetooth fait un joli segfault au démarrage.

Suite au prochain numéro...

31/07/2011

QtMoko

Ce qui devait arriver arriva. Après yet another apt-get dist-upgrade, mon Frerunner est complètement planté depuis un mois. Avec le noyau 2.6.29, je n'ai plus de serveur X, et avec le 2.6.34, le serveur X prend 80% de CPU et fso-frameworkd est dans les choux. Vu le niveau de maintenance de la pile FSO dans Debian, je suis très pessimiste quant à mes chances de retrouver un tél fonctionnel en puisant juste dans testing et le dépôt pkg-fso.

Me voilà donc parti pour utiliser QtMoko en dépannage.

Eh bien je dois dire que je m'y habitue. Après tout, c'est aussi une Debian, je peux utiliser Navit, et c'est bien plus joli que Zhone. Je suis tout de même un peu à l'étroit, vu que c'est installé sur la mémoire flash du tél. Mais aujourd'hui je vais sauter le pas ; je fusille la Debian encore installée sur ma carte 8 Go pour y mettre QtMoko.

09/10/2010

Debian testing

Depuis début septembre j'ai recalé mon /etc/apt/sources.list pour pointer sur Debian testing au lieu de unstable + dépôt pkg-fso. Résultat : le FR reste fonctionnel et je suis beaucoup moins tendu lors des mises à jour ;). Mais il faut bien entendu rester vigilant car il peut arriver que des paquets cassés passent à travers le filtre testing.

08/06/2010

Noyau QtMoko 2.6.29-rc3-v24

Aujourd'hui installation du noyau de QtMoko v24. Ça boote et ça semble fonctionner. Durée de boot (jusqu'au dialogue code PIN sous Zhone) de 2'33, contre 2'36 pour le noyau Debian. Pas d'amélioration significative.

Je vais tout de même le garder un peu histoire de voir si le wifi performe mieux.

21/05/2010

ogpsd client de gpsd

Jusqu'à récemment tout allait bien côté GPS : avec fsoraw la cohabitation ronronnait entre Zhone et les applications clientes de gpsd. Mais depuis début mai c'était la grosse galère pour obtenir un fix avec navit. Je ne sais pas pourquoi ça marchait jusque là, mais j'ai dû me rendre à l'évidence : gpsd et ogpsd ne sont pas faits pour vivre ensemble car chaque donnée GPS récupérée par l'un n'est plus disponible pour l'autre :( Ne voulant pas choisir entre ogpsd et gpsd, j'ai décidé de patcher ogpsd pour qu'il soit client de gpsd. Après 10 jours de mise à l'épreuve sur mon FR, je ne suis pas mécontent du résultat.

26/04/2010

Xorg.conf et udev (le retour)

Nouvelle évolution dans X.org dans Debian, qui permet maintenant de rapatrier dans xorg.conf la config préalablement faite via des règles udev maison. Voici par exemple le xorg.conf snippet pour l'émulation du clic droit :

Section "InputClass"
	Identifier	"Clic droit"
	MatchIsTouchscreen	"on"
	Option		"EmulateRightButton"	"1"
EndSection

Voir ce billet pour des infos plus détaillées sur les nouvelles possibilités de configuration de X.org.

12/02/2010

Toujours le son - Retour à 'Mic 2'

Suite à quelques échanges sur la liste community, je suis revenu à mon ancienne config, en réduisant significativement le gain géré par control.12. Résultat, qualité audio de même niveau qu'avec la config QtMoko, tout en ayant une config plus en ligne avec les recommandations des développeurs.

J'en ai profité pour mettre à jour la page wiki de réglage du son.

Pour résumer

Ancienne config (qualité nulle avec un fond sonore)

control.48 = 1
control.12 = 6
control.63 = 'Mic 2'
control.5  = 127

Config inspirée de QtMoko (OK)

control.48 = 1
control.12 = 6
control.63 = 'Right PGA'
control.5  = 127

Config actuelle (OK)

control.48 = 1
control.12 = 1
control.63 = 'Mic 2'
control.5  = 110

05/02/2010

Enfin un son correct

J'ai récemment fait buzzfixer mon FR. Petit test rapide, à la maison : c'est nettement mieux, plus de buzz. \o/

Mais... il y a un "mais" : en extérieur ou avec un bruit de fond (gare, centre commercial, bistro) même léger, son ho-rri-ble pour l'interlocuteur. 90% du temps la conversation tenait principalement du "hein ? on comprend rien avec ton téléphone !". Mega frustrant... :(

Heureusement, grâce à ce thread sur le forum, j'ai eu l'idée d'aller chercher du côté de QtMoko voir s'il n'y avait pas un paramétrage ALSA plus pertinent à récupérer. Et bingo ! Après quelques jour d'essai de la nouvelle config, mon FR revit et j'ai à nouveau des conversations téléphoniques sereines.

Il n'y a plus qu'à pousser cette config dans Debian.

28/01/2010

Xorg.conf et udev

Cette semaine j'ai passé un peu de temps à résoudre un problème curieux et très gênant. En gros, depuis l'upgrade de mon FR du week-end dernier, le touchscreen se comportait très bizarrement. Après quelques tâtonnement, j'ai vu que chaque action était reproduite à un autre endroit de l'écran. Par exemple, si je tire le curseur graphique sur le côté gauche en faisant glisser mon doigt sur l'écran, le curseur se balade aussi sur le haut de l'écran. Le tout avec une parfaite symétrie :

• gauche -> haut
• bas -> gauche
• droite -> bas
• bas -> gauche

Le pire est que cela faisait aléatoirement - mais très rapidement - planter X dès que je voulais utiliser le clavier matchbox :(

J'ai questionné la liste smartphones-userland et on m'a donné une piste de réponse : utiliser le driver evdev en lieu et place de tslib.

Je n'en suis pas resté là, et après analyse des logs Xorg et des paquets xserver-xorg-input-tslib et xserver-xorg-input-evdev, j'ai enfin compris ce qu'il se passait : Le paquet du driver evedev installe un fichier rules pour udev qui joue le rôle de catchall pour la plupart des périphériques d'entrée X. Et le paquet du driver tslib n'en installe pas. Avec pour conséquence :

• chargement du pilote evdev déclenché par udev
• chargement du pilote tslib spécifié dans xorg.conf

=> deux drivers qui se tirent la bourre pour gérer les évènements du touchscreen :/

Solution :

• ajouter un fichier rules udev dans le paquet du driver tslib
• supprimer la référence à tslib dans xorg.conf (sinon Xorg verra un deuxième touchscreen au lieu de modifier la configuration de celui détecté par udev).

Le fichier xorg.conf est quasiment réduit à sa plus simple expression :

pini@debian-gta02:~$ cat /etc/X11/xorg.conf 
# Xorg configuration for an Openmoko FreeRunner
Section "Device"
	Identifier	"Configured Video Device"
	Driver		"glamo"
EndSection

Dernier problème à régler : plus possible de configurer le clic droit dans xorg.conf (sinon X voit deux touchscreens). J'ai donc ajouté un fichier rules udev perso dans /etc/udev/rules pour le configurer via udev :

pini@debian-gta02:~$ cat /etc/udev/rules.d/67-tslib-right-clic.rules 
ACTION!="add|change", GOTO="xorg_tslib_end"
KERNEL!="event*", GOTO="xorg_tslib_end"

ENV{x11_driver}=="tslib", ENV{x11_options.EmulateRightButton}="1"

LABEL="xorg_tslib_end"

Et voilà :)

DD

Grâce à Navit, me voici entré dans le sacro-saint cercle des DD.

/me est pas mal fier :D