Cherche spec du protocole USB du Mir:ror

Bonsoir,

De nouveau, il me reprend l'envie de bricoler autour de mon Mir:ror. Cette fois, j'aimerai jouer avec une fonction que je crois deviner : la gestion des "chorégraphies" du Mir:ror.

Sauf que voilà, je n'arrive pas à mettre la main sur une doc un peu complète. En fouillant les projets autour du Mir:ror, je vois bien qu'il y a une telle fonction (reflektor, mirlite...). Sauf que je n'ai pas encore compris comment ça se met en oeuvre.


Quelqu'un a des conseils pour avancer sur le sujet ?
Une piste pour faire du reverse-engeneering?
Ou juste une expérience à partager lorsque le Mir:ror était pleinement fonctionnel ?


Merci d'avance pour toutes les aides.

Dans le code de mirlite, on trouve un lien :
http://2.bp.blogspot.com/_NcFT1bJ_drE/SPRnEuvht3I/AAAAAAAABek/GIx05u3bGz8/s1600-h/MirrorFactoryTestTool.jpg

Je serai bien content de trouver ce "Mirror factory test tool".

La perle de la soirée : après des heures à fouiller et refouiller Internet, je tombe sur :
http://websvn.ow2.org/log.php?repname=wildcat&path=%2Fsandbox%2Fmahmoud%2FHouseAutomation%2Flib%2Fmirware.tar.gz&rev=462&peg=462


Une copie de la version 0.9.9 de mirware. Je ne sais pas s'il y a des collectionneurs dans le coin, mais c'est un truc à sauvegarder.

merci pou ce lien Si Moon peut le recupérer dans le coffre à surprise du forum..

Ouaip, ben pour t'aider Guyou un lien que tu dois certainement avoir :

http://blog.nomzit.com/2010/01/30/decoding-the-mirror-comms-protocol/

Sinon, j'ai tenté l'expérience de lancer le bazar sur ma machine (avec réinstallation des libs en 32bits) et ben à part une belle erreur QtScript il plante :
./mirware
QScriptEngine: Must construct a Q(Core)Application before a QScriptEngine
Abandon


Je pense que je vais devoir sortir le bus pirate et certainement retrouver une application qui tourne ailleurs que sous Linux pour pouvoir faire tourner l'ensemble...

Note aussi pour plus tard : modprobe usbmon + wireshark + activité == reverse possible.
Car wireshark est capable de snooper l'USB....

Une idée lancée en privé serait de demander la libération du code de mir:ror / mirware... Est-ce que celle du nabaztag (de libération) s'est déroulée de manière fluide ou est-ce qu'il a fallu faire le forcing et si oui comment ? Vaste question n'est il pas ?

jcarnu a écrit:

Ouaip, ben pour t'aider Guyou un lien que tu dois certainement avoir :

http://blog.nomzit.com/2010/01/30/decoding-the-mirror-comms-protocol/

Ce site est intéressant à plus d'un titre. D'abord, il tente de faire une synthèse documentaire du protocole, ce qui est bien. Ensuite, il précise que si on fait des manips à l'aveugle, on va bricker nos Mir:rors.

