Installation eines VDR+Plugins nativ auf CoreELEC Boxen

machtnix versuch es mal mit diesem patch:

Oder mit der Änderung die ich oben gepostet hatte.

--- a/openglosd.cpp
+++ b/openglosd.cpp
@@ -690,7 +690,7 @@ bool cOglFb::BindTexture(void)
 
 void cOglFb::Blit(GLint destX1, GLint destY1, GLint destX2, GLint destY2)
 {
-    glBlitFramebuffer(0, 0, width, height, destX1, destY1, destX2, destY2, GL_COLOR_BUFFER_BIT, GL_NEAREST);
+    //glBlitFramebuffer(0, 0, width, height, destX1, destY1, destX2, destY2, GL_COLOR_BUFFER_BIT, GL_NEAREST);
     glFlush();
 }
 
diff --git a/video.c b/video.c
index 54422b9..faf4d31 100644
--- a/video.c
+++ b/video.c
@@ -1501,6 +1501,7 @@ bool getResolution(char *mode) {
        } else {
                DmaBufferHandle = h[1];
        }
+       DmaBufferHandle = -1;
        
        close(fd);
 #if 0

Quote from jojo61

Das Clear funktioniert aber wohl auf dem DRM Buffer nicht. Ich könnte das DMA bei der CPU ja weglassen, nur dann ist trotzdem das glBlit noch vorhanden (auch wenn es nicht genutzt wird). Um das weg zu bekommen müsste ich dann wieder einen Compiler #if drum herum bauen und das will ich nicht. Damit müsste man das dann für die CPU extra bauen.

So ganz verstehe ich nicht, wohin das OSD bei dir gerendert wird und wie da beim odroid die Pipeline ist

Bei softhddevice-drm (mit GL) wird ein gbm_suface erstellt, auf das OpenGL rendert und drm macht daraus einen framebuffer, der dann auf einem separaten drm plane dargestellt wird, so machts die kmscube Referenz.
Zum debuggen habe ich mir mal die Mühe gemacht und die Möglichkeit eingebaut, den fertigen output buffer in ein png schreiben zu lassen. Damit könnte man zumindest prüfen, ob die GL Seite schon falsch ist.

Woher bekämst du denn den DRM Buffer?

Gruß

Andreas

Wenn du dir das osdopengl.cpp anschaust dann sieht du das ich als Framebuffer (bei DMA) eine egIImage anlege und darauf wird dann gerendert.

Das ganze habe ich im Internet abgeschrieben und deswegen kann ich den genauen Ablauf wie das zu einem glFrameBuffer passt auch nicht sagen.

Zumindest scheint die Funktion glBlitFramebuffer zu merken das das Zeil hier kein linearer Framebuffer ist. Das ganze funktioniert ja auch mit deinem

expliziten rendern, nur beim zweiten mal wird der alphakanal immer dunkler. Evtl. muss ich einfach das eglImage immer wieder neu anlegen

bool cOglOutputFb::Init(void)
{
    initiated = true;

        glGenTextures(1, &texture);
    glBindTexture(GL_TEXTURE_2D, texture);
    void *frameBufferImage = {0};

    if (DmaBufferHandle >= 0 ) {
        EGLint img_attrs[] = {
                EGL_WIDTH, VideoWindowWidth,
                EGL_HEIGHT, VideoWindowHeight,
                EGL_LINUX_DRM_FOURCC_EXT, DRM_FORMAT_ARGB8888,  //DRM_FORMAT_RGBA8888
                EGL_DMA_BUF_PLANE0_FD_EXT,      DmaBufferHandle,
                EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
                EGL_DMA_BUF_PLANE0_PITCH_EXT, VideoWindowWidth * 4,
                EGL_NONE
            };

        frameBufferImage = eglCreateImageKHR(eglDisplay, EGL_NO_CONTEXT, EGL_LINUX_DMA_BUF_EXT, 0, img_attrs);
        GlxCheck();
    } else {
        glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
    }

    GlxCheck();
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_BORDER);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_BORDER);

    if (DmaBufferHandle >= 0)
        glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, frameBufferImage);

    glGenFramebuffers(1, &fb);
    glBindFramebuffer(GL_FRAMEBUFFER, fb);
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, texture, 0);
    GlxCheck();
    if (glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE) {
        esyslog("[softhddev]ERROR::cOglOutputFb: Framebuffer is not complete!");
        return false;
    }
    return true;
}

