Parmi les projets tombés en désuétude, il y eu mon dernier GUI en date pour plate-forme PC. Mais pour des raisons techniques, celle-ci devait se faire avec la même technologie que celle choisie pour faire de la vidéo de fou: directfb. Rien à voir avec directX (enfin, presque rien): c'est une bibliothèque permettant de manipuler le plus directement possible l'abstraction de mémoire vidéo (fbdev) sous Linux.
J'avais déjà fait quelques petits programmes de test avec mais ici je me suis retrouvé évidemment à vouloir tester l'application qui était derrière, de manière systématique, chose qui était impossible à travers HDMI/USB ... (enfin, disons peu pratique plutôt qu'impossible).
dfb->WaitForSync(dfb) (☑) et DSCAPS_PRIMARY sans DSCAPS_FLIPPING avec un dfb->SetCooperativeLevel (dfb, DFSCL_EXCLUSIVE). Tout venait de là. En monitorant un peu les timestamps obtenus au moment du retour de WaitForSync, il devenait possible de se la jouer "Future Crew" et prédire dans combien de temps le retour d'écran allait avoir lieu. Mieux: je pouvais même prédire quelle portion de la VRAM était succeptible d'être utilisée par l'écran, et donc quelle portion de cette même VRAM pouvait être modifiée sans produire d'artefacts visibles.
Le site que j'utilisais jusque là n'est plus trop en vie... mais le code devrait toujours être présent sur github ... encore que les dates des dernières mises à jour semblent crier "do not use for new designs". Dommage.
Et sur devterm ? est-ce que ça fonctionnerait ? le package est disponible, son package 'bin' aussi ... par contre, j'ai systématiquement un 'segmentation fault' quand j'essaie d'utiliser les outils comme dfbshow ou dfbplay (juste après l'initialisation du joystick). Même dfbinfo n'y échappe pas. Il y a un /dev/fb0 sur l'appareil, fonctionnant en 480x1280 selon /proc/fb...
Voilà, c'est ce qu'il y avait à en dire en 2021, mais je note ce matin que quelqu'un s'est lancé dans directFB2 ... il faudra que je regarde ça de plus près ;)
No comments:
Post a Comment