L'idée c'est d'utiliser EGL & GLES2. EGL c'est un API standard pour pouvoir créer des contexts OpenGL ou OpenVG ou autre (rien d'autre dans le standard pour le moment). Donc tu écris ton compositeur wayland avec EGL, tu crées un context opengl (wayland encourage d'utiliser GLES2 parceque c'est en gros opengl 2.0 - opengl 1.0 et que ca correspond as ce que supporte tous les GPU embedded).
Et voila c'est exactement comme les compositeur actuel. Tu fais de l'opengl, et les bugs GPU bah c'est des bugs du driver GL.
Bon je simplifie un peux parceque tu as aussi besoin de faire le modesetting mais ca y a deja des librairies pour utiliser KMS et faire le boulot a ta place. Ou tu peux copier le code de weston.
La vérité c'est que la partie modesetting & creation de context ca doit être 1000lignes de code en plus par rapport a un compositeur X. C'est pas grand chose et c'est standard si tu utilises EGL et KMS (KMS linux only pour le moment).
[^] # Re: Gestionnaire de fenêtres
Posté par glisse . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 3.
Tu te trompes ;)
L'idée c'est d'utiliser EGL & GLES2. EGL c'est un API standard pour pouvoir créer des contexts OpenGL ou OpenVG ou autre (rien d'autre dans le standard pour le moment). Donc tu écris ton compositeur wayland avec EGL, tu crées un context opengl (wayland encourage d'utiliser GLES2 parceque c'est en gros opengl 2.0 - opengl 1.0 et que ca correspond as ce que supporte tous les GPU embedded).
Et voila c'est exactement comme les compositeur actuel. Tu fais de l'opengl, et les bugs GPU bah c'est des bugs du driver GL.
Bon je simplifie un peux parceque tu as aussi besoin de faire le modesetting mais ca y a deja des librairies pour utiliser KMS et faire le boulot a ta place. Ou tu peux copier le code de weston.
La vérité c'est que la partie modesetting & creation de context ca doit être 1000lignes de code en plus par rapport a un compositeur X. C'est pas grand chose et c'est standard si tu utilises EGL et KMS (KMS linux only pour le moment).