Quote from jojo61

Wenn du dir das osdopengl.cpp anschaust dann sieht du das ich als Framebuffer (bei DMA) eine egIImage anlege und darauf wird dann gerendert.

Das hört sich ja richtig an. Ich habe das zu vdpau-Zeiten mit einem eglCreatePbufferSurface gemacht und jetzt halt über ein gbm surface. Aber das Prinzip sollte dasselbe sein.

Stimmt nur der alpha-Wert nicht, oder wird komplett über das alte OSD gezeichnet?

Ich rendere komplett über das alte OSD. Aber nur der transparente Teil geht kaputt. Naja kaputt .. es sieht so aus als ob Alpha immer grösser wird und damit wird dann der Alpha Bereich im OSD so langsam schwarz. Nach 3-4 updates/neu rendern des OSD ist der transparente Teil dann schwarz.

Ok, ich hatte ein ähnliches Problem auch, aber da wurde das alte OSD bzw. in unserem Fall die alte Textur vorher nicht gelöscht. Aber das betraf dann alle Bereiche, das konnte man gut sehen, wenn man durchs Menü gewandert ist. Markierte Zeilen blieben dann stehen. Sah man aber erst, wenn die Transparenz im VDR OSD relativ hoch war, sonst wars schnell ganz dunkel.

Wenn das bei dir wirklich nur der transparente Bereich ist, ist das in der Tat merkwürdig aber es wäre interessant, ob der output buffer wirklich richtig ist und später erst was falsch läuft...

Ich habs gefunden

Ich muss das Blending ausschalten. Sonst blendet er jeden Update ins eglImage über das aktuelle. Löschen kann ich das eglImage wohl nicht.

Jetzt wird es einfach überschrieben egal was da vorher stand. Ich werde es gleich einchecken.

Deine Beschreibung mit dem Menü wandern hat mich drauf gebracht. Das habe ich dann auch hier gesehen.

Bin gespannt ob es nun auch mit der Mali 450 geht.

jojo61: Sorry, dass ich Wasser in den Wein gießen muss. Leider funktionieren mit der letzten Änderung die Skins vom Skindesigner nicht mehr, da viele Sachen nicht richtig oder gar nicht dargestellt werden...

EDIT: Wenn ich im Hauptmenü nach unten scrolle, sieht das Bild für einen kurzen Moment normal aus, dann fehlen wieder Teile, bis ich weiter scrolle.

Dasselbe gilt auch für die OK-Taste. Hier fehlen Teile, dann blitzt kurz das ganze Bild auf, nur um wieder zu verschwinden. Vielleicht hilft Dir das beim Debuggen...

jojo61 Fehlt vielleicht das flush oder finish?

Und täglich grüßt der skindesigner Ich weiss gar nicht warum man ein so überladenes OSD haben will

beta ich habe den Fehler gefunden und nun eingecheckt. Danke für das Feedback.

Kann mal jemand mit einer Mali 450 feedback geben ob es nun geht.

Quote from jojo61

Danke für das Feedback.

Ich danke Dir, jojo61!

Quote

Kann mal jemand mit einer Mali 450 feedback geben ob es nun geht.

Ok, baut gerade. Ergebnis folgt

Jetzt schonmal danke an alle Beteiligten.

Quote from Zabrimus

