Video Treiber für Odroid-N2+ (softhdodroid)

Ich denke ich weiß, wo das Problem mit meinem Bild liegt (und jojo61 müsste noch dasselbe Problem beim Grabben haben):

The driver needs to allocate memory for a whole frame, but its more than the kernel allows in its default configuration.
To make the driver work the FORCE_MAX_ZONEORDER parameter in arch/arm64/Kconfig needs to be changed from "11" to "13" (https://forum.odroid.com/viewtopic.php?t=20901).

Wenn ich aber den Kernel übersetze mit "13", bootet er nicht mehr. Ich kann zwar über Petitboot booten, VDR läuft aber gar nicht mehr. Ich frage mich nur, wie CoreElec das macht, hier steht der Wert auch auf "11".

jojo61 Hast Du ein komplettes UHD-Bild grabben können, oder fehlt Dir da auch die Ecke?

Das nutzt mir leider nichts, da ja erst einmal der gesamte Videospeicher gelesen wird, selbst wenn es dann nur runterskaliert ausgegeben wird.

Kennt sich denn jemand mit boblight aus? Mein Ambilight (ada102) hängt an einem Atmel Controller und funktioniert mit Hyperion. Wenn ich VDR mit boblight-Plugin starte, habe ich einen segmentation fault.

Du musst im boblight plugin noch die Stelle ergänzen die auf das softhdodoid plugin verweist. Das musste man auch für softhdcuvid und andere ergänzen. Ich kann dir die Stelle raussuchen, habe jetzt aber gerade keinen Zugriff.

Hallo,

Quote from mamomoz

Das musste man auch für softhdcuvid und andere ergänzen.

Patch für Softhdcuvid

diff -upr ./old/boblight-git/ambithread.c ./new/boblight-git/ambithread.c
--- a/ambithread.c    2018-10-05 16:00:20.126752025 +0200
+++ b/ambithread.c    2018-10-05 16:44:20.019042666 +0200
@@ -45,15 +45,17 @@ cAmbiThread::cAmbiThread()
    osd3dChanged = true;
 
    softHdPlugin = cPluginManager::GetPlugin("softhddevice");
-   int softHdGrabService = (softHdPlugin && softHdPlugin->Service(ATMO1_GRAB_SERVICE, 0));
+   if (!softHdPlugin)
+        softHdPlugin = cPluginManager::GetPlugin("softhdcuvid");
 
+   int softHdGrabService = (softHdPlugin && softHdPlugin->Service(ATMO1_GRAB_SERVICE, 0));
    if (!softHdGrabService)
       error("Can't find softhddevice %s!", softHdPlugin ? "service" : "plugin");
    
    int softHd3DOsdServive = (softHdPlugin && softHdPlugin->Service(OSD1_3DMODE_SERVICE, 0));
-
    if (!softHd3DOsdServive)
         tell(1, "Can't find softhddevice 3D OsdMode Service 1.1, 3D detection will not work!");
+
 }
 
 cAmbiThread::~cAmbiThread()
@@ -86,7 +88,7 @@ void cAmbiThread::Action()
    cMutexLock lock(&mutex);
 
    tell(0, "boblight Thread started (pid=%d)", getpid());
-
+   
    loopActive = true;
    bob.open();

Gruss

Wolfgang

Danke Wolfgang! Wo finde ich denn ein aktuelles boblight plugin?

Hallo,

Quote from beta

Wo finde ich denn ein aktuelles boblight plugin?

vdr-plugin-boblight-0.0.7 ist von

https://projects.vdr-developer.org/git/vdr-plugin-boblight.git/

Ob es da noch was aktuelleres auf z.B github/gitlab gibt,weiss ich nicht.

Gruss

Wolfgang

Hallo,

gerade ersten Test gemacht.

Mit gepachten ubuntu Kernel hauts noch nicht richtig hin.

Das Log wird geflutet mit:

vdr: video: grab
BOBLIGHT: Got image with 64x64 pixel; 12288 bytes
BOBLIGHT: sleeping 53ms (15 Hz)
Softhddevice NOT detached: 910

BoblightPlugin verbindet sich mit Hyperion, aber die Farben passen nicht.

vdr läßt sich dann kaum noch bedienen.

Mit dem CoreElec-Ubuntu-Mix-Kernel funktioniert das leider genauso wenig. Hier habe ich denselben Effekt wie mit dem anderen Kernel. Ich frage mich nur, wie CoreElec das löst. Auch dieser Kernel kann nicht das 4k-Bild aus der VPU mit einem Schlag auslesen (s.o., FORCE_MAX_ZONEORDER ist dafür auch zu klein).

Im Log habe ich bei beiden Kerneln übrigens ein:

