totolito a écrit 11 commentaires

Bonjour/Bonsoir!

Et bien j'ai finalement réussi à faire ce que je souhaitais. J'ai modifier un des drivers de mplayer (celui qui écrit des images pnm au lieu d'ouvrir le buffer vidéo). Les images ne sont plus écrites sur le disque mais envoyé par messagerie IPC. Mon appli les récupèrent puis les affiche.

Ca marche niquel et c'est assez fluide B)

Merci pour votre participation!

Merci à tous pour ces pistes! Je regarde ça ^{__^}

Peux tu me donner plus d'info la dessus? Veux-tu dire que le QtWebKit 1.0 du QML est capable de lire des vidéos simplement du fait qu'il supporte du html5 ???

J'affiche déjà quelques pages html (docbook) pour de l'aide en ligne.

Comment puis-je tester tes dires?

Bonjour,

Merci de ta réponse!

L'intérêt est de ne pas avoir à embarquer X11 sur un petit micro avec une petite mémoire !!!

Je suis sur un micro ARM11 (plateforme type mini6410)

Salut à toi!

Pour le boitier, regarde chez Okatron / OKW, ils font des produits nommés "interface terminale", bonne qualité…

Pour la dalle, tu peux trouver du résistif pas cher, à piloter avec un ADC, voir trouver un contrôleur ADC vers liaison série quelconque…

Perso, utiliser un Rasperry pour ça c'est un peu galère, quand tu vois des systèmes déjà prêt à l'emploi (FriendlyARM par ex. fournit dalle LCD plus Touchscreen…

Connecter la dalle tactile
Tester la liaison i2c (et surtout retrouver l'adresse de la dalle - normalement 0x4b ou 0x4c - à faire dalle déconnectée puis connecté)
Cross compiler i2c-tools et lancer un i2cdetect sur le bus i2c

A partir des sources du noyau 3.0, récupérer et coller dans voss sources les fichiers suivants:
/drivers/input/touchscreen/atmel_mxt_ts.c
/include/linux/i2c/atmel_mxt_ts.h

Ajouter les lignes suivantes au fichier /drivers/input/touchscreen/atmel/KConfig

config TOUCHSCREEN_ATMEL_MXT
tristate "Atmel mXT I2C Touchscreen"
depends on I2C
help
  Say Y here if you have Atmel mXT series I2C touchscreen,
  such as AT42QT602240/ATMXT224, connected to your system.

  If unsure, say N.

  To compile this driver as a module, choose M here: the
  module will be called atmel_mxt_ts.    

Ajouter les lignes suivantes au fichier /drivers/input/touchscreen/atmel/Makefile

obj-$(CONFIG_TOUCHSCREEN_ATMEL_MXT) += atmel_mxt_ts.o    

Editer votre fichier décrivant votre plateforme (mach-xxx.c)

static struct mxt_platform_data mxt_platform_data __initdata = {
        .config         = NULL,
        .config_length  = 0,
    .x_line     = 18, 
    .y_line     = 12,
    .x_size     = 800,
    .y_size     = 480,
    .blen       = 0x1,
    .threshold  = 0x28,
    .voltage    = 3300000,
    .orient     = MXT_DIAGONAL,
    .irqflags   = IRQF_TRIGGER_FALLING
};

static struct i2c_board_info i2c_devs0[] __initdata = {
[...]
    { I2C_BOARD_INFO("mXT224", 0x4b),
      .platform_data    = &mxt_platform_data,
      .irq          = IRQ_EINT(16),
    },
[...] }  

Note: On suppose q'un bus i2c est déjà présent et configuré...
Ici l'id de l'irq câblée est 16... A adapter.

Lancer la configuration du noyau

make menuconfig 

Activer la compilation du driver en mode noyau:
Device Driver -> Input Device Support -> Touchscreen -> Atmel mXT I2C Touchscreen.

Désactiver les drivers de la dalle actuelle si nécessaire
Device Driver -> Input Device Support à Touchscreen -> Votre dalle

cross-compiler (ex avc un arm)

make CROSS_COMPILE=/chemin vers compilo/preefix_compil- 

Reflasher le noyau puis démarrer

Un dmesg | grep mxt doit vous lister ce type de lignes (ici addr i2c = 0x4b)

atmel_mxt_ts 0-004b: Family ID: 128 Variant ID: 1 Version: 22 Build: 171
atmel_mxt_ts 0-004b: Matrix X Size: 18 Matrix Y Size: 12 Object Num: 17 

Ce qui signifie que le driver a bien détecté le mXT!

Tester le /dev/input/event0 à l’aide du programme evtest:

evtest

ou sur un event précis:
evtest /dev/input/event0

Récuperer et extraire la tslib

Pré-Configurer

cd tslib
./autogen.sh

Configurer (ex avec un arm11)

./configure                       \
--host=arm-linux --target=arm  --prefix=/chemin_tslib/output \
CFLAGS="-march=armv6 -mtune=arm1176jzf-s -mfloat-abi=softfp" \
CXXFLAGS="-march=armv6 -mtune=arm1176jzf-s -mfloat-abi=softfp" \
--enable-static --enable-shared

cross-Compiler et récupérer les libs dans --prefix

make
make install    

Tester le fonctionnement avec un ts_calibrate puis ts_test

Note: Après installation sur la cible, éditer ts.conf afin d’utiliser le module input:
module_raw input. Faire un fichier de conf de la tslib. ex:

export TSLIB_TSEVENTTYPE=INPUT
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event0
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/etc/ts.conf
export TSLIB_PLUGINDIR=/lib/ts

Désolé pour la réponse tardive mais je n'en ai pas été notifié...

Pour le module multitouch, la dernière release de tslib intègre le support multitouch.

Source ici:
https://github.com/kergoth/tslib/downloads

Pour définir ma plateforme, j'ai tapé dans ce fichier:
/arch/arm/mach-s3c64xx/mach-mini6410.c

A toi de trouver le tiens...

Pour info dans mon mach-mini6410:

static struct mxt_platform_data mxt_platform_data __initdata = {
.config = NULL,
.config_length = 0,
.x_line = 18, 
.y_line  = 12,
.x_size  = 800,
.y_size  = 480,
.blen    = 0x1,
.threshold  = 0x28,
.voltage    = 3300000,
.orient  = MXT_DIAGONAL,
.irqflags = IRQF_TRIGGER_FALLING
};

static struct i2c_board_info i2c_devs0[] __initdata = {
[...]
{ I2C_BOARD_INFO("mXT224", 0x4b),
.platform_data = &mxt_platform_data,
.irq     = IRQ_EINT(16),
}
[...]
};

Pour l'IRQ il est fortement déconseillé de s'en passer !! Sinon tu es obligé de poller en permanence le mxt224, pas bon pour pleins de raisons...
Attention, j'ai patché le driver mxt224 afin de faire une petit lecture i2c d'un registre de temps en temps car parfois l'IRQ n'est pas relâché...

bonne chance...

Oyé!

Suite et fin de mon aventure avec mon touchscreen:

Donc, je me retrouve avec un /dev/input/event0. Que faire maintenant?

Avant, avec le touchscreen d'origine, j'avais un /dev/touchscreen. En faisant un cat dessus, je voyais un paquet de data passer lorsque je touchais le TS. Je tente un cat /dev/input/event0, qui ne marche pas.

En fouinant, je trouve un soft qui s'appelle evtest et qui permet justement de tester "brut" les événements de type input. Compilation, et lancement, bingo, le driver mXT envoi bien des événements!!!

On continu en configurant la tslib sur /dev/input/event0: touchscreen non supporté! :-/

Du coup je jette un oeil aux sources, et me rend compte que mon TS est multitouch, alors que la tslib ne le supporte pas :-S

Heureusement, tslib fonctionne avec des "modules", ici, le fichier de conf de tslib est configuré ainsi: module_raw input
Houra! Je trouve quelqu'un qui a codé un module compatible multitouch, recompile et test:
Ca tourne !!!!!!

Malheureusement, ça tourne pendant un certain temps pluis plus rien. Après analyse, la ligne IRQ (faling edge) reste en bas -> Une IT loupée par le driver :-/

Pas le coeur à trouver où le driver des ITs foire, j'ajoute un schedule_delayed_work à la fin de l'ISR afin de lire le mXT 100ms plus tard, ainsi la ligne IRQ remonte toujours après 100ms. Ok, pas très propre mais 3 lignes en plus et un polling différé seulement après l'IT, j'ai vu pire ;-)

Donc tout roule !!!!

Merci de votre soutien.

Pour info: totolito@gmail.com

Voici des infos complémentaires, qui m'ont permis de mettre en oeuvre le driver !

Après avoir compilé mon driver, j'ai vu qu'il était bien chargé, mais aucun device n'y était attaché.

J'ai fini par comprendre qu'il fallait indiqué quel device (et à quelle adresse) était connecté à notre plateforme. En fonction du nom de ce device, linux cherche un driver associé. Dans mon driver, j'ai une liste (d'alias) de nom de devices supportés. Les deux doivent matcher pour que le driver probe le device

J'ai recompilé une première fois et le driver m'a gratifié d'un "not enough params". Après recherche, j'ai trouvé que le driver avait besoins d'infos spécifiques à ma plateforme, en l'occurence, à quelle dalle le mXT224 était connecté (taille, nombre de lignes X/Y, orientation, etc). J'en ai profité pour lui coller une IRQ,

Recompile, lancement, et là, le driver trouve mon device et créer un /dev/input/qlq chose

Ça sent bon, je remets en ordre mon rootfs pour jouer avec et je reviens!

Salut par ici!

Tout d'abord, merci de votre participation, je n'ai que très peu de réponse ailleurs pour mon souci.

Il faut dire pour motiver les foules que je viens de loin: Jamais fait de linux embarqué, j'ai réussi grâce au net à mettre sur pied un environnement de cross-compilation, personnalisation, compilation et installation de u-boot, kernel, rootfs, lib Qt, puis développement d'une IHM avec ce nouveau framework, superbe interface graphique avec QML !! J'adore !

Le plus difficile arrive donc avec le changement de l'écran (pas assez lumineux) et de la dalle tactile (plus résistante face aux utilisateurs). C'est là où je m'attendais à avoir le plus de problème !!!

Bon, aujourd'hui je creuse cette histoire de bind, qui visiblement permet de lier un driver à un device...

Ensuite je vais trouver un bon cours sur le fonctionnement détaillé de /dev/input. J'ai encore des flous à ce sujet. En effet, mon ancien touchscreen était accessible en faisant un cat /dev/touchscreen, et je ne visualise pas très bien où-comment le /dev/input intervient...

Et pour finir, je déboulotterai le fichier /drivers/input/touchscreen/atmel_mxt_ts.c afin de mieux comprendre comment il fonctionne. J'y ai déjà jeté un coup d'oeil et les différences avec mon ancien driver de dalle (via une communication série propriétaire) sont nombreuses:
- L'ancien fonctionnait de manière un peu bâtard il me semble, car il y avait deux drivers, un pour gérer la liaison série et qui routait ça par un copy_to_user dans /dev/touchscreen-1wire, et un autre fichier qui utilisait les possibilités de /dev/input via des input_report_abs(). Par contre je n'ai pas trouvé le lien entre les deux :-(

Merci de votre attention ;-)

Flute j'ai perdu mon post!

Je disais donc que je suis désolé pour le multiposte, mais j'ai trop hésité entre les deux sections -.-

Sinon j'ai recompiilé le noyau pour y intégrer le driver atmel.

Voilà aussi le résultat d'une commande :

# ls /sys/bus/i2c/drivers/atmel_mxt_ts
bind  uevent  unbind

Je suppose que le driver est bien "chargé". Je cherche maintenant à comprendre à quoi sert bind, uevent et ubind..

Merci à vous