Auteur: Yves Martin Date: À: ML Guilde Sujet: Re: port série
Selon "alain.dieudonne" <alain.dieudonne@???>:
> lorsque la fenêtre Wine qui contient MapStore est active, il suffit que
> je bouge la souris (sur la fenêtre active) ou que j'appuie sur une
> touche du clavier pour avoir de nouveau les données GPS comme si une de
> ces actions "réveillait" le port série.
>
> Je pense que le problème est causé par wine, mais je ne le connais pas
> encore assez bien. Les manpages ne sont pas très détaillées sur le sujet
> et le site en anglais ne me facilite pas la chose...
N'abime pas ton hardware - je suis quasiment certain que c'est un problème
de software dans Wine.
Tout dépend de la façon dont MapStore interroge le GPS: en polling ou sous
interruption. Et si Wine est capable de demander le même service au noyau
Linux sur le device (/dev/ttyS0)
Pour le mode "interruption", un programme natif est bloqué en lecture sur
le device et est révéillé par le kernel lorsqu'un caractère arrive.
Pour le mode "polling", un programme fait une lecture non bloquante et
boucle s'il n'y a rien.
Dans ton cas, tout le problème est de savoir comment Wine fait la
correspondance entre les fonctions Win32 et la lecture d'un device Linux.
Si des interruptions logicielles comme le mouvement de la souris provoque
la lecture du port, la piste du polling est forte - mais il est possible
que pour éviter de consommer les ressources (CPU qui frise le 100%), Wine
ignore le polling ou qu'un autre appel système suspend le processus - et
donc qu'il n'est pas réveillé par l'arrivée de caractères sur le port série.
Une solution "crade" serait de faire un script qui a fréquence régulière
envoie un signal inoffensif non masqué (à tester mais pourquoi pas SIGINT)
au processus MapStore/Wine. Cela aura pour effet de réveiller le processus
qui lira le port série... On peut aussi envoyer des événements X11 mais c'est
moins simple.
Cela me fait penser au jeu "Nebulus" sous Linux qui bouffe 100% de CPU
alors qu'il n'y a rien à faire (une petite musique, qq rafraîchement d'écran,
attente d'événements clavier): pourquoi ? Je pense que le développeur a fait
une grosse boucle avec du polling partout au lieu de faire des lectures de
clavier par interruption avec des rafraîchements d'écran et musique sous
interruption temporelle par timer - le kernel ferait dormir le processus presse
tout le temps dans ce cas - mais c'est sur que c'est plus dur à coder.
Dès que j'ai qq heures, je prends les sources et je fais un patch ;)