Nov 25 11:01:11 odroid kernel: [  134.956174@0] ge2d: ge2d timeout!!!

Es sieht so aus, als würde der CoreElec-Grabber den FrameBuffer auslesen und nicht die VPU. Darin ist aber hier nur das OSD.

Hier gibt es noch einen Kernel, in dem das videocapture-Device bereits eingebaut ist. Vielleicht funktioniert der ja?

https://github.com/tobetter/linux…nk/amvideocap.c

Edit: Gerade probiert. Der Kernel bootet nicht.

Wie gesagt, was mir aufgefallen ist, ist dass der AML grabber unter CoreElec das Framebuffer Device benutzt. Könnte man nicht Dein Video-Bild einen einen Framebuffer mappen, den man dann nutzt? Es gibt doch 4, oder?

Mit dem neuen Commit habe ich einen crash in vdrboblight:

Thread 9 "vdr" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f84606170 (LWP 3495)]
0x0000007fac592200 in cAmbiThread::putData (this=this@entry=0x5555bf2ca0)
    at ambithread.c:397
397	   			rgb[0] = p->r;

Quote from jojo61

Mach mal in video.c in Zeil 471 aus dem #if 0 ein #if 1

Danke, probiere ich gleich aus.

Quote from jojo61

Kannst du bei Corelec sehen welchen Framebuffer hyperion da nutzt ?

Ja, /dev/fb0, dort ist das Bild inkl. OSD

jojo61: Mit Deinem letzten Commit habe ich keinen Sync mehr mit 4k (getestet mit SES UHD Demo). Ohne den Commit funktioniert es.

Ich bin immer noch an dem Thema hyperion dran. Ich denke, ich bin da etwas auf der Spur, brauche aber noch eine Weile...

Ich poste hier meinen aktuellen Zwischenstand mit dem Odroid N2+ und Hyperion.

Ich habe hier einen Odroid N2(+)-Kernel abgelegt ("aktueller" 4.9), bei dem ich alle media-Treiber und -Module durch die von CoreElec ersetzt habe. Eine .config liegt bei. Die Overlays müssen so gepatcht werden, wie ich das weiter oben in diesem Thread schon beschrieben habe (ebenfalls enthalten). Der Link läuft leider in 7 Tagen ab, vielleicht kann das jemand sonst noch irgendwo hosten.

Als hyperion nutze ich dieselbe Version, die CoreElec auch benutzt (2.0.12). Wahrscheinlich funktioniert auch der aktuelle git-Stand, ich habe den aber nach dem Auschecken mit der o.g. Version überschrieben. Übersetzt habe ich so

cmake -DENABLE_WS281XPWM=0 -DENABLE_X11=0 -DENABLE_FB=0 -DENABLE_DISPMANX=0 -DENABLE_SPIDEV=OFF -DENABLE_AMLOGIC=1 -DPLATFORM=amlogic -DCMAKE_BUILD_TYPE=Release -Wno-dev ..

Da ich im Moment nicht vor dem Rechner sitze, konnte ich nur remote testen. Ich habe eine SES Astra 4k Demo-Aufnahme getestet und eine Full-HD-Aufnahme:

Der grab der Bilder sieht erst einmal in Ordnung aus (sowohl 4K als auch 1080i).

Für das Grabben von 4k habe ich in die /etc/rc.local folgendes eingetragen:

echo 3 > /sys/module/amvdec_h265/parameters/double_write_mode
echo 3 > /sys/module/amvdec_vp9/parameters/double_write_mode

Getestet habe ich mit c2play. Es gibt noch ein kleines Problem. Nach Beenden eines Videos und dem Start eines neuen Videos deaktiviert sich die Video-Ausgabe. Die kann man aber (als root) einfach wieder einschalten mit einem

echo 0 > /sys/class/video/disable_video

jojo61: Vielleicht ist das ja auch das Problem mit mit Deiner fehlenden Konsole. Könntest Du evtl. (bis ich das eigentliche Problem gefunden habe), das echo 0 > ... mit in Dein Plugin aufnehmen. Es müsste ausgelöst werden, wann immer das Video wechselt.

Ein paar Ideen habe ich noch, falls es (noch) nicht zuverlässig funktionieren sollte. Man könnte alle Patches aus dem CoreElec-build noch implementieren und noch weiter mit den .config-Parametern spielen.

Evtl. hat ja der eine oder andere Lust, zu testen und mitzuhelfen Kernel-Debugging ist echt ein Aufwand...

Das Ganze ist quick and dirty implementiert und ich habe einige -Werrors aus dem Makefile auskommentiert. Falls es irgendwann einmal zufridenstellend läuft, müsste man diese Warnungen noch alle beseitigen.