Discussion :

[totolito]

Bonjour à tous,

Je développe actuellement une application sur la plateforme mini6410 de friendlyARM équipée d'un ARM11 de Samsung et d'un écran 7" tactile, le tout tourne sur emdebian avec le framework Qt + QML

Je souhaite changer la dalle tactile résistive actuelle par une dalle tactile capacitive projetée. La dalle actuellement est possède un driver développé par friendlyARM et je peux l'utiliser avec la tslib.

La dalle que je souhaite utilisée possède un chip atmel mXT pilotable en i2c. J'ai trouvé le driver ad-hoc dans le noyau linux 2.6.39 dans /drivers/input/touchscreen/atme_mxt_ts.c.

J'ai backporté ce driver dans mon noyau tuné 2.6.36 sous forme de module que j'ai pu charger avec insmod dans la cible. Jusque là, tout va bien

Avec i2cdetect, j'ai bien trouvé ma dalle sur le bus i2C.

Mais maintenant, je ne sais plus quoi faire!!! Je pensais devoir faire un mknod afin de le linker sur la tslib, mais pas de trace de major/minor dans le driver qui semble utiliser le périphérique i2c (logique) mais je n'ai aucune idée de la procédure à faire ensuite

Si une bonne âme peut me donner quelques info sur la manière de procéder


J'ajoute que la dalle a aussi un contrôleur USB qui m'a permis de la tester sur Ubuntu avec succès, détection et utilisation au poil

[totolito]

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

[totolito]

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

[agaves]

Bonjour à tous,

Je suis confronté au même souci que toi, je développe une application sur une PHYCARD-L de PHYTEC OMAP 3530 et d'un écran 7" tactile en linux OSELAS 2.6.33.7. .

J'essaye de faire fonctionner le système avec une dalle tactile capacitive projetée. J'ai réalisé un premier essai avec une dalle avec un driver EGALAX en USB le problème est que le driver fourni à besoin du server X11 et que je n'utilise pas celui-ci.

Je me suis orienté vers OCULAR qui propose des dalles avec contrôleur atmel mxt224 soit en USB soit en I2C. Je dois recevoir une dalle capable de faire les deux aujourd'hui ou demain.

J'aimerais faire comme toi, mais je ne suis pas encore assez doué pour m'en sortir tout seul.

J'ai récupéré les fichiers atmel_mxt_ts.c et atmel_mxt_ts.h créé un Makefile pour cross compilé le driver sous forme de module .

Je lance le make en rajoutant les paramètres pour être certains qu'ils soient pris en compte.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

make SUBARCH=arm CROSS_COMPILE=/opt/OSELAS.Toolchain-1.99.3/arm-cortexa8-linux-gnueabi/gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/bin/arm-cortexa8-linux-gnueabi-

Cela génère bien le fichier .ko , par contre je suis bloqué pour la modification du driver pour lui indiquer le mXT224 ainsi que la taille, le nombre de ligne, l'orientation et l'IRQ (au passage est-il possible de ne pas utiliser d'IRQ?).

J'ai bien vu qu'il fallait définir une structure struct mxt_platform_data mais où la définir. J'ai comparé avec le driver d'un MCP2515 qui est déjà implémenté sur ma plateforme et c'est un fichier mcp251x_plat.c qui fait cela. Ensuite, je fais un modprobe mcp251x_plat expansion_slot=1. Dois-je poursuivre sur cette piste?

Pour anticiper les problèmes est-il possible de me dire où trouver le module multitouch de la TSLIB?

Merci

[totolito]

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...

[totolito]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

obj-$(CONFIG_TOUCHSCREEN_ATMEL_MXT)	+= atmel_mxt_ts.o

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
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:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

evtest

ou sur un event précis:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

evtest /dev/input/event0

Récuperer et extraire la tslib

Pré-Configurer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$cd tslib
$./autogen.sh

Configurer (ex avec un arm11)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
./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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
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:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
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

[agaves]

Bonjour,

Je vous adresse mes meilleurs voeux pour 2012. Je vous remercie pour le tuto, je pense que j'y serait encore sans cela.

Je pense que je suis confronté au même problème pour l'interruption.

"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é..."

Au démarrage la dalle génère une interruption qui n'est jamais traitée par le système, en déconnectant le signal d'interruption et en le reconnectant cela regénère le front descendant du coup cela débloque le système. Ensuite la dalle fonctionne correctement.

J'aissyé d'initialiser l'interruption le plus tard possible mais rien ne fonctionne.

Peux-tu m'indiquer les modifications que tu as effectuées dans le driver, j'utilise la version 2.6.39 ?

[totolito]

Bonjour à tous!

En pièce jointe le fichier Diff permettant de patcher les sources...