Gedimmtes LCD bleibt dunkel nach Telnet halt

Sklaventreiber
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von rhabarber1848 »

Hi,

Neutrino, LCD-Dimmtimeout != 0, LCD ist dunkel
Telnet-Login, dort den Befehl halt ausgeführt.
Beim Neustart der Box bleibt das LCD-Display dunkel,
bis Neutrino geladen ist, sogar die Debug- und Uboot-
Meldungen werden nicht angezeigt.

Folgender Patch implementiert in Neutrino Signal-
Handler, welche das LCD-Display wieder aufwachen
lassen, obiges Problem ist damit gelöst.

neutrino_lcdwakeup.diff

Irgendwelche Einwände?
The system is going down NOW!
Sending SIGTERM to all processes
[yhttpd] !!! SIGNAL !!! :15!
[yhttpd] No special SIGNAL-Handler:15!
[yhttpd] stop requested......
[neutrino] received signal, waking-up LCD...
[neutrino] received signal, waking-up LCD...
[neutrino] received signal, waking-up LCD...
Sending SIGKILL to all processes
Requesting system halt
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von rhabarber1848 »

PS: Nein, ich hatte keine Lust, switch/case zu coden, damit der Signaltyp angezeigt wird ;)
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von seife »

Würde man nicht besser dem U-Boot beibringen, das LCD einzuschalten?

Das funktioniert zwar, aber kommt mir irgendwie vor als wäre es an der falschen Stelle...
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von rhabarber1848 »

seife hat geschrieben:Würde man nicht besser dem U-Boot beibringen, das LCD einzuschalten?

Das funktioniert zwar, aber kommt mir irgendwie vor als wäre es an der falschen Stelle...
Dann würde man aber immer noch nicht die Debugmeldungen
der Dbox sehen können. Neutrino schaltet das Display ab und
sollte es beim Beenden wieder einschalten, soweit mein Gedanke.

Ich habe auch versucht, den Kerneltreiber beim Entladen das
Display wieder einschalten zu lassen, leider scheint das Modul
beim Herunterfahren nicht entladen zu werden.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von seife »

Dann würde ich es in die exit-routine einbauen. Signalhandler sind etwas tricky und die Nebenwirkungen sind manchmal subtil.

Wer per "halt" runterfährt, sollte wissen, was er tut ;)
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von rhabarber1848 »

seife hat geschrieben:Dann würde ich es in die exit-routine einbauen.
Wenn ich das richtig sehe, wird CNeutrinoApp::ExitRun nicht
aufgerufen, wenn die Box per halt heruntergefahren wird.
seife hat geschrieben:Signalhandler sind etwas tricky und die Nebenwirkungen sind manchmal subtil.
Sie werden in tuxcald, tuxmaild, timerd, yhttpd, controld und zapit
bereits genutzt, hast Du dort Probleme feststellen können?
seife hat geschrieben:Wer per "halt" runterfährt, sollte wissen, was er tut ;)
Ich habe nicht immer die FB zur Hand, wenn ich die Box herunterfahre,
um ein Yadd zu testen. Die Sagem-Dbox sendet keinen Bootp-Request
beim Warmstart. Während die Box per halt herunterfährt, suche ich
die FB zum Wiedereinschalten, nur bleibt dabei halt oft das LCD dunkel.

Wenn Dir die Signal-Lösung nicht gefällt, schaue ich mir mal Uboot an,
dort müsste das LCD auch einschaltbar sein.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von seife »

rhabarber1848 hat geschrieben:
seife hat geschrieben:Signalhandler sind etwas tricky und die Nebenwirkungen sind manchmal subtil.
Sie werden in tuxcald, tuxmaild, timerd, yhttpd, controld und zapit
bereits genutzt, hast Du dort Probleme feststellen können?
Nein, aber die führen z.B. keine skript-plugins aus. Das müsste man halt ausführlich testen. Aber du hast natürlich recht, einen Versuch ists wert.
Wenn Dir die Signal-Lösung nicht gefällt, schaue ich mir mal Uboot an,
dort müsste das LCD auch einschaltbar sein.
Dort gehört's IMHO eigentlich hin (weil der bootloader sollte die Hardware so initialisieren, dass sie in einem definierten Ausgangszustand ist). Andererseits sollten wir keinen unnötigen Stress deswegen Veranstalten ;)
Liontamer
Klöppelliese
Beiträge: 1644
Registriert: Donnerstag 8. August 2002, 12:51

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von Liontamer »

Ein Workaround wäre, statt 'halt' ein 'rcsim KEY_POWER' zu benutzen. (evtl. auch über ein script)
racker
Einsteiger
Einsteiger
Beiträge: 369
Registriert: Samstag 29. Mai 2004, 01:50

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von racker »

rhabarber1848 hat geschrieben: Wenn Dir die Signal-Lösung nicht gefällt, schaue ich mir mal Uboot an,
dort müsste das LCD auch einschaltbar sein.
Hi,
das ist eigentlich das Interessante an diesem Verhalten,
u-boot resettet das Display, schaltet es ein und initialisiert es.

