Forum TI-Planet.org

Bonjour!
Je voulais savoir si c'était possible de faire un programme qui permette d'utiliser la Nspire CX (/CAS) comme périphérique d'entrée "natif". Il faudrait qu'elle puisse émuler un clavier, de sorte que si on la branche à un autre appareil qui gère les claviers, on ait un véritable clavier physique, et sans rajouer un seul driver.

Il ne faut pas oublier que, étant donné qu'on risque de la brancher sur des appareils portables, il faut aussi faire en sorte que l'alimentation via USB soit coupée (sinon, la Nspire ou l'Hôte se vide prématurément).

C'est possible ? Quelqu'un veut se lancer ? Franchement, si j'avais les connaissances nécessaires, je m'y serais déjà mis, mais je n'y connais rien à propos de la Nspire et de Ndless. J'avais fait du C il y a fort longtemps, et je doûte que ça m'aide, vu le peu que j'ai fait (arrivé aux allocations manuelles de mémoire, sur le tuto du Site Du Zéro).

Il faudrait déjà rajouter le support USB dans Ndless...

Après on verra

Non, il suffit de faire du reverse engineering pour envoyer un faux device descriptor et ainsi signaler un clavier.
Ensuite, rien de plus simple, on émule un comportement de clavier normal sur la Nspire !

L'intérêt serait quand même limité...

le solutionneur wrote:Non, il suffit de faire du reverse engineering pour envoyer un faux device descriptor et ainsi signaler un clavier.
Ensuite, rien de plus simple, on émule un comportement de clavier normal sur la Nspire !

L'intérêt serait quand même limité...

Pardon, j'ai entendu "simple" ?
Il y a une énorme différence entre "simple" et "faisable".

La partie émulation du protocole est simple.
Suffit de recevoir le paquet, voir ce qu'on nous veut, envoyer un paquet de réponse. Et aussi envoyer soi-même ds paquets.

C'est le côté reverse engineering qui est le plus difficile.

Je ne comprends pas l'intérêt, là, surtout que le clavier de la TI-Nspire n'est pas terrible.
Un truc qui pourrait utile, en revanche, ce serait de lui donner le comportement de clé USB afin de pouvoir effectuer des transferts sans logiciel.

Je sais que ça peut paraître étrange, mais je pense que pouvoir avoir des touches physiques sur n'importe quel appareil c'est quand même super pratique, même avec un clavier ABCD. Je ne sais pas si mon avis est partagé, mais je ne supporte pas les claviers tactiles. Et puis ça permet de faire une sorte de télécommande pour PC/autres, certes filiaire, mais ça tient bien dans la main.

Donc, la faire passer pour un clavier "natif", c'est faisable, ça. Et couper l'alimentation, c'est possible?


(Pour lui donner le comportement de clef USB, je crois qu'il faut percer les secrets du file system, et je crois que c'est pas gagné. )

J'imagine que personne ne veut se lancer dans la conception de ce genre de programme..?

Donc, la faire passer pour un clavier "natif", c'est faisable, ça.

Oui, surtout qu'on fait passer une 89T pour un clavier USB tout à fait honnête, grâce à Linky.

(Pour lui donner le comportement de clef USB, je crois qu'il faut percer les secrets du file system, et je crois que c'est pas gagné.)

Il n'y a pas de driver tiers libre pour FlashFX / Datalight Reliance, mais on connaît les APIs pour accéder au FS.

J'imagine que personne ne veut se lancer dans la conception de ce genre de programme..?

Si, mais plus exactement, après le design, personne n'a le temps de finir le reverse-engineering et le codage de ce genre de programmes

Oui, surtout qu'on fait passer une 89T pour un clavier USB tout à fait honnête, grâce à Linky.

Mais la 89T est quand même plus ouverte qu'une Nspire, et puis le support de l'USB par Ndless est encore partiel et en bêta...

Il n'y a pas de driver tiers libre pour FlashFX / Datalight Reliance, mais on connaît les APIs pour accéder au FS.

Ca, j'm'en doutais, vu que j'utilise TILP !

Si, mais plus exactement, après le design, personne n'a le temps de finir le reverse-engineering et le codage de ce genre de programmes.

Et si je me lançais directement, comme ça, dans un projet de programme pour Ndless? Qui corresponde à mon besoin? Comme j'avais fait pour LuaCS ?
Ouais, sauf que là, c'est un autre niveau, parce que je n'ai aucune idée de comment émuler un clavier en C, et ensuite pour gérer l'USB...

En fait, le "design", y'a rien à faire, la calculatrice n'a rien à afficher. Comme ça a été dit plus haut, il s'agit d'envoyer à l'hôte un "code signé clavier", avec le caractère tapé (ou la touche).

Et j'aimerais bien que vous m'expliquiez ce que vous appelez le "reverse-engineering", parce que ça ne me dit rien, ce truc là.

Il n'y a pas de driver tiers libre pour FlashFX / Datalight Reliance, mais on connaît les APIs pour accéder au FS.

Ca, j'm'en doutais, vu que j'utilise TILP !

En fait, ça n'a rien à voir avec TILP
TILP communiquait avec les Nspire bien avant qu'on exécute du code natif sur les Nspire. Grâce au travail de reverse-engineering de Romain Liévin, qui a sniffé les URBs qui passaient entre TINCLS et la machine, TILP parle (plus ou moins bien...) le protocole USB propriétaire "NavNet" de la machine. Dans l'implémentation de NavNet, il y a des appels aux fonctions Nucleus d'accès au filesystem (c'est de celles-là que je voulais parler).

Sans vouloir dénigrer le travail réel que tu as fait pour LuaCS, l'implémentation d'un host USB HID est en effet d'un tout autre niveau.

Et j'aimerais bien que vous m'expliquiez ce que vous appelez le "reverse-engineering", parce que ça ne me dit rien, ce truc là.

D'une façon générale, le reverse-engineering (en français, "rétro-ingéniérie") consiste à décortiquer et analyser, par tous les moyens, le fonctionnement d'une construction matérielle ou logicielle (plus ou moins) inconnue, et non nécessairement électronique ou informatique (on peut très bien faire du reverse-engineering mécanique).