Nur kurz zur Info. Ich habe ein neues Release erstellt. Darin ist einiges aufgeräumt worden, Updates für verschiedene Plugins und ein paar Fixes. Die Version ist 0.2.0.

Zur Info, ich habe nun keine Probleme mehr beim erstellen der Images mit ./build-local.sh -9, vielen Dank für die tolle Arbeit. Jetzt teste ich das Image mit einem Tanix TX3.

Hallo,

leider kommt jetzt bei der Mali450 ein anderer Fehler:

May 06 14:25:03 CoreELEC vdr[3936]: [3936] loading plugin: /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1

May 06 14:25:03 CoreELEC vdr[3936]: [3936] ERROR: /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1: undefined symbol: glGenVertexArrays

Aus meiner Sicht ist das ein libmali-Problem. Den Fehler hatte ich gestern in meiner chroot-Umgebung, nachdem ich mir die libmali zerschossen hatte.

Wahrscheinlich wäre der schnellste Weg, um zu schauen, ob das auf Deiner Box läuft, ein UBUNTU im chroot aufzusetzen, VDR und softhdodroid zu kompilieren und zu schauen, ob es dann startet. Falls ja, könnte man die libmali ersetzen....

Ein libmali Problem insofern, als dass der blob nur striktes OpenGL/ES 2.0 kann.

Das Problem ist, dass das aktuelle openglosd.cpp für OpenGL geschrieben wurde und Funktionen enthält, die OpenGL/ES 2.0 nicht kennt. glGenVertexArrays, glBindVertexArray sind z.B. welche davon.

Es ist nicht allzu aufwendig, das an gles anzupassen, aber man muss sich halt durchwursteln. Ich habe das vor langer Zeit schon für libmali gemacht. Die Shader haben damals nicht gepasst und GL_RED oder GL_CLAMP_TO_BORDER gabs auch nicht.Falls sich jemand damit beschäftigen will, kann ich ihm gerne meinen Code zur Verfügung stellen.

Unabhängig davon wärs wirklich zu überlegen, ob ihr nicht auf den blob verzichten könnt und stattdessen mainline mesa nutzt...

Gruß

Andreas

Quote from rell

Unabhängig davon wärs wirklich zu überlegen, ob ihr nicht auf den blob verzichten könnt und stattdessen mainline mesa nutzt...

Das verstehe ich nicht ganz. Wir reden hier doch von der libMali.so Wie hängt das mit mainline mesa zusammen ?

Im übrigen habe ich nicht die Fähigkeiten das openglosd umzuschreiben um nur noch OpenGL 2.0 zu nutzen. Wer das kann und Lust dazu hat kann mir gerne einen Patch schicken. Ob sich das lohnt ist mir aber unklar. Die Mali 450 ist ja nun mal schon sehr alt. Und evtl. gibt es ja auch eine Lösung mit mainline mesa.

Die libmali.so kommt doch vom Boardhersteller? Die ist closed source und enthält nur GLES 2.0 Funktionen.

Mesa stellt genauso wie die libmali.so die GL Funktionen zur Verfügung.

Seit geraumer Zeit gibts in mesa die Unterstützung für Mali400/450 und über mesa wird teilweise opengl angeboten.

Ich brings deshalb ins Spiel, weils einfach open source ist...

Wenn sich das jemand ansehen möchte, kann man hier einen Commit finden, der die Umstellung auf gles beschreibt oder sich an meinem aktuellen fork entlang hangeln - der macht reines gles 2.0

Allzu viel ist es eigentlich nicht - die vdpau Geschichten kann man ignorieren.

Ich könnts machen, allerdings wird das testen schwierig, da mir die Hardware fehlt.

Gruß Andreas

https://github.com/Zabrimus/CoreE…-ng/options#L84 gibt an, welche gl Variante gewählt wird.

Bei anderen steht das z.B. auf mesa, aber keine Ahnung, ob das so einfach geht.

Man müsste evtl. verschiedene Devices anlegen...