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

[Aquanum]

A tout hasard, tu as un uevent de type add qui passe ? (Déjà sans regarder dans le code.)

[totolito]

Bonjour Aquanum !

Et bien... je ne sais pas de quoi tu parles

J'ai fait un dmesg, et rien ne semble indiquer que l'i2c a trouvé mon périphérique.

Par contre je lis bien son contenu avec un i2cget... et je retrouve bien le répertoire /sys/bus/i2c/drivers/atmel_mxt_ts.

Dans celui-ci je trouve 3 trucs sur lesquels je vais bientôt prospecter pour savoir à quoi ça sert:
bind, uevent et unbind...


NB: J'ai recompilé le driver en mode noyau...

[Aquanum]

Essaie de lancer un udevmonitor.

Tu peux écouter les uevent de ton kernel qui vont te renseigner sur les minor et major numbers. Exemple
udev se base dessus pour populer ton /dev
Ecouter les uevents de la sorte est un moyen de charger tes devices dynamiquement.
udemonitor est plus une interface de debug, si tu veux aller plus loin il faudra mettre les moins un peu plus dans le cambouis.
Mais cela peut être déjà une piste pour connaître éventuellement les minor et major numbers si tu ne les connais pas. Maintenant ils se retrouvent dans le code du kernel, donc c'était plus une astuce pour les connaître rapidement si tu n'arrives pas à les trouver dans le source du kernel.

[totolito]

Salut Aquanum!


MErci pour ta réponse, mais il semble que mon driver de dalle n'utilise pas les major/minor mais passe par le mécanisme de /dev/input en appelant les fonctions input_report_abs().

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

Code :

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

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

Je prospecte ces infos actuellement...
Il semble que je doive faire un bind de mon driver vers mon device... Je cherche je cherche...


;-)

[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

[Aquanum]

Héhé ! Ça c'est de la sacré recherche !
Ravi de savoir que tu t'en es sorti ! En tout cas merci pour le feedback

C'est vrai que la tslib est plutôt sympa pour cette utilisation ! J'ai un peu bidouillé avec pour le concours de linuxembedded.fr sur mini2440 mais je n'ai pas été super loin faute de temps libre hélas.

Bon courage pour la suite

[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, j'ai trouvé ça je ne sais plus trop où, mais le voici en pièce jointe. Par contre, il semble que la dernière release de tslib intègre le support MT (multitouch). Je viens de la compiler mais pas encore testé.

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:

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
22
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 conseillé de ne pas s'en passer !! Sinon tu es obligé de poller en permanence le mxt224, pas bon!
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]

Je confirme que la dernière release de la tslib supporte le multitouch.

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

[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

[totolito]

Puisque le sujet est abordé sur un autre topic, je prierais à ceux qui souhaitent apporter aide, questions et commentaire de le faire sur celui-ci:

http://www.developpez.net/forums/d11...r/#post6296846

Merci