Par contre, suite à toutes mes expériences, je ne pense pas que le format suive un format de longueur fixe, mais bel et bien un format dont la taille des données correspond à la longueur indiquée dans l'entête.
Du coup, j'ai amorcé une doc sur le protocole pour stocker mes découvertes : https://github.com/guyou/ref-lect/blob/master/doc/protocol.md
(la version actuelle contient bien peu par rapport à tout ce qu'on peut trouver comme info actuellement)

J'en profite pour indiquer que, supposant que mon idée d'utiliser Vala pour ce projet n'était pas idéale puisque cela restreint les contributions, j'ai exhumé un projet nommé reflektor (http://sourceforge.net/projects/reflektor/) qui est en C. Et comme son auteur ne répond plus, j'ai fait un clone sur GitHub : https://github.com/guyou/reflektor

Toutes les contributions seront étudiées avec le plus grand des intérêts.

guyou a écrit:

Toutes les contributions seront étudiées avec le plus grand des intérêts.

Tu veux dire les pull requests ?

Sérieusement, pourquoi pas. Il faudrait que je lise plus attentivement l'ensemble des choses. Le choix du C pourquoi pas non plus, après j'avais commencé des choses en python également mais c'est pas du tout publiable tellement c'est embryonnaire. Donc partons sur le C, ça me paraît être une bonne piste pour tenter des contribs.

Afin de faire des expériences facilement, je me suis mis en tête de faire un "shell" pour envoyer des commandes arbitraires sur le Mir:ror. Confronté au fait que j'avais deux entrées à surveiller, j'ai employé poll. Mais je suis confronté à un comportement étrange : j'ai le sentiment que poll reste bloqué lorsqu'il interroge le périphérique USB.


Pourquoi cette impression ? Car en l'état, mon code ne réagit pas au entrées clavier. Pourtant, si je ne met que STDIN dans mon poll, l'entrée clavier est bien détectée et traitée. De même, si je met une valeur de timeout >100, le poll reste bloqué indéfiniment, ce qui n'est pas le comportement attendu. Et plus surprenant, si je saisi une commande et que je déclenche un événement (ajout tag, retournement du mir:ror) alors cet événement est traité, et la saisie clavier aussi.


Bref, si vous avez une explication, je suis curieux de la connaître. Mon code : https://github.com/guyou/reflektor/tree/feature-shell
La procédure de test :
1) activer "sudo ./src/reflektor_shell"
2) saisissez "0101" (pour la commande d'interrogation du device ID)

Ignorez-moi, je suis un imbécile. Ce n'est pas poll qui est bloqué, mais plutôt le Mir:ror qui réponds qu'il y a des choses à lire, alors que ce n'est pas vrai, et le read est bloqué.

Humpf, c'est bizarre ce que tu dis car le cat /dev/hidraw est clair : il y a toujours un truc à lire....
Ceci étant là où je suis il n'y a pas de mir:ror donc je dois faire des suppositions sur des souvenirs datant d'il y a 15 jours ce qui est titanesque pour moi

jcarnu a écrit:

Humpf, c'est bizarre ce que tu dis car le cat /dev/hidraw est clair : il y a toujours un truc à lire....
Ceci étant là où je suis il n'y a  pas de mir:ror donc je dois faire des suppositions sur des souvenirs datant d'il y a 15 jours ce qui est titanesque pour moi

J'ai dit de m'ignorer !!!


En fait, je suis un parfait idiot, le read n'est pas bloqué, c'est le reste du code qui part dans une lecture sans fin en attendant autre chose que "\0". Bref, je maîtrise mal le code et le device, aucune chance de m'en sortir sans creuser un peu.

Dans mes souvenirs, quand j'avais commencé à coder un truc pour le mirror, c'était en utilisant libmirror en C sous Windows...
Il prend (quasi) tout en charge (c'est lui qui est utilisé par ref:let il me semble)...
Donc normalement en lisant le code de libmirror (et en débuggant "un peu"), il doit y avoir moyen de repondre le protocole sans devoir jouer à analyser les paquets...

Là j'ai rien sous la main mais j'peux regarder voir si j'retrouve ça...

BigPanda a écrit:

Dans mes souvenirs, quand j'avais commencé à coder un truc pour le mirror, c'était en utilisant libmirror en C sous Windows...
Il prend (quasi) tout en charge (c'est lui qui est utilisé par ref:let il me semble)...
Donc normalement en lisant le code de libmirror (et en débuggant "un peu"), il doit y avoir moyen de repondre le protocole sans devoir jouer à analyser les paquets...

Là j'ai rien sous la main mais j'peux regarder voir si j'retrouve ça...

Oui, j'ai relu pas mal de code existant pour comprendre un peu plus. Je me suis aussi documenté sur le protocole HID et j'ai même lu une partie du code source du driver Linux. Et du coup, j'ai enfin compris l'origine d'une constante magique : 64 octets par trame.

Du coup, j'ai pu recoder la base du protocole de comm. Youpi !


Oui, bon, j'ai pas vraiment fait progresser la science, mais moi j'ai compris un truc. c'est bête à satisfaire un geek.

Heu si vous trouvez coment changer les couleurs et ou les sons, vous allez intéressés beaucoup de monde. D'après le screen du début ce fut... possible. Perso j'ai 3 mirror à la maison sur mon ser veut et des pi. Tous sont utilisés sous linux en python.