 Alors, retourner au frambuffer. Le frambuffer du Linux peut s'assurer au passé. Mais même si le support du frambuffer, dans des softwares, est souvent pas maintenu, et parfois, juste remonte. J'ai proposé de retourner. Aujourd'hui, sur ces 3 softwares, on va pouvoir rassembler sur le frambuffer. Je vais commencer avec des exemples simples. Je vais vous remercier de base. Je vais vous montrer des outils. Je vais parler de 2 libraries qui peuvent être utilisées pour rassembler sur le frambuffer. OpenGL Rendering, avec le frambuffer, est adressé. Nous parlons de l'outil de frambuffer dans les frameworks multimédia. Nous allons couvrir les outils de graphique et des outils d'interface d'utilisation qui permettent d'utiliser un appareil de frambuffer. Allons-y. Pour vérifier que le frambuffer répond bien, un simple test à faire, c'est de rassembler le commandant de cad. Ici, nous rassemblons le frambuffer avec des valeurs randomes. En pratique, le code standard M-Map est utilisé. Nous avons déjà ouvert le file de frambuffer, pour obtenir un fil de descriptor. Nous passons ensuite au M-Map, afin d'appliquer le frambuffer dans la mémoire. Un pointeur est réveillé et est représenté ici, avec 3 RGB bytes par pixel. Nous n'avons qu'à remplir l'arrêt, afin d'appliquer sur la main. Donc, pour établir un rectangle bleu, nous remplirons l'arrière correspondante, par la setting de la valeur de 255 bytes pour le bleu et de 0 bytes pour le gris en noir. Nous l'avons compagnie, cet exemple avec GCC en randit. L'exemple a été réveillé avec très peu de lignes de code. Nous l'avons compagnie. Ok, nous avons le rectangle bleu. N'oubliez pas, c'est familier avec le frambuffer. J'ai su avoir un look sur l'app FB test, sur l'app FB Mark Software. Le software de l'app FB test propose l'app FB test, pour vérifier la couleur de randit. Nous n'avons pas un compositor, pour bouger sur les windows. Donc, je le prends pour spécifier, la taille, la position, la position de l'app FB, la position de l'app FB, la position de l'app FB, la position de l'app FB, la position de l'app FB, la position de l'app FB, la taille, la position, quand on commence les programmes, afin d'éviter l'avalaping. Dans ce code, il y a un file, un programme, dans lequel nous pouvons voir l'utilisation de Hema. Tout ceci, adressé dans ce truc, va travailler comme ça. Nous allons voir les outils basés sur le frambuffer. Tout d'abord, nous pouvons utiliser un terminal, un emulator, nommé FVpad. Nous type, pour exemple, le command FBSet, pour le print, les outils de frambuffer. FVpad permet de changer entre les tabs. Je change pour un autre tab, liste PDF files, pour exemple. Et je reviens au premier tab. Ça vous donne un petit overview de FVpad. Nous allons voir comment ça fonctionne. Le frambuffer est mappé. Le terminal DO, master en slave, est ouvert. Un nouveau processus est créé, dans lequel le shell est exécuté. Ensuite, tous les outils d'input sont envoyés à la slave et sont interprétés par le shell. Le master read le character de l'outil shell, qui est rendu dans le frambuffer. Les spectateurs d'image sont disponibles. Nous allons étudier FBI sur FIM. Ces spectateurs d'image commencent avec la mappé de frambuffer. La mappé est aussi décadée en utilisant des laboratoires communes, comme LibJPEG ou LibPNG. Et ensuite, le frambuffer est juste rempli avec le data décadé. Simple, où les brosses sont séparées. Nous allons démarrer NetSurf sur la page d'input et sur les links avec la page qui permet de faire des calibres de couleur sur le monitor. Notez que le masque que vous portez est managé par chaque programme qui se tourne sur le frambuffer. En NetSurf, nous étudions, par exemple, des textes dans le search arrière. Nous allons avoir un look dans l'implémentation. Pour NetSurf, le support de frambuffer est implémenté dans le Nib NSFB de l'Université. Quand ce laboratoire est installé, les fonctions de callback sont registrées. Durant NetSurf initialisation, les Linux initialisent les fonctions de callback dont le mapping de frambuffer. Ensuite, les fonctions de callback sont installées dans le frambuffer pour se tourner sur la page web. Pour les links, le mécanisme est similaire. Le M-Map est fait en initialisation et les fonctions de callback sont installées dans le MAP. Maintenant, je peux montrer les joueurs médias. Nous allons tourner FBFF qui est basé sur les laboratoires de FBFF pour la vidéo audio-deco. Nous allons tourner les joueurs et les joueurs. Les joueurs montrent l'utilisation de FBFF sur les interfaces de frambuffer. Nous pressons le bar Nous pausons les joueurs parce que quand il y a des programmes sur le frambuffer, il n'y a pas un manager donc ce n'est pas le cas. Toutes l'input sont procédées par toutes les applications. Pour FBFF, nous avons le M-Map call. Ensuite, le frambuffer est directement rempli avec les données de déco pour le display. Pour le M-Player, une structure avec des fonctions de callback est retournée. Une est la fonction de configuration pour la mapping de frambuffer. Et une autre est la fonction pour remplir le frambuffer avec les données de déco. La dernière touche que je vais vous montrer est FB PDF. La touche que j'utilise aujourd'hui pour cette présentation. FB PDF vient avec deux programmes. L'une reliant sur le laborat popular et l'autre reliant sur le laborat nouveau. Ces deux libraries sont commonly utilisées pour le management pour la même raison qu'on n'a pas un manager Windows quand il y a des programmes sur le frambuffer. En pressant la clé don nous allons à la prochaine page sur les documents. Comme d'habitude nous commençons avec un M-Map call. Le populaire ou la nouvelle PDF est utilisé pour obtenir la page PDF pour rendre. Et le frambuffer est rempli avec deux programmes. Les libraries peuvent être utilisées avec le frambuffer. La première qu'on va voir c'est Kero. Nous pouvons expérimenter avec des softwares Kero en note que deux différents projets avec le même nom existent. Le premier projet donne un simple programme nommé Kero FB qui nomme pas une ligne. Le deuxième projet donne des animations qui montrent les possibilités de Kero. Certaines informations pour développer avec Kero. Nous avons créé une surface target pour le frambuffer dans notre cas. C'est possible de passer le pointeur sur le frambuffer donc tous les drawings sont directement visibles. Mais selon ce que vous voulez faire, double buffering peut-être que dans ce cas toutes les drawings et les opérations sont faits dans une surface située dans un ram. Ensuite, un contexte est créé et le API de Kero est appelé pour les drawings. Pour le randonner vous pouvez utiliser des fonctions de Kero ou juste obtenir le pointeur de l'arrière et remplir le frambuffer avec ses contenus. Le deuxième pointeur de l'arrière est Ivas qui est partie de l'EFL projet. Le pointeur de l'arrière est disponible. Nous pouvons illustrer avec le programme d'expédite. Quand on utilise l'expédite on spécifie FB dans l'option d'utiliser l'engine de frambuffer. Nous pouvons jouer rapidement avec l'expédite et en développant avec Ivas. Nous 1erons ce qu'on appelle un canvas. Dans nos casques c'est un canvas pour le frambuffer que nous indiquons avec le FB string. La prochaine fonction lead à la mapping de frambuffer. Le drawing est fait avec l'API de l'EVAS pour voir l'expédite qui s'appelle la fonction de frambuffer. La prochaine section est évoquée pour ouvrir le randonner dans le frambuffer. Merci pour le project MESA 3D. Il est possible de faire OpenGL dans des softwares et de le randonner dans le frambuffer. Pour faire ça une interface nommée GLFBDEV peut être utilisée. Il consiste d'une extension OpenGL pour le frambuffer. Et c'est très similaire pour la bien-known GLX extension disponible pour l'ex-windows system. La nouvelle interface GL qui est plus générique est aussi supportée. Let's have a look sur la extension GLFBDEV. On peut trouver un exemple d'exemple en MESA demo ou en Yagir softwares. Nous allons faire un test GLFBDEV venu pour le MESA demo. Nous allons faire le Yagir. Un ordre sur le projet Yagir comme vous le verrez dans la présentation. Yagir est une autre implementation de la populaire OpenGL demo nommée GL mais qui supporte beaucoup d'autres methods de rendition d'OpenGL. C'est pourquoi quand on utilise Yagir nous spécifiquons GLFBDEV dans les options d'utiliser GLFBDEV extension. La première function de GLFBDEV nommée est GLFBDEV Crate Buffer dans laquelle nous passons le pointeur sur le frame buffer. La function de la set window est utilisée pour mettre la taille sur la position de la frame buffer erreur dans laquelle OpenGL est rendue. Ensuite un contexte doit être créé et attaché à le frame buffer. La function de la set buffer est appelée pour remplir le frame buffer avec le 3D drawing. Avec l'interface EGL c'est similaire. Un exemple d'utilisation est disponible dans les MESA demo ou en Yagir software. Nous allons gérer EGL TRI FBDEV et nous allons gérer Yagir. Mais cette fois nous spécifiquons EGL FBDEV dans les options d'utiliser EGL interface. On nage EGL FBDEV implementation qui était basée sur le legacy infrastructure de MESA. EGL implementation pour le frame buffer est basée sur Galiom infrastructure. La première function de EGL est l'interface de Galiom. Comme EGL est une interface générique si la bibliothèque de MESA sur votre système supporte d'autres plateformes comme X, Veylon ou VRM. On choisit la plateforme d'utilisation d'utiliser d'une plateforme EGL. C'est le fait de FBDEV et l'initialisation de la function est appelée. Si nous suivons la implementation de Galiom avec des trackers et des compagnons nous arrivons sur la mapping de frame buffer. La function d'utilisation de la surface Windows est utilisée pour installer l'air en l'air. C'est important de noter que la structure d'argument dépend de la plateforme. Avec la plateforme X X Windows est utilisée dans cette function. Comme GLF BDEV un contexte doit être créé et attaché à la frame buffer. Finalement la function d'utilisation de la frame buffer avec le 3D drawing. Je dois regarder le code source si vous voulez trouver plus des frameworks multimédia populaire des frameworks multimédia ont un output de frame buffer. Note que tout le display de la vidéo est fait en CPU quand vous utilisez la frame buffer. La première frame buffer qu'on va voir est FF MPEG. Pour chaque démon de la frame buffer on va commencer l'anime. La FF MPEG commande est créée avec beaucoup d'options mais la plus importante ici est la format spécifique pour l'output dans l'implementation. Le LibAV de la lab donne la support de la frame buffer avec une structure qui contient 2 functions utilisées durant le transcode. La function de la frame buffer et la function de la frame buffer pour remplir la frame buffer avec la vidéo. La seconde framework utilisée avec la frame buffer est Gstreamer. Nous roulons le tool pour construire un pipeline dans lequel on spécifie l'output. La version 0.10 de la nouvelle version de Gstreamer a commencé dans le démon. Comment ça fonctionne? Le élément de la FB DevSync est offert par un plugin dans lequel nous avons une fonction pour la map et une fonction pour remplir la frame buffer avec la frame buffer est Gzine. Un programme nommé FB Gzine est disponible pour tester ce support de la frame buffer dans l'implémentation. La Gzine ouvre la function de la vidéo avec la string FB afin d'utiliser la plugin de la frame buffer. Puis c'est toujours le même mécanisme appelant la map pour remplir la frame buffer. La fréquence multi-média que nous allons voir c'est VLC. Quand on ouvre la commande VLC on spécifie FB dans l'option d'utiliser la module de la frame buffer vidéo output. Ici c'est la même idée. Une plugin avec la support de la frame buffer est rempli. On va remplir la frame buffer. En suivant les détails sur la source code sont seulement pour information si vous voulez trouver un autre. Maintenant je vais présenter les laboratoires graphiques qui donnent une abstraction de la graphique de la frame buffer port. Glute permet de développer des programmes avec des codes portables. Depuis la frame buffer comprise seulement la rondeur Glute est utile pour l'input dans le programme. Nous pouvons expérimenter la frame buffer port de Glute. On va faire un project de Glute que nous avons vu avant. Il est créé avec Glute dans les options d'utiliser l'API de Glute. On peut voir que le curseur est managé par Glute. Et ici est la frame buffer port de Glute directement sur l'extension de Glute. Let's have a look on SDL. A popular library that provides a graphical on system layer for programming cross-platform applications. We can illustrate the frame buffer port of SDL. We are going to run to test coming from SDL. On the Yager's project uses SDL API. This time the mouse cursor is managed by SDL. On here is the Yager's. If we look the frame buffer port in SDL we can see the frame buffer mapping done at initialization. On when we call functions like SDL flip for updating the screen the frame buffer is written for OpenGL rendering that we have already seen is used by SDL. Now let's talk about user interface toolkits. The first one we are going to see is elementary which is part of the EFL project. We have already mentioned this project in the presentation. When we have talked about the Eva's growing library on its frame buffer engine in EFL architecture Eva's library but also Ecore library allow elementary to work on the frame buffer. We are going to run elementary test in which we can test many elementary widgets and we are going to run Yager's with EFL in the options to use an elementary GLView widget. We can play quickly with elementary test on here is Yager's in the implementation we can see the use of Eva's for drawing in the frame buffer. OpenGL rendering is based on the generic Eva's GL interface available in Eva's library. And for the frame buffer this Eva's GL interface directly relies on GL everyday extension. Another toolkit for creating graphical user interface is JTK. It relies on the color drawing library that we have seen before in this presentation. OpenGL rendering into a JTK widget is possible using JTK GL error interface. We can experiment the frame buffer part of JTK. To do this we are going to run JTK demo in which we can test many JTK widgets. And we are going to run Yager's with JTK in the options to use a JTK GL error widget. We can play quickly with JTK demo. And here is Yager's how it works. We have the frame buffer mapping done at initialization. And we can see the use of care for drawing widgets for OpenGL rendering GL JTK GL error directly realized on GL svdev extension. At the beginning of the presentation we have started with a blue rectangle. Then we have seen the care of drawing library. The OpenGL rendering and on this basis JTK. We have also tested the Gstreamer multimedia framework. So we have everything for running a high-level application on the frame buffer. I propose to show as example the WebKit browser for JTK. We are going to start the JTK launcher application available in WebKit JTK for running a WebGL demo on the HTML5 media player. The last user interface toolkit we are going to see is cute. The frame buffer port is available. Just note that depending on the version the implementation is based on QWS or on QPA infrastructure. We can illustrate the frame buffer port of cute by running cute demo in which we can test many cute widgets and we are going to run a gear with cute in the options QGL widget. We can play quickly with cute demo and here is the gear I am going fast on the next two slides that just detail where to look in the code for understanding the frame buffer port in cute but you know that we have the mmap call and for OpenGL rendering each gel is used by cute as we did for GTK I propose to show the webkit browser for cute we are going to start the cute test browser application available in cute webkit for running the same WebGL demo on the same HTML5 media player that we have seen before with GTK now you can imagine all kinds of applications running directly on the frame buffer before finishing just some extra informations if you need a compositor for managing multiple applications or if you have an application that really depends on X for example or for anything else it's still possible to use the frame buffer with graphics backend like direct FB X or alone but in this case all we have seen in the presentation is completely different for instance with X the GTK port for X will be used KRO drawing will be done in the X window GLX extension will be used for OpenGL rendering on everything will rely on the X window system that's why I'm saying it's another story and I will finish I will finish with a few words on the origins of this presentation everything started with a Linux from scratch distribution 15 years ago for understanding how graphics work and for playing with many a different graphics backend and I realized that some graphics backend won't be maintained anymore and now belong to the past that's why I created the IGFX back project in order to preserve them thanks very much for assembling all this information in one place great talk I have a question is when you I am writing directly to FB Dev how can you synchronize with V-Sync with the tube in practice sorry the question is with FB Dev how I synchronize with V-Sync if it's correct in practice I don't have to care about it everything I think it's managed at low level in the kernel drivers on the really low level hardware now I just call M-Map have the pointer on the flambuffer and just fill the question is if I ever try to run Firefox or Chromium Personally, no but I encourage you to try it could be a little complex but yes, Chromium was based at the origins on the WebKit Brothers so you are not too far away from that for Firefox it's completely different but I think you have some work before having Firefox running on it but I come back to this slide to this slide you still can use X on it will work on X on the flambuffer with all it's complexity yes I join the presentation and directing with a good overview of the thing it looks really fun to play with and quite simple to work with so the programmer in me is quite happy about that now I'm thinking about this and I'm trying to think of use cases and I can't see a few of them but I'm wondering I don't want to miss anything so I'm wondering what in your opinion are great use cases of the framework like when it's really really justified to use it so I have well understand the question the question is the use case of the flambuffer what in your opinion is like the good based example you know for use cases for sure the flambuffer is deprecated now it's KMS QRM and for the future it's it's it's it's it's it's it won't be the flambuffer for sure but the flambuffer on some unbedded systems sometimes if you don't have GPU or hardware you can still use the flambuffer for drawing on small TFT screen for example on that's right don't expect to have your 3D games d'enginir en travaillant comme ceci ou de jouer vos 4 clés de streams dans le frambuffer. Mais le frambuffer est juste, je pense, utile pour comprendre comment les choses travaillent. Par exemple, dans Mesa, le gallium est une structure. Pour des personnes qui ont un petit look dans ça, je pense que c'est complexe. Et comme le frambuffer est très simple, vous pouvez vraiment s'occuper de l'infrastructure de gallium pour comprendre comment ça fonctionne. Et aussi parce que le frambuffer est en pure software, vous pouvez différencier si une issue est venu du hardware ou de l'implémentation du software. C'est possible, mais pour sûr, j'ai commencé par dire, dans 3 softwares, le support du frambuffer est parfois retiré. Donc, vous devez regarder dans la log de cette histoire pour trouver le support du frambuffer sur un software. Sdl2, pour exemple, JTK3, pour exemple, n'a pas le support du frambuffer. Donc, oui, c'est un peu un problème. Merci. J'aimerais savoir, je suppose que vous avez écrit une application travaillant directement sur le frambuffer. Comment pouvez-vous obtenir une notification sur la résolution du frambuffer, en particulier si la résolution change ou si le moment a été détaché, etc. Parce que j'ai recently written application for an embedded device that uses the frambuffer to do a sort of PNC, to display remotely on the embedded device, a Beagle World Lab. And the other way I've seen to get information about the frambuffer is using an IOCTL and periodically calling to get information about the resolution. Yes. If I were understanding the question, the question concerns the resolution, if it changes during the program running, typically. Yes, it's a good question and in my case, the resolution, I always use a static resolution so I don't have this issue. And as a polling mechanism you have implemented, I think it's a solution to address this kind of use case. You first have to differentiate what you're calling framebuffer which is fbcon versus the new DRM KMS stuff which has the same features. You can literate a buffer, mem method and fill it with pixels exactly like you do at fbcon. Now, the difference is that with new DRM KMS you get to v-sync that and get rid of all the tearing, etc. and get that all correct, but otherwise can work exactly the same way. Now taking that into account, what's the use of this stuff, particularly I don't refill because I wrote that code and it supports fbcon because I wrote that code and I know it's single-buffered and it copies everything for the screen exactly as you've described. I've also got the DRM KMS code and the same application works as zero lines change, it just works. So a great use of it is run terminology which is a terminal emulator if you're TTY and if it's fbcon, it'll use fbcon, if it's DRM KMS, it'll use that instead and then you get everything v-sync and now you get a fast console where scrolling is fast. So have you ever done a make in TTY and gone and made a cup of coffee and come back? That doesn't happen now, it's fast because the kernel TTY doesn't play catch up. It just does every line really brute force and a really dumb scroll. Proper terminals will just play catch up and scroll instantly. You can also then in a terminal emulator play videos, look at images, etc. Play TYCAT, file that mp4 and play the video in the terminal emulator. It'll also do splits and tabs that if you want to do that you can run effectively kind of an i3 slash sway like GUI, just want a big terminal in your TTY and not need a display system at all. So that is a use case for that. If you assume that DRM KMS in the mem map model is effectively the same thing as fbcon which is what you're kind of strictly talking about. So if I understand correctly what you're saying is you open a terminal to a remote machine and suddenly I'm not going to use text anymore I can't pick up a graphic session to a remote... No! That one's local. It uses escapes to basically tell the terminal here's a file path to a URI to this thing and the terminal I'll load that for me and it just keeps just the URI in the actual terminal history thing so it doesn't give all pixels so it's kind of compact and it can rebuild so you can scroll through history and find all these things and reload them back in without keeping them in memory. So that's why it won't work remotely. Unless it's a URI which both systems can access like you actually URI but yeah, that's a use case but again it depends on your definition of frame buffer if you're being really strictly set on or DRM KMS. Where is the link between the GTY device frame buffer? How can I determine which frame buffer device corresponds to my current GTY where my program is running? Does it make sense? Yes here so here the system directly run on the frame buffer but you have a TTY it's supported by the kernel which provides the console the TTY on the frame buffer and I come back to when I feel the frame buffer with random values let's say I'm feeling my TTY with random values but in memory I have another TTY and I can still access I have only one from buffer and here I feel the second TTY with random values if I'm coming back to the first TTY I have the content of my command in it which is restored I can switch back but the driver rend as to the same frame buffer when you switch everything gets ruined but there is only one frame buffer Thanks Thanks