Linux und OpenGL mit Frame Buffer Device ohne X11

[alexander_ro]

Hallo,

ich benutze Gentoo ohne X11 und versuche gerade OpenGL (Mesa3D) mit dem FB-Device zum laufen zu bekommen. Ich habe schon eine ganze weile im Netz nach Informationen gesucht aber nur die Aussage gefunden das es geht leider stand da nirgends wie. Das einzige das in die Richtung geht ist directfb aber nicht ganz was ich wollte. Die OpenGL Beispiele die ich gefunden haben laufen zwar unter X11 aber nicht ohne. Kennt Ihre vielleicht irgend eine Seite wo das Beschrieben wird oder hat vielleicht einer ein kleines Beispiel wie es geht ... :-) ?

Viele Grüße
Alexander

[xq]

ich kann dich mal richtung SDL 1 hinten, die haben eine implementiernung für framebuffer access, mehr weiß ich leider auch nicht

[Sternmull]

Zumindest proprietäre Desktop-OpenGL-Treiber hängen von X11 ab, ich glaub die Open-Source-Treiber auch. Wenn du dort Hardware beschleunigtes OpenGL willst, dann geht das also vorerst nicht ohne X11. Was du suchst ist wahrscheinlich eine EGL-Implementierung die du ohne X11 verwenden kannst um OpenGL zu initialisieren. Das wird es sicherlich in mittelfristiger Zukunft geben da Wayland darauf aufbauend X11 ablösen soll. In dem Artikel sind auch zumindest ein paar Ebedded Hardware Plattformen aufgezählt die das bereits leisten.

[alexander_ro]

Auf den Architektur Bildern von Wayland sieht das für mich so aus als ob OpenGL direkt allerdings über DRM läuft. Hier ist dann der Hardware Treiber in dem DRI-Modul untergebracht oder sehe ich das falsch?

DRM und das Frame Buffer Device ist aber nicht das gleiche?

[Sternmull]

Ich hab vor einiger Zeit mal das Bedürfnis gehabt den Linux Grafik-Stack zu verstehen, dabei fand ich das hier recht hilfreich. Dort steht auch wie DRM und framebuffer einzuordnen sind. Ich bin allerdings kein Experte und hab auch das in dem Artikel bestenfalls halb verinnerlicht. Soweit ich verstehe ist ein Framebuffer-Interface hier wirklich nichts anderes als das Initialisieren eines Grafik-Modus und ein Puffer in den man dann seine Pixel malen kann damit die anschließend auf dem Bildschirm erscheinen. Das scheint ein primitivst-Interface zur Grafikdarstellung zu sein das vollkommen unabhängig von jeglicher OpenGL-Implementierung arbeitet. Ich glaub auf Desktop-Systemen wird dieses Framebuffer-Interface normalerweise ausschließlich zur Darstellung von Boot-Splashscreens und der nativen TTYs verwendet (also dem Konsolen-Modus den man vor der X-Initialisierung hat). Man kann es zwar auch von anderen Programmen aus verwenden, hat dann aber kein OpenGL (es sei denn man implementiert es in Software und "malt" das Ergebniss dann in den Framebuffer).

Die Architektur-Übersicht auf Wikipedia zeigt EGL und OpenGL als Teil von Mesa3D welches letzendendes über DRM mit dem Kernel kommuniziert. Das gilt allerdings nur für die Open-Source Treiber. Die proprietären können da ihr eigenes Süppchen kochen. Wichtig ist nur das die demnächst auch EGL zur Verfügung stellen werden damit Wayland-Implementierungen (und potentiell sicherlich auch andere Anwendungen) an die OpenGL-Funktionalität kommen ohne X11 bemühen zu müssen.

[Lynxeye]

Mesa kann auf Fbdev nur Softwarerendering, also Softpipe oder LLVMpipe als Treiber. Was du wahrscheinlich willst ist EGL mit KMS als native Window backend. Schau dir dazu mal die configure optionen von Mesa an. Damit kannst du dir direkt auf deinem DRM device einen native OpenGL Context holen, der dann auch mit den DRI Treibern funktioniert.

