[Erledigt] "Scart automatisch" aus Deep-Standby

[caotz]

Nochmals hallo,
ich habe meine Philips SAT Dbox2 so eingestellt dass sie "im TV-Modus" startet. Auch hab ich eingestellt dass Scart "automatisch" erkannt wird. Wenn nun der DVD-Player schon eingeschaltet ist und die Dbox2 aus dem Deep-Standby hochfährt startet sie im TV-Modus. Wenn man nun irgendeine Taste (tb "OK" oder "Dbox"/"Menü") drückt, wird auf Scart umgeschaltet. Irgendwann "früher" ist die Box noch wie erwartet im Scart-Modues hochgefahren. Ist das ein Bug den ihr beheben könnt?

[GetAway]

Ich habs mal eben debugged.
Scheinbar liefert die ioctl Abfrage direkt nach dem Booten ein anderes Ergebnis mit anliegender Spannung,
als durch ein Wecken durch Anlegen der Spannung am Pin8. Da kann vielleicht seife etwas zu sagen, wenn
er mal wieder hier liest.

[caotz]

Cool dass du es reproduzieren konntest, hatte schon Angst um meine Hardware

[seife]

GetAway: sicher, dass der ioctl einen anderen Wert liefert? Glaub ich eigentlich nicht, zumindest wurde daran IMHO nie was gemacht.

Was "im betrieb" passiert ist IMHO:
* es wird ein event getriggert, wenn die Spannung sich ändert
* dieser Event wird vom eventwatchdog irgendwo im controld/zapit-Unterholz ausgewertet und triggert die Umschaltung

Wenn beim Booten die Spannung schon anliegt passiert das nicht, weil keine Änderung eintritt => kein Event.

Der Eventwatchdog müsste also beim starten einmal getriggert werden.
Oder sowas in der Art.
So dass auch ohne event einmal etwas wie "WatchDog->vcrModeChanged(WatchDog->getVCRMode());" aufgerufen wird.

[caotz]

Bin mir _relativ_ sicher dass es früher mal ging. Hab mittlerweile aber SAT und einen anderen DVD-Player. Wie gesagt schlatet es ja auf Scart nachdem man zum 1. mal eine beliebige Taste drückt

[GetAway]

GetAway: sicher, dass der ioctl einen anderen Wert liefert?

Ich habe in neutrino.cpp nur CNeutrinoApp::RealRun debugged.
Dort wird als erstes der ioctl abgefragt.

Code: Alles auswählen

		int fp = open(VCR_DEVICE ,O_RDWR);
		if (fp >= 0)
		{
			ioctl(fp, VCR_IOCTL, &val);
			close(fp);
			if (val > VCR_0V)
			{
				dprintf(DEBUG_NORMAL, "Switching to scart mode...\n");
				lastMode = mode;
				handleMsg(NeutrinoMessages::EVT_VCRCHANGED, VCR_STATUS_ON);
			}
		}

"val" ist dort 0 nach einem Reboot mit anliegender Spannung.
Aber es ist ja in dem moment kein Event, da sich die Spannung ja nicht ändert, sondern schon anliegt.
Trotzdem muss das irgendwo schon in die Warteschlange von rcinput(?) geschoben werden, weil auf
Tastendruck, nach Reboot, in den Scartmodus geschaltet wird.

Mir fällt da noch Last_Modus von Zapit ein.

[rhabarber1848]

Bin mir _relativ_ sicher dass es früher mal ging.

Ich kann die Situation hier reproduzieren und bin Deiner Meinung.

[mrvica]

VCR Scart kann aber kein RGB durchschleifen, nur S-Video und FBAS, was die Bildqualität mindert, habe mir neulich dies bei ebay geholt und bin sehr zufriden, kriegt man jetzt für wenig Geld da alle jetzt auf HDMI umgestiegen sind, SCART ist überholt
http://www.tembographics.com/savage/B-T ... ontrol.pdf
alle Eingänge und Ausgänge voll RGB fähig, hat auch FB die man gar nicht braucht, schaltet automatisch um sobald das Signal anliegt
such mal nach PRO AUDIO VIDEO CONTROL BT945, kann auch andere Bezeichnung haben je nach Hersteller, hama, speaka

mrvica

[GetAway]

Any News?

@seife. Wo muss man das ansetzen. Das betrifft doch bestimmt auch die DM500?

[Gaucho316]

Ich habe etwas geforscht und bin auf die Datei dbox2_fp_core.c im Verzeichnis driver/fp/ gestoßen. Dort wird in Zeile 245 die Variable fpVCR ausgelesen, wenn das Kommando FP_IOCTL_GET_VCR übergeben wird. Diese Variable wird in Zeile 331 aber mit 0 initialisiert, anstatt den tatsächlichen Status auszulesen. Ist das vielleicht schon der Fehler?

[seife]

Eigentlich nicht.
Das wird auf null initialisiert, aber danach wird, wenn ein interrupt kommt, der wert aktualisiert.
Wenn er sich vom vorherigen Wert unterscheidet, wird ein event geworfen.

Du kannst ja mal versuchen, das auf 3 zu initialisieren, ich denke aber nicht, dass das was ausmacht.

[Gaucho316]

Das wird auf null initialisiert, aber danach wird, wenn ein interrupt kommt, der wert aktualisiert.
Wenn er sich vom vorherigen Wert unterscheidet, wird ein event geworfen.