Btw sollte ein Programm die Hardware nicht in einem undefinierten Zustand hinterlassen.
=> Die Lösung mit Signalhandler gefällt mir ganz gut.

Gruß
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von seife »

dann geht es aber mit "reboot -f" immer noch nicht :-)
racker
Einsteiger
Einsteiger
Beiträge: 369
Registriert: Samstag 29. Mai 2004, 01:50

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von racker »

seife hat geschrieben:dann geht es aber mit "reboot -f" immer noch nicht :-)
Was beweist, dass wir 2 Baustellen haben :D

Gruß
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von rhabarber1848 »

racker hat geschrieben:u-boot resettet das Display, schaltet es ein und initialisiert es.
Punkt 2 geschieht bei mir eben nicht. Kann eigentlich jemand
anderes das von mir geschilderte Verhalten reproduzieren?
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von seife »

reicht das evtl. schon?

Code: Alles auswählen

Index: lcd.c
===================================================================
RCS file: /cvs/tuxbox/boot/u-boot-tuxbox/board/dbox2/lcd.c,v
retrieving revision 1.3
diff -u -p -r1.3 lcd.c
--- lcd.c       14 Feb 2005 16:35:32 -0000      1.3
+++ lcd.c       10 Mar 2009 10:48:30 -0000
@@ -276,7 +276,7 @@ static void lcd_reset_init (void)

        lcd_send_cmd (LCD_CMD_ON, 1);
        lcd_send_cmd (LCD_CMD_RES, 7);
-       lcd_send_cmd (LCD_CMD_SRV, 1);
+       lcd_send_cmd (LCD_CMD_SRV, 0);
        lcd_send_cmd (0x00, lcd_contrast);

        switch (hwi[0])
Das ist auf die schnelle der grösste unterschied zwischen der linux-treiber initialisierung und der im u-boot.
Interessant wäre auch, ob das LCD an geht, wenn der treiber geladen wird, oder wenn neutrino startet.
Test-boote doch evtl. mal ohne neutrino-autostart (oder mach ein "sleep 10" in die start_neutrino), damit du das feststellen kannst.
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von rhabarber1848 »

seife hat geschrieben:reicht das evtl. schon?
Nein.
seife hat geschrieben:Interessant wäre auch, ob das LCD an geht, wenn der treiber geladen wird, oder wenn neutrino startet.
Erst Neutrino aktiviert das Display.

Ich habe auch den Fall "reboot -f" getestet. Wenn das LCD aus war
startet "reboot -f" die Box neu und das LCD-Display ist aktiv. Die
Debug-Meldungen werden angezeigt, aber kein Bootp-Request
abgesetzt, die Box bootet also aus dem Flash.

Hier der Vergleich dessen, wie sich meine Sagem-Box verhält:

reboot -f: kein Bootp-Request, LCD wird wieder eingeschaltet
halt/Einschalten über FB: Bootp-Request, LCD bleibt dunkel, sofern es ausgeschaltet war

Interessant wäre das Verhalten der Nokia- und Philips-Boxen.

Hier scheint also der Dbox-interne Code einige Defizite zu haben,
die vom Tuxbox-Code nicht behoben werden.

Weder Dein U-Boot-Patch, noch das LCD-Kernel-Modul sind in der
Lage, ein ausgeschaltetes LCD-Display wieder einzuschalten, nur
Neutrino (Enigma nicht getestet) macht das.

Ich schau noch mal weiter...
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von rhabarber1848 »

seife hat geschrieben:Signalhandler sind etwas tricky und die Nebenwirkungen sind manchmal subtil.
Du hast Recht, ich hatte jetzt schon mehrfach die Situation,
dass ich Neutrino mit kill nicht beenden konnte, es erschien
mehrfach die Logmeldung meines Patches
received signal, waking-up LCD...
aber Neutrino lief weiter. Dabei war es egal, ob ich die
Haupt-PID, alle PIDs (kill w x y z) oder "killall neutrino"
aufgerufen habe. Nur kill -9 funktionierte noch...

Ich habe den Patch daher aus dem ULC entfernt und poste
ihn hier zu Dokumentationszwecken. Für mich ist das
Thema erstmal erledigt.

Code: Alles auswählen

--- ../cvs/apps/tuxbox/neutrino/src/neutrino.cpp        2009-02-22 19:45:44.000000000 +0100
+++ ./apps/tuxbox/neutrino/src/neutrino.cpp     2009-03-04 20:52:47.000000000 +0100
@@ -1935,6 +1935,13 @@
        }
 }