[alexander_ro]

Linux Grafik-Stack zu verstehen

Danke für den Link der hat mir auch geholfen die ganzen Kürzel besser zu zuordnen.

https://de.wikipedia.org/wiki/Direct_Re ... ayland.svg
Auf dem Wikipedia Bild sieht man rechts oben die "OpenGL application" die dann über DRI/DRM auf die Grafikkarte zugreift. So etwa würde ich mir das jetzt vorstellen.

Daneben ist Wayland das im Prinzip das gleiche macht aber mit EGL. Was mir jetzt noch nicht ganz klar ist was zwischen den beiden Varianten die Vor- oder Nachteile sind. Weil ich irgendwie noch ein wenig mit den Kürzeln auf Kriegsfuß stehe. Ist EGL das was man Teileweise auch als OpenGL ES liest oder bring ich da was durcheinander?

[Sternmull]

OpenGL ist ja eine reine Rendering-API. Zur initialisierung von OpenGL wird normalerweise was Plattform-spezifisches genommen (WGL und Windows, GLX unter Linux). EGL stellt diese Funktionalität über eine einheitliche API zur Verfügung die dann überall dort eingesetzt werden kann wo sie implementiert ist. EGL ist also ein Weg an OpenGL ran zu kommen und dessen Ressourcen zu verwalten (was auch gleichzeitigen Zugriff aus verwandten APIs wie OpenGL und OpenVG ermöglichen soll). Wenn OpenGL dann ein mal per EGL initialisiert ist, hat die Anwendung wahrscheinlich nicht mehr viel mit EGL zu schaffen sondern macht halt einfach ihr übliches OpenGL-Ding.

Ich glaub das SVG ist ein bisschen missverständlich. Die Pfeile an denen EGL steht dürften ausschließlich für Initialisierung und Ressourcen-Verwaltung stehen (z.B. damit Client-Anwendung und Waland-Server effizienten Zugriff auf gemeinsam genutzte Puffer bekommen und die Zugriffe synchronisieren können). "Gemalt" wird dann grundsätzlich mit OpenGL.

[alexander_ro]

Ich habe mir jetzt eine Test installation auf einem Asus eee901 gemacht. Gentoo mit Mesa und dem OpenSource Grafikkarten Treiber.

Im Netz habe ich mir aus Infos von allen möglichen Seiten und der Referenz zu EGL ein Testprogramm gebaut. Das läßt sich auch übersetzen was nicht viel aussagt. Leider bekomme ich aber eine Fehlermeldung wenn ich das Programm aufrufe.

Code: Alles auswählen

#include <iostream>
#include <sstream>
#include <string>

#include <EGL/egl.h>
#include <GL/gl.h>

int main(int argc, char *argv[])
{
// Neuen Display konekt erzeugen
  EGLDisplay eglDisplay = eglGetDisplay ((EGLNativeDisplayType) 0);

  if (eglDisplay == EGL_NO_DISPLAY)
    std::cout << "eglGetDisplay: Fehler EGL_NO_DISPLAY" << std::endl;

// EGL Initialisieren
  EGLBoolean boolInitRc = eglInitialize (eglDisplay, nullptr, nullptr);

  if (boolInitRc == false)
    std::cout << "eglInitialize: Fehlerhaft" << std::endl;

// Festlegen welche Render API benutzt werden soll
// Mögliche Werte: EGL_OPENGL_API, EGL_OPENGL_ES_API, or EGL_OPENVG_API
  EGLBoolean boolApiRc = eglBindAPI (EGL_OPENGL_API);

  if (boolApiRc == false)
    std::cout << "eglBindApi: Fehlerhaft" << std::endl;

// EGL Frame Buffer Konfiguration erstellen
  EGLint eglConfigAttrib[5];
  eglConfigAttrib[0] = EGL_SURFACE_TYPE;
  eglConfigAttrib[1] = EGL_WINDOW_BIT;
  eglConfigAttrib[2] = EGL_RENDERABLE_TYPE;
  eglConfigAttrib[3] = EGL_OPENGL_ES2_BIT;
  eglConfigAttrib[4] = EGL_NONE;

  int iConfigs;
  EGLConfig eglConfig;
  eglChooseConfig (eglDisplay, eglConfigAttrib, &eglConfig, 1, &iConfigs);

  if (iConfigs != 1)
  {
    printf("Error: eglChooseConfig(): config not found.\n");
    exit(-1);
  }

// Erzeuge eine EGL Windowfläche
  EGLSurface eglSurface;
  eglSurface = eglCreateWindowSurface (eglDisplay, eglConfig, (EGLNativeWindowType) NULL, NULL);

// Erzeuge einen EGL Render Context
  EGLint eglContextAttrib[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE };
  EGLContext eglContext;
  eglContext = eglCreateContext (eglDisplay, eglConfig, NULL, eglContextAttrib);

// Verbinde den EGL Render Context mit der EGL Windowfläche
  eglMakeCurrent (eglDisplay, eglSurface, eglSurface, eglContext);

// Wie gehts nun weiter ...
}