Richtig, aber es kommt ja gar kein Interrupt. Erst wenn ich eine Taste auf der Fernbedienung drücke, bekommt die Box mit, das etwas passiert ist. Ich schätze erst dann wird auch der Pin8-Status überprüft. Oder liege ich da komplett falsch?

[GetAway]

Eigentlich nicht.
Das wird auf null initialisiert, aber danach wird, wenn ein interrupt kommt, der wert aktualisiert.
Wenn er sich vom vorherigen Wert unterscheidet, wird ein event geworfen.

Du kannst ja mal versuchen, das auf 3 zu initialisieren, ich denke aber nicht, dass das was ausmacht.

Wenn man mit 3 initialisiert, schaltet die Box immer auf Scart. Gerade getestet.

Ich tippe auch auf den Interrupt, den man irgendwo einbauen muss.

[seife]

Man müsste also einmal initial den IRQ abarbeiten, acuh wenn er gar nicht kommt... hm...

Probier mal eine von beiden Zeilen (nicht beide ;-)

Code: Alles auswählen

--- a/fp/dbox2_fp_core.c
+++ b/fp/dbox2_fp_core.c
@@ -401,6 +401,9 @@ static int fp_detect_client(struct i2c_adapter *adapter, int address, unsigned s
        if (request_irq(FP_INTERRUPT, fp_interrupt, SA_ONESHOT, "fp", data) != 0)
                panic("Could not allocate FP IRQ!");
 
+       fp_check_queues();
+       fp_task(NULL);
+
        return 0;
 }

[GetAway]

@seife

Es funktionieren beide Varianten, wobei ich für die 2. Variante tendiere, da man
bei der 1. Variante die Funktion noch zusätzlich deklarieren muss.

Gratulation Gaucho316. Auf den Treiber wäre ich jetzt nicht gekommen.

[seife]

Hm. Komisch ist halt, dass es früher mal funktioniert haben soll (ich vermutete ja den controld-zapit-merge als "Schuldigen"), aber am Treiber schon ewig nichts mehr geändert wurde.

Vielleicht wurde aber auch irgendwas anderes geändert, evtl. wurden die Treiber mal in einer anderen Reihenfolge geladen oder irgendein ioctl, der einen Interrupt als "Dreckeffekt" getriggert hat oder so...

[GetAway]

Hm. Komisch ist halt, dass es früher mal funktioniert haben soll (ich vermutete ja den controld-zapit-merge als "Schuldigen"), aber am Treiber schon ewig nichts mehr geändert wurde.

Vielleicht wurde aber auch irgendwas anderes geändert, evtl. wurden die Treiber mal in einer anderen Reihenfolge geladen oder irgendein ioctl, der einen Interrupt als "Dreckeffekt" getriggert hat oder so...

Ich habe bis 2009.12 zurückgebaut, da ging es auch nicht.

[caotz]

Ich muss gestehen dass bevor ich dieses Jahr wieder angefangen hab an der Dbox zu basteln ein sehr altes Image lief. Ich glaube von 2006 oder 2007

[seife]

Controld-zapit merge war im März 2009 committed worden.

Aber selbst wenn es vorher "aus Versehen" funktioniert hat, ist ein richtiger fix jetzt auch nicht schlecht

[caotz]

Wäre dankbar wenn ihr das hinbekommt!

[GetAway]

Wenn von seife nichts besonders dazu noch kommt, kann es so rein.

Patch: Patch ist im CVS.

[seife]

Ich hab mal noch nen kommentar dazugeschrieben, für den Fall, dass es doch nicht so recht funktioniert oder Nebenwirkungen zeigt.

Nicht dass jemand meint, ich hätte gewusst was ich da tue und es deswegen als korrekt ansieht

[rhabarber1848]

oder Nebenwirkungen zeigt.

Diese sind bereits eingetreten: http://www.tuxbox-cvs.sourceforge.net/f ... 88#p380388

Ich teste nun die alternative Code-Zeile...
PS: Auch hier bleibt meine Box nach einem Kaltstart hängen...

PPS: commit vorerst reverted: http://article.gmane.org/gmane.comp.vid ... x.scm/3073

[GetAway]

Meinst du diese alternative?

Code: Alles auswählen

Index: driver/fp/dbox2_fp_core.c
===================================================================
RCS file: /cvs/tuxbox/driver/fp/dbox2_fp_core.c,v
retrieving revision 1.94
diff -u -p -r1.94 dbox2_fp_core.c
--- a/driver/fp/dbox2_fp_core.c	9 Sep 2011 14:12:25 -0000	1.94
+++ b/driver/fp/dbox2_fp_core.c	19 Sep 2011 21:09:06 -0000
@@ -313,7 +313,7 @@ static int fp_detach_client(struct i2c_c
 	return 0;
 }
 
-
+static void fp_check_queues(void);
 static int fp_detect_client(struct i2c_adapter *adapter, int address, unsigned short flags, int kind)
 {
 	int err = 0;
@@ -404,7 +404,8 @@ static int fp_detect_client(struct i2c_a
 	/* initial poll of the frontprocessor to get e.g. SCART pin state correct,
 	 * http://www.tuxbox.org/forum/viewtopic.php?t=49713
 	 * I'm not 100% sure this is correct, but users report it works */
-	fp_task(NULL);
+//	fp_task(NULL);
+	fp_check_queues();
 
 	return 0;
 }

[rhabarber1848]

Meinst du diese alternative?

Ja, auch damit bleibt die Box beim Kaltstart hängen.