+static void signalHandler(int /*signum*/)
+{
+       // turn on LCD display
+       dprintf(DEBUG_NORMAL, "received signal, waking-up LCD...\n");
+       CLCD::getInstance()->wake_up();
+}
+
 int CNeutrinoApp::run(int argc, char **argv)
 {
        CmdParser(argc, argv);
@@ -2241,6 +2248,12 @@

        execute_start_file(NEUTRINO_INIT_END_SCRIPT, false);

+        //catch all signals
+        signal(SIGHUP, signalHandler);
+        signal(SIGINT, signalHandler);
+        signal(SIGQUIT, signalHandler);
+        signal(SIGTERM, signalHandler);
+
        RealRun(mainMenu);

        ExitRun(true);
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von seife »

Wir könnten ein "aufräum-Binary", das das Frontend in standby schickt, das LCD wieder anmacht etc. basteln, was dann beim shutdown aufgerufen wird.
Schreib's mal jemand auf meine Liste :-)
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von Barf »

Habe den Thread erst neulich entdeckt,...

Das das System nach einem unsauberes "runterfahren" (wie z.B. halt) in einem "komischen" Zustand sich befindet finde ich (normalerweise) nicht ein Problem, dass eine Lösung erfordert. Insbesonderes kein Hack.

Unabhängig davon halte ich eine vernünftige signal handling in Neutrino für sehr wünschenswert. Dabei soll, bei den normalen, "beende-dich"-Typ Signale, Neutrino so sich verhalten wie man es erwartet, d.h., nach Aufräumarbeiten sich beenden. Wegen

Code: Alles auswählen

until neutrino -f -u ; do
(start_neutrino) sogar mit (am mindestens für ein Signal) exitstatus 0. (In rhabarber1848s Signalhandler sollte also ExitRun aufgerufen werden.)

Danach könnte man ein einfaches shutdown Kommando implementiern z.B. als

Code: Alles auswählen

#!/bin/sh

if [ $1 = "s" ] ; then
    touch /tmp/.nohalt
elif [ $1 = "-r" ] ; then
    touch /tmp/.reboot
fi

killall -HUP neutrino
um ein sauberes Runterfahren von der Shell zu implementieren. Dies haben wir z.Z.nicht!!!
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von rhabarber1848 »

Durch lcdcmd (Quelle) bin ich wieder auf das Thema gestoßen.

Wenn in einem Yadd "lcdcmd -on" vor lcdmenu in /etc/init.d/start steht,
wird das LCD-Display korrekt wiedereingeschaltet. lcdcmd sendet dazu
zwei Befehle, LCD_IOCTL_ON an /dev/dbox/lcd0 und FP_IOCTL_LCD_DIMM
an den Frontprozessor /dev/dbox/fp0. Das ist wahrscheinlich die Erklärung,
warum U-Boot alleine mit Befehlen an das LCD nicht funktionierte, das
Display war mittels Frontprozessor gedimmt.

Nun die Frage: Kann U-Boot Befehle an den Frontprozessor senden?
Falls nicht, dann reicht dieser positiv getestete Patch im FP-Kernelmodul,
der den Dimm-Modus deaktiviert: fp_lcd_init.diff
Der Wert 150 stammt aus lcdcmd.c, der Befehl ist aus "case FP_IOCTL_LCD_DIMM"
in dbox2_fp_core.c entnommen.

Eine andere Methode im Userspace wäre mittels liblcddisplay: lcd_poweron.diff
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von rhabarber1848 »

rhabarber1848 hat geschrieben:Nun die Frage: Kann U-Boot Befehle an den Frontprozessor senden?
Kann das jemand beantworten? Falls das möglich wäre,
könnte man dann auch die Tasten am Gerät auslesen,
um z.B. den Bootvorgang wahlweise von HDD oder aus
dem Flash auszuführen?
rhabarber1848 hat geschrieben:Falls nicht, dann reicht dieser positiv getestete Patch im FP-Kernelmodul,
der den Dimm-Modus deaktiviert: fp_lcd_init.diff
Das gleiche, positiv getestet, für Kernel 2.6: fp_lcd_init26.diff
Zuletzt geändert von rhabarber1848 am Dienstag 23. Juni 2009, 11:36, insgesamt 1-mal geändert.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von seife »

rhabarber1848 hat geschrieben:
rhabarber1848 hat geschrieben:Nun die Frage: Kann U-Boot Befehle an den Frontprozessor senden?
Kann das jemand beantworten?
Der u-boot kann das (noch) nicht, es gibt keinen Frontprozessor-Treiber.
Falls das möglich wäre,
könnte man dann auch die Tasten am Gerät auslesen,
um z.B. den Bootvorgang wahlweise von HDD oder aus
dem Flash auszuführen?
Ja, das hätte ich auch gern, das schau ich mir auch mal an, ich weiss nur noch nicht, wann.
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: Gedimmtes LCD bleibt dunkel nach Telnet halt

Beitrag von rhabarber1848 »

rhabarber1848 hat geschrieben: und FP_IOCTL_LCD_DIMM
an den Frontprozessor /dev/dbox/fp0. Das ist wahrscheinlich die Erklärung,
warum U-Boot alleine mit Befehlen an das LCD nicht funktionierte, das
Display war mittels Frontprozessor gedimmt.
Patches für Kernel 2.4 und 2.6 committed:
http://article.gmane.org/gmane.comp.vid ... ox.scm/732
http://article.gmane.org/gmane.comp.vid ... ox.scm/733