Citer : Posté le 27/04/2018 02:54 | #

---

Comme dit plus haut, effectivement, p7 est à l'état de chantier et il faut que je réimplémente pas mal de choses de façon propre dans la libcasio concernant le protocole de communication. Je me suis pas mal concentré sur la mémoire principale de base, les archives etc, et moins sur les fichiers de stockage, voilà pourquoi. Mais j'y travaille !

Concernant le niveau de zoom de p7screen, ça m'étonne, c'est à 8 normalement… si tu pouvais m'envoyer le Makefile.cfg en réponse ou via MP, je t'en serais reconnaissant (normalement le zoom par défaut apparaît aussi dans p7screen --help). Concernant les signaux qui ne répondent pas, ça c'est parce que la SDL2 catche les signaux pour les retourner en tant qu'évènements. Je n'ai pas encore trouvé de façon propre pour gérer ça, il faut que je me penche sur la question de façon plus sérieuse. Et p7screen ne se met pas en boucle infinie, il s'est probablement connecté avec ta calto et est en attente du prochain paquet

Autrement, je travaille aussi sur une autre syntaxe pour p7, plus verbeuse et basée sur le positionnel que la précédente. L'idée principale était de pouvoir combiner des actions différentes dans une seule exécution de p7, et de pouvoir adapter l'interface à p7mcs (l'équivalent de p7 pour la mémoire principale). Les mauvaises langues diront que ça s'approche du SQL, mais je leur rétorque qu'il n'y a pas encore de conditions ni de boucles dans ma syntaxe (et qu'en plus elle est trop cool). Voici quelques exemples pour vous donner un aperçu de ce que ça va donner :


Affiche de l'aide concernant les sous-commandes disponibles.


Optimise la mémoire de stockage (sur la flash) et liste les fichiers sur la carte SD.


On commence à entrer dans du tordu. Ici, la connexion se passera, comme le préfixe on serial /dev/ttyUSB1 setting 115200N1 l'indique, sur la connexion série dont la liaison est disponible sur /dev/ttyUSB1 (interface USB-série que j'utilise pour me connecter à la calculatrice), sur laquelle on se met d'accord avec la calculatrice pour définir les paramètres de connexions à 115200 bauds, pas de parité, un bit de stop. Sur cette liaison, on envoie le fichier disponible localement sur ~/addin.g1a qu'on renomme ADDIN.g1a sur la calculatrice et qu'on place dans le dossier ADDINS.

De plus, le type de liaison parle aussi du protocole « applicatif » (les protocoles propriétaires utilisés pour les calculatrices CASIO ne sont pas vraiment pensées pour rentrer dans des couches du modèle OSI, mais supposons), donc ici par exemple, serial représente le protocole 7 au-dessus d'une liaison série et usb représente le protocole 7 au-dessus d'une liaison USB. On pourrait tout à fait imaginer l'introduction d'autres types, comme legacy, pour le protocole legacy, ou afx pour les AlgebraFX/Graph 100.


L'avantage de cette syntaxe est qu'on peut même faire varier la liaison sur plusieurs sous-commandes. Ici, on commence par définir la couche de liaison comme étant une liaison série sur /dev/ttyUSB1, où on définit les paramètres de connexion 115200 bauds, pas de parité, deux bits de stop, et où on dit à p7 de ne pas terminer la connexion pour qu'on puisse la reprendre plus tard. Sur cette liaison, on affiche la version de l'OS et l'ID de la calculatrice (product ID).

Ensuite, on change de liaison pour une liaison USB, et on récupère et affiche le nom d'utilisateur sur cette nouvelle liaison (la première liaison est fermée).

De plus, mais ce n'est guère plus qu'une idée pour le moment, j'aimerais implémenter une exécution de scripts externes avec quelque chose du type :


Mais j'ignore totalement ce qui peut se passer si je met un préfixe de liaison, etc. Je me pencherai sur la question quand j'aurai fini d'implémenter le reste.

J'espère avoir pu vous donner une idée de la puissance de la syntaxe que j'implémente au travers de ces quelques commandes. J'essaierai, quand j'aurai fini d'implémenter un décodeur correct pour cette syntaxe, de faire quelque chose de rétrocompatible avec les anciennes options et sous-commandes (en fait, celles du p7 actuel) pour que vos scripts ne soient pas complètement à la ramasse. De plus, on m'a également suggéré de proposer la gestion de chemins complets comportant nom, dossier et appareil de stockage, du type crd0:dossier/fichier.ext, que j'aimerais aussi implémenter en plus de la forme décomposée que j'ai un peu présentée au-dessus. Normalement tout ça devrait cohabiter de façon pas trop mauvaise

---

Citer : Posté le 27/04/2018 13:38 | #

---

À l'époque de la libp7, le callback pour afficher une frame pouvait retourner un code d'erreur pour que la fonction qui a pris le contrôle du fil d'exécution puisse le rendre. Mais en vrai, ça ne me plaît plus que la fonction qui reçoive les frames prenne le contrôle du fil d'exécution, et c'est pas vraiment dans la logique de la façon dont ça marche pour la Prizm/G90+E, donc je vais changer ça.

EDIT : ah mince, je me souviens de pourquoi j'ai fait ça. Bon, va falloir jouer avec.

Ajouté le 27/04/2018 à 15:37 :
J'ai fait ce que j'ai dit plus haut, et corrigé quelques petits trucs au passage, donc p7screen devrait marcher encore plus like a charm qu'avant, en récupérant et adaptant quelques trucs de la libp7 d'ailleurs. Je t'invite à re-tester

---

Citer : Posté le 03/05/2018 22:51 | #

---

Bon, récemment, j'ai fait un peu de recherches concernant le screenstreaming pour la Graph 90+E (et les autres plateformes par la même occasion), et je partage ici quelques conclusions que ça puisse resservir plus tard.

Concernant le format des paquets eux-mêmes : au-delà de ce qui est spécifique au protocole 7 (donc type 0x0B pour le screenstreaming), trois formats possibles : TYP01, TYPZ1 et TYPZ2.

Le TYP01 n'a aucun sous-header et est directement suivi d'une image de 128x64 pixels au format casio_pictureformat_1bit (1 bpp, de haut en bas, de gauche à droite, et comme ça tombe pile on n'a pas à se poser la question des fill bits).

Le TYPZ1 et le TYPZ2 ont un sous-header qui est quasiment le même pour les deux, au premier champ près :
- taille (6o pour le TYPZ1, 8o pour le TYPZ2) : taille en octets de ce qui suit le sous-header, champ de contrôle exclu, en base16 (appelé « ASCII-HEX » par Simon Lothar, appellation qui est restée dans la communauté) ;
- largeur (4o) : largeur (hauteur) de l'image en pixels, en base16 ;
- longueur (4o) : longueur de l'image en pixels, en base16 ;
- un "1" en ASCII (1o) ;
- format d'image (3o).

Les formats d'images connus sont :
- RC2 (casio_pictureformat_16bit) : 16 bpp, de haut en bas, de gauche à droite. R5G6B5.
- RC3 (casio_pictureformat_4bit_rgb) : 4 bpp, de haut en bas, de gauche à droite. R1G1B1 puis un bit de déchet.
- RM2 (casio_pictureformat_2bit_dual) : deux fois une image comme pour le TYP01, mais avec des dimensions différentes.

Voyez libcasio/picture.h pour les formats d'images gérés par la libcasio en long et en large.

Pour ce qui concerne le SCSI : comme le révèle cette page de chez Cemetech, en plus des commandes de base qui permettent à la calculatrice de se comporter en mode « clé USB », la calculatrice implémente des commandes supplémentaires… qui permettent d'accéder à un flux avec un simili-Protocole 7.00 dessus.

Grosso modo, trois commandes propriétaires : 0xC0 pour voir s'il y a des données (le retour contient le nombre d'octets disponibles), 0xC1 pour recevoir des données (dont on précise la quantité dans la commande), et 0xC2 pour envoyer des données.

Pourquoi est-ce que je parle d'un simili-Protocole 7.00, alors que le wiki a l'air de dire que c'est le Protocole 7.00 ? Parce que le paquet envoyé par Screen Receiver, l'appli de BrandonW sur Cemetech, envoie un paquet qui ressemble à du protocole 7, mais n'en est pas :


Le premier byte est un type valide (ACK), les deux derniers caractères correspondent bien au « checksub » ('%02X'%((0 - 0x30 - 0x32 - 0x30 - 0x30 - 0x31) % 256) == '0D'), tout ce qui n'est pas le premier byte est en ASCII, ça c'est bon. Mais deux choses me chiffonnent :
- le fait qu'il s'agisse d'un ACK étendu d'après le sous-code (02) mais qu'il n'y aie pas de données (0 juste après) ;
- le dernier '0' avant le « checksub ». Il n'a rien à faire là, mais sans lui le « checksub » est invalide. C'est surtout lui qui me fait me dire que c'est une évolution du Protocole 7.00 et non le protocole lui-même.

Pour en savoir plus, j'enquête parmi ce que je trouve comme documentation, et j'ai demandé à Lephenixnoir de me faire un dump avec le Screen Receiver de CASIO et sa Graph 90+E, on verra ce que ça donne

---

Citer : Posté le 04/05/2018 19:55 | #

---

Pour ce que j'avais fait comme recherches, non, ce n'est pas possible sous Microsoft Windows. C'est pour ça que je cherche à gérer les deux drivers, CESG502 et WinUSB, en fait.

Et CESG502 est pas génial. Déjà je n'ai pas trouvé comment savoir si c'est lui ou non, donc je n'ai pas l'impression qu'il n'y aie de GUID associé (ou peut-être que si, mais je n'ai pas trouvé comment le récupérer). Ensuite, pour les opérations de lecture, contrairement à la grande majorité des drivers proposant un flux, il ne faut pas lui donner un buffer de la taille qu'on veut lui demander, mais d'une taille supérieure à ce qu'on peut recevoir au maximum.

J'avais posté un topic sur le forum du MSDN, mais je n'ai pas eu de réponse convaincante. Si tu trouves, fais-moi signe

---

Citer : Posté le 22/09/2018 12:22 | #

---

J'ai quelques soucis d'installation sur Fedora 28.
N’ayant pas les packages: libusb-1.0-0-dev && libsdl1.2-dev avec yum (ou alors je suis bigleux) j'ai les ais DL manuellement et foutu dans un repo.
Après avoir installer libusb (1.0.22) et sdl (1.2.15) impossible d'installer libp7-3.0


Au passage, est-ce qu'il est possible d'installer seulement p7 et non p7screen ? Parce que j'en ai pas besoin et visiblement c'est ça qui foire l'installation (d’ailleurs j'avais déjà eu ce problème sous Arch mais comme j’étais passé par yaourt bah p7 c'est installer et p7screen à foirer complet).

Citer : Posté le 22/09/2018 12:40 | #

---

Merci
Je suis aller un peu plus loin mais maintenant p7utils ne trouve pas <libp7.h> alors que je n'ai pas eu de probleme lors du make install de libp7

Ajouté le 24/09/2018 à 15:18 :
Bon j'ai essayé de tout ré-installer mais impossible de trouver comment régler ce problème...

Citer : Posté le 24/09/2018 15:21 | #

---

a2x fait partie d'asciidoc. C'est pas précisé dans le README de l'époque ?

---

Citer : Posté le 24/09/2018 16:09 | #

---

Parmi les dépendances de construction des p7utils se trouve sans doute pkg-config (« README » veut dire « Lisez-moi » ). Je t'invite à l'installer et à refaire make.

Sous Fedora et distributions dérivées, d'après mes recherches, yum install pkgconfig devrait le faire.

---

Citer : Posté le 24/09/2018 16:21 | #

---

Oh tiens, effectivement. Je pensais pas que je faisais autant n'importe quoi à cette époque. Pardon pour ça !

Si tu fais pkg-config libp7 --cflags manuellement, qu'as-tu comme sortie ?

---

Citer : Posté le 24/09/2018 16:35 | #

---

Hm, ça veut dire que le chemin par défaut où la configuration du paquet libp7 n'est pas géré par Fedora. Il a été installé par défaut dans /usr/lib/pkgconfig/, de là tu as deux possibilités :

- le copier dans l'un des dossiers par défaut de pkg-config, que tu peux obtenir via pkg-config --variable pc_path pkg-config.
- ajouter le dossier /usr/lib/pkgconfig/ à pkg-config avant de l'exécuter, en utilisant export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/lib/pkgconfig (à ajouter dans ton .profile, .bashrc, .zshrc ou autre pour un ajout permanent)..

---

Citer : Posté le 20/09/2019 14:08 | #

---

Dsl pour ce détérage d'une année mais j'ai ça: The command is unsupported by the calculator