Voilà comment la gestion de HIDPB va se présenter :
- Il y a quelques hooks additionnels AMS-specific pour que ce soit pratique à utiliser, il y a donc un test de version d'AMS (même si tout ça est retrouvé dynamiquement autant que possible)
- Il y aura 2 parties : un hook à installer, et une lib statique pour les programmes clients. Le hook s'occupe de prendre en charge les périphériques de façon transparente, et la lib statique permet au programme client de savoir quel périphérique est actuellement connecté, et d'installer un handler d'évènements.
- L'handler est prévenu lors d'un mouvement de souris, d'un clic, d'un appui de touche, d'un débranchement, ou d'un branchement de périphérique. Il reçoit en paramètre une structure contenant un champ 'type' indiquant le type de l'évènement, et une partie données spécifique à l'évènement. Dans le cas d'un branchement de périphérique, le type du nouveau périphérique est indiqué. Pour les mouvements de souris, les champs sont de type delta_x, delta_y, ...
- La seule condition pour que le bazarre fonctionne est que l'AI3 ne soit pas masquée. Lorsqu'un clavier est branché, les appuis de touches apparaissent dans la keyboard queue d'AMS (donc dans n'importe quelle app/flash app via ngetchx & co, comme le clavier vendu par TI). Il n'y a pas un tel comportement pour la souris, j'ai testé, c'est complètement stupide
(mis à part dans l'écran Graph à la rigueur).
Si le programme client ne masque pas / ne redirige pas l'AI1, il peut passer par ngetchx()/kbhit() (l'handler décrit plus haut est optionnel). Sinon il doit passer par l'handler, et prevenir la lib de ne pas faire suivre les appuis de touche dans la keyboard queue (ça permet d'eviter un appui de touche résiduel lorsque l'AI1 sera démasqué).
- Un seul handler à la fois peut être installé (ie pas d'installation d'handler en hook d'évènements d'AMS), à moins que quelqu'un veuille développer une appli intéressante qui dépendrait de ça.
- Concernant l'équilibre entre code dans le hook et code de la lib statique : s'il y a beaucoup de code dans le hook, la consommation en RAM sera plus élevée tant que le sera installé, mais la lib statique sera plus petite. L'inverse est choisi, puisque la Titanium a proportionnellement plus de Flash que de RAM.
- Pour la tuyauterie interne de communication entre le hook et la lib au setup : c'est dommage qu'il n'y ait pas de lib de gestion de base de registre, ce serait un projet utile. Dans notre cas, soit on se base sur un fichier, soit le hook s'installe comme hook d'évènements, et la lib utilise EV_defaultHandler() pour communiquer (ça ne concerne *que* le setup).
Des remarques/suggestions ?