Fehlermeldungen:
libEGL warning: DRI2: xcb_connect failed
libEGL warning: DRI2: xcb_connect failed
eglInitialize: Fehlerhaft
Error: eglChooseConfig(): config not found.

Habt Ihr vielleicht eine Idee was ich da falsch mache?

[Sternmull]

Habs mit open source ATI-Treibern probiert. Auf einer vtty sehe ich deinen Fehler. Dort gibt eglGetError() dann übrigens EGL_NOT_INITIALIZED zurück. Innerhalb einer X11-Session läuft es ohne Fehler durch. Wenn man sich an eine neue API heran tastet dann sollte man übrigens sehr pedantisch bei der Fehlerbehandlung sein. Man weiß ja schlichtweg noch garnicht was einem alles um die Ohren fliegen kann.

Aber ich hab auch eine gute Nachricht: Ich hab hier eine funktionierende Minimalanwendung gefunden :) Den Code hab ich mir nicht angeguckt. Aber ich habs kompiliert und ausprobiert. Mit den open source ATI-Treibern geht es auch wunderbar. Auf meinem Desktop mit proprietärem Nvidia Treiber geht es erwartungsgemäß nicht weil die kein KMS implementieren. Aber ich hab Hoffnung das das im Rahmen der Wayland-Unterstützung irgendwann auch mal mit allen proprietären Treibern gehen wird.

[alexander_ro]

Danke für den Link der sieht gut aus. Ja das Programm funktioniert bei mir auch. Das Beispiel stammt von einem Fachbuch Autor kennst Du zufällig das Buch dazu. Ist das gut? So wie es aussieht muss man da noch ein bisschen mehr tun als ich bisher zusammen gefunden habe.

Stimmt wäre schön wenn es mit den proprietären Treibern aller Hersteller auch ginge. Noch besser wäre wenn die Hersteller keine eigenen Treiber machten sondern die OpenSource Treiber entsprechend bei der Entwicklung unterstützen würden. Aber erstmal zum arbeiten reicht es mir wenn es auf meiner Hardware mit den OpenSource Treibern geht. Meine Hardware ist ja schon älter (Alien M14, eee 901) da funktionieren die OpenSource Treiber auch gut. Wobei ich bei meinem Alien M14 im Moment nur den Intel Chip Nutze. Ob da der Nvidia OpenSource Treiber funktioniert muss ich erst noch testen.

[Sternmull]

Ein Buch dazu kenne ich nicht. Aber ich vermute auch das die ganze Geschichte viel zu jung und wechselhaft ist als das man da ein brauchbares Buch finden könnte. Der Code des Beispiels ist ja recht überschaubar. Warum das alles so funktioniert und wie es zusammen hängt lässt sich sicherlich mit überschaubarem Aufwand recherchieren. z.B. steht auf Wikipedia ein bisschen was zu libgbm. Die Referenz zu EGL und OpenGL ES gibts bei Khronos. Bei Wayland sollte man auch mal rein gucken. Das dürfte ja die ultimative Referenz sein... denn die müssten ja wissen was sie tun.