Startbild der m740AV

[FFischer]

Hallo Forum,
hat hier schon jemand einen Hinweis zum Startbildschirm der Box :confused:
Ich habe bisher keine Anzeigemöglichkeit bzw. Änderungsmöglichkeit für die Startanzeige gefunden.
Ist dies überhaupt /usr/share/startbild1_cf <startbild2_cf> ?

[Lemmi]

Hallo Forum,
hat hier schon jemand einen Hinweis zum Startbildschirm der Box :confused:
Ich habe bisher keine Anzeigemöglichkeit bzw. Änderungsmöglichkeit für die Startanzeige gefunden.
Ist dies überhaupt /usr/share/startbild1_cf <startbild2_cf> ?

Ich mutmaße: JA
Es handelt sich aber um Programme, die wahrscheinlich das Startbild darstellen.

[spitt]

Diese Vermutung klingt einleuchtend. Würde auch Sinn machen, da man evtl. dynamische Daten mit einbauen könnte (Fortschritt, etc.), auch wenn dies bisher nicht der Fall ist.

Das eröffnet vielleicht eine neue Erweiterungsmöglichkeit... ;)

[max]

das wird nicht gerade trivial sein.
Vielleicht eine Option des Bootloaders?
Evt. ein Kernelpatch wie bootsplash (siehe http://www.bootsplash.org/)

Das wäre dann nix das man mal einfach so ändert indem man eine Bilddatei austauscht.

Allerdings fände ich die Option auf Bootmeldungen ziemlich klasse.

Gruss

[shrike]

Der Startbildschirm wird nicht über die ausführbaren Dateien /usr/share/startbild{1|2}_cf sondern über die Datei /data/disp_startbild dargestellt.

/user/share/startbild1_cf erzeugt das folgende Bild:
http://suerge.de/startbild1_cf.jpg
Interessant: Unter der angegebenen URL http://carrefouronline.tv erscheint eine nicht eingerichtete Domain.

/user/share/startbild2_cf erzeugt das folgende Bild:
http://suerge.de/startbild2_cf.jpg
Das Ergebnis ist ähnlich wie bei startbild1_cf. Der aktuelle Fernsehkanal wird im Hintergrund weiterhin angezeigt. starbild2_cf hat also eher OSD-Charakter.

Leider habe ich keine Ahnung, was disp_startbild (noch) alles treibt. Habe auch das eine oder andere *.png-Bild in den Verzeichnissen gefunden, allerdings keines, das dem Startbild der Box entspricht -> wahrscheinlich verarbeitet disp_startbild keinen externen Bildparameter.

Hat jemand weitere Ideen für eine Änderung des Startbildes?

[andreas.koch]

Leider habe ich keine Ahnung, was disp_startbild (noch) alles treibt. Habe auch das eine oder andere *.png-Bild in den Verzeichnissen gefunden, allerdings keines, das dem Startbild der Box entspricht -> wahrscheinlich verarbeitet disp_startbild keinen externen Bildparameter.

Hat jemand weitere Ideen für eine Änderung des Startbildes?
Ich bin jetzt nicht ganz sicher was du gemacht hast? Was hast du augeführt und wie? Nur das eine Datei das Attribute-Ausführbar gesetzt hat, muß nicht heißen das sie das auch ist.
Das Startbild (wie alle Bilder) wird meines Wissen über den Framebuffer /dev/fb0 dargestellt. Das ist ein Memory-Device (heißt man kann darauf nach belieben schreiben und davon lesen). Läuft die Box ist der für das OSD reserviert, und wird im RAW-ARGB-Format mit 720x576x32 interlaced betrieben. Man kann z.B. mit "cat /dev/fb0 > bild.raw" einen Screenshot vom OSD machen. Umgekehrt gehts genauso, man kann ein Bild im RAW-Format als OSD z.B. so Anzeigen "cat bild.raw > /dev/fb0".
Zum Startzeitpunkt der Box benutzt der Framebuffer aber glaube ich nur 15 Bit. Siemens/wavebug nutzt die Library libdirectfb für die Darstellung des OSDs. Das Startbild selber wird irgendwie von wavebug ausgegeben. Es könnte sein das es irgendwo als RAW-Image auf der Box liegt, oder aber fest in ein Binary kompiliert ist.
Bei letzterem wird man wohl kaum eine Chance habe es auszutauschen.

Grüße

Andreas

[api]

Läuft die Box ist der für das OSD reserviert, und wird im RAW-ARGB-Format mit 720x576x32 interlaced betrieben. Man kann z.B. mit "cat /dev/fb0 > bild.raw" einen Screenshot vom OSD machen. Umgekehrt gehts genauso, man kann ein Bild im RAW-Format als OSD z.B. so Anzeigen "cat bild.raw > /dev/fb0".
Zum Startzeitpunkt der Box benutzt der Framebuffer aber glaube ich nur 15 Bit. Siemens/wavebug nutzt die Library libdirectfb für die Darstellung des OSDs.
Da hänge ich mich mal etwas 'off topic' dran:
Ich suche nach einer Möglichkeit, an die Reaktion der Box auf Fernbedienungskommandos (lircd) heranzukommen. Grundsätzlich wäre ein Auslesen von /dev/fb0 zu diesem Zweck möglich, aber sicherlich nicht sehr effektiv. (Ich hab's probiert, es geht tatsächlich.)
@andreas.koch: Hälst Du es irgendwie für möglich, die Kommunikation der Library libdirectfb 'abzuhören' und daraus auf den Inhalt des OSD zu schließen?
Man könnte damit die Reaktion auf Kommandos des EPG-PHP-Scriptes auswerten und die Abarbeitung der Kommandos beschleunigen.
Man könnte dann auch z.B. ein 'Schatten-OSD' auf dem PC darstellen.

[shrike]

Hi Andreas,

Ich bin jetzt nicht ganz sicher was du gemacht hast? Was hast du augeführt und wie? Nur das eine Datei das Attribute-Ausführbar gesetzt hat, muß nicht heißen das sie das auch ist.Da hast du natürlich recht, aber sowohl /usr/share/startbild{1|2}_cf als auch /data/disp_startbild sind ausführbare Dateien (ELF-Binaries). Mein Vorgehen: Login auf der Box via Telnet, Ausführen der genannten Dateien auf Kommandozeile. Auf dem Fernseher erscheint bspw. nach Eingabe von /data/disp_starbild das bekannte Einschaltbild der Box (weißer Gigaset-Schriftzug auf schwarzem Hintergrund).

Ich würde somit deiner Theorie des einkompilierten Bildes in ein Binary (=disp_starbild) recht geben. Wahrscheinlich ruft wavebug irgendwann disp_startbild auf, um das Einschaltbild anzuzeigen. Wie hast du herausgefunden, daß "Das Startbild selber [...] irgendwie von wavebug ausgegeben [wird]"?

Danke für die interessanten Zusatzinfos bzgl. /dev/fb0. Nach einigen Experimenten die Frage, wie denn so ein Screenshot auf dem PehZeh wieder angezeigt werden kann? Dachte, ich kenne mich ein wenig mit Bildbearbeitung aus, aber ich hatte bis dato noch keinen Kontakt mit dem raw-Format: Zumindest IrfanView als auch Photoshop scheitern an den ~2MB großen Screenshots.

Grüße
Shrike

[Flyer2]

Da hänge ich mich mal etwas 'off topic' dran:
Ich suche nach einer Möglichkeit, an die Reaktion der Box auf Fernbedienungskommandos (lircd) heranzukommen. Grundsätzlich wäre ein Auslesen von /dev/fb0 zu diesem Zweck möglich, aber sicherlich nicht sehr effektiv. (Ich hab's probiert, es geht tatsächlich.)
@andreas.koch: Hälst Du es irgendwie für möglich, die Kommunikation der Library libdirectfb 'abzuhören' und daraus auf den Inhalt des OSD zu schließen?
Man könnte damit die Reaktion auf Kommandos des EPG-PHP-Scriptes auswerten und die Abarbeitung der Kommandos beschleunigen.
Man könnte dann auch z.B. ein 'Schatten-OSD' auf dem PC darstellen.

Um an die Eingaben der Fernbedienung zu kommen kann man die libdirectfb
verwenden. Im Anhang findest Du die Quellen für ein Tetris auf der Box
dabei werden die Pfeiltasten der Fernbedienung zur Steuerung verwendet(Zeile 465ff).
Um die Datei zu übersetzen braucht man die DirectFb Header (hab ich mir von
www.directfb.org gezogen) und die auf der Box vorhandene Library zum
Linken.

Ein Programm zur Darstellung von png oder jpg Dateien auf der Box hab ich vor
einigen Tagen hier im Forum gepostet (http://www.m740.de/forum/showthread.php?t=876). Wenn man die disp_startbild
dadurch ersetzt sollte ein eigenes Startbild möglich sein.

[andreas.koch]

Hälst Du es irgendwie für möglich, die Kommunikation der Library libdirectfb 'abzuhören' und daraus auf den Inhalt des OSD zu schließen?
Man könnte damit die Reaktion auf Kommandos des EPG-PHP-Scriptes auswerten und die Abarbeitung der Kommandos beschleunigen.
Man könnte dann auch z.B. ein 'Schatten-OSD' auf dem PC darstellen.
Da fragst du mich was.
Würde erstmal davon ausgehen das die Lib nur /dev/fb0 mmap, und in den gemappen Bereich schreibt. Der Framebuffer kennt zwar auch ioctl-Calls, aber die sind für sowas eher zu vernachläßigen, vorallendingen weil man nicht genau weiß was Siemens von den implementiert (ein Blanking per ioctl funktionierte bei einem meiner Test z.B. nicht) hat.
Die andere Variante (ich glaube die meintes du) Calls von wavebug zur Lib abzuhören, halte ich für schwierig. Die einfachste Methode die mir gerade einfällt wäre:
1. Man benennt libdirectfb* in libdirectfb_echt* um.
2. Man schreibt eine Library libdirectfb die exact die selbe API wie die echte libdirectfb hat. Diese enthält allerdings nur Funktionen die auf libdirectfb_echt* verweisen (über dlopen, dlsym, usw.), in den kann man dann alles mithören.
3. Hoffen, das ld sich so verarschen läßt, und keine ungewollten Rekursionen auftreten.

Wenn man nicht die komplete API abbilden will, könnte man evtl. die lib mit einem Filter (ld-Flag --auxilliary) neulinken, der Teile der API enthält (weiß nur nicht in wie man von da aus noch auf die orginale Lib zugreifen kann).

Evtl. reichen aber auch schon API-Calls zur libdirectfb aus, hab mich aber mit der Library nicht beschäftigt.

Alles andere geht ins eingemacht, da die Kommunikation ja über Funktionen, die irgendwo (eben dynamisch) im RAM stehn, von statten geht.

Auf was man dann von den Calls schließen kann, kann ich nicht sagen, aber die API der Lib ist ja vollständig dokumentiert.

Für ein Schatten-OSD würde ich allerdings ehr den Framebuffer selber benutzen.

Grüße

Andreas

[andreas.koch]

Ich würde somit deiner Theorie des einkompilierten Bildes in ein Binary (=disp_starbild) recht geben. Wahrscheinlich ruft wavebug irgendwann disp_startbild auf, um das Einschaltbild anzuzeigen. Wie hast du herausgefunden, daß "Das Startbild selber [...] irgendwie von wavebug ausgegeben [wird]"?

wavebug killen und neustarten, dann kommt der Startscreen.
disp_startbild scheint auch nur ein Bild direkt auf den Framebuffer zu schreiben, evtl. setzt es noch die Auflösung.


Danke für die interessanten Zusatzinfos bzgl. /dev/fb0. Nach einigen Experimenten die Frage, wie denn so ein Screenshot auf dem PehZeh wieder angezeigt werden kann? Dachte, ich kenne mich ein wenig mit Bildbearbeitung aus, aber ich hatte bis dato noch keinen Kontakt mit dem raw-Format: Zumindest IrfanView als auch Photoshop scheitern an den ~2MB großen Screenshots.
RAW:= Roh. Soll heißen, da stehen einfach nur ARGB Farbwerte (32 Bit) für jedes Pixel hintereinander weg drin (in diesem Fall für 720x576 Bildpunkte allerdings interlaced).

Grüße

Andreas
P.S.: Ob und wie man Photoshop o.ä. dazu benutzen kann die Bilder darzustellen weiß ich nicht, benutze schon seit Jahren kein Windows mehr (zumindest nicht wenn ich nicht muss).

[api]

Um an die Eingaben der Fernbedienung zu kommen kann man die libdirectfb verwenden.
Die Eingabe der Fernbedienung kenne ich in diesem Fall bereits: Die habe ich ja selbst erzeugt und mit lircd zur Box übertragen.

Ich möchte die Reaktion der Box auf die Eingaben beobachten! Und diese Reaktion äußert sich nunmal im OSD.

[api]

Die andere Variante (ich glaube die meintes du) Calls von wavebug zur Lib abzuhören, halte ich für schwierig.

Die einfachste Methode die mir gerade einfällt wäre:
1. Man benennt libdirectfb* in libdirectfb_echt* um.
2. Man schreibt eine Library libdirectfb die exact die selbe API wie die echte libdirectfb hat. Diese enthält allerdings nur Funktionen die auf libdirectfb_echt* verweisen (über dlopen, dlsym, usw.), in den kann man dann alles mithören.
3. Hoffen, das ld sich so verarschen läßt, und keine ungewollten Rekursionen auftreten.

An so was in der Art dachte ich. Wäre also theoretisch möglich.
Danke.

[andreas.koch]

An so was in der Art dachte ich. Wäre also theoretisch möglich.
Danke.
Theoretisch ist viel möglich, ob das dann allerdings praktisch relevant ist die Frage.
Mir ist noch eine andere Variante eingefallen: Wenn Siemens die Lib nicht (wie bei der libjpeg) bis ins ungekenntlich gepacht (steht ja in den Siemenssourcen) hat, kann man die Calls auch direkt durch eine modifizierte Library abfangen. Allerdings weiß ich nicht ob und was Siemens an der Lib geändert, und ob sich diese aus den Siemenssourcen noch neukompilieren läßt (es fehlen an einigen Stellen nämliche Teile).
Da du die Box ja fernsteuern willst, könnte der Filter über den Linker auch interessant sein (der ist eigentlich für Debuging oder Profiling Version von Funktionen gedacht).
Da der Filter (vielmehr das shared-object, durch das gefilltert wird) nicht vorhanden sein muß, könnte man so auch die Darstellung des OSD durch setzen/löschen eines Links an- und ausschalten (und hätte so an Geschwindigkeit gewonnen, da das Darstellen entfällt).

Grüße

Andreas

[api]

Mir ist noch eine andere Variante eingefallen: Wenn Siemens die Lib nicht (wie bei der libjpeg) bis ins ungekenntlich gepacht (steht ja in den Siemenssourcen) hat, kann man die Calls auch direkt durch eine modifizierte Library abfangen. Allerdings weiß ich nicht ob und was Siemens an der Lib geändert, und ob sich diese aus den Siemenssourcen noch neukompilieren läßt (es fehlen an einigen Stellen nämliche Teile).
Da du die Box ja fernsteuern willst, könnte der Filter über den Linker auch interessant sein (der ist eigentlich für Debuging oder Profiling Version von Funktionen gedacht).
Da der Filter (vielmehr das shared-object, durch das gefilltert wird) nicht vorhanden sein muß, könnte man so auch die Darstellung des OSD durch setzen/löschen eines Links an- und ausschalten (und hätte so an Geschwindigkeit gewonnen, da das Darstellen entfällt).

OSD auf der Glotze abschalten und nur Infos an den Rechner senden: Das ist doch mal 'ne Idee! Eine(r) kann Fernsehen und der(die) Andere, ohne zu stören, den Timer programmieren. Hat was.
Und wie machen wir das konkret?

[andreas.koch]

OSD auf der Glotze abschalten und nur Infos an den Rechner senden: Das ist doch mal 'ne Idee! Eine(r) kann Fernsehen und der(die) Andere, ohne zu stören, den Timer programmieren.
Nur Umschalten könnte ein Problem werden.


Hat was. Und wie machen wir das konkret?
Wenn ich dieses Linker Flag (ld) "--auxialary name" richtig verstanden habe (und der ld.so auf der Box eben das Feld was damit gesetzt wird kennt). Kann man mit/in dem Shared Object "name" alternative Implementation von einzelnen Symbolen einer Lib angeben und "name" muß nicht vorhanden sein.
Beispiel (glaube so wirds leichter verständlich):
libdirectfb hat eine Funtkionen drawPNG (weiß nicht ob sie die hat, aber mal angenommen).
dann schreibe ich ein Lib fake_lib die drawPNG mit exakt den selben Parametern enthält. Das einzige was diese Funktion allerdings macht, ist die Information das drawPNG aufgerufen wurde weitergeben (wie auch immer) und den Return-Code das alles Ok war zurückgeben.
Dann linke ich libdirectfb (im aller letzten Schritt, wenn libdirectfb-x.x.so erstellt wird) --auxiliary use_fake_lib, und ersetze die Lib auf der Box mit dieser. Außerdem kopiere ich fake_lib auf die Box (am besten ins selbe Verzeichnis wie libdirectfb).
Setze ich nun den Linke von fake_lib zu use_fake_lib, würde jedes mal wenn die Funktion drawPNG aus der libdirectfb aufgerufen würde, stattdessen die Funktion aus fake_lib aufgerufen. Wenn use_fake_lib nicht existiert, wird die Funktion aus libdirectfb aufgerufen.
Das heißt ich kann über den Link steuern, wann tatsächlich etwas gezeichnet wird und wann nicht.

Die Idee ist aber noch nicht ganz ausgereift: Denn die Frage ist ob der dynamische Linker, tatsächlich jedes mal nach der alternativ Implementierung sucht oder nur wenn er das erst Mal das Symbol lädt. Das müßte man mal testen.

Grüße

Andreas

[api]

Wenn ich dieses Linker Flag (ld) "--auxialary name" richtig verstanden habe (und der ld.so auf der Box eben das Feld was damit gesetzt wird kennt). Kann man mit/in dem Shared Object "name" alternative Implementation von einzelnen Symbolen einer Lib angeben und "name" muß nicht vorhanden sein.
Beispiel (glaube so wirds leichter verständlich):
libdirectfb hat eine Funtkionen drawPNG (weiß nicht ob sie die hat, aber mal angenommen).
dann schreibe ich ein Lib fake_lib die drawPNG mit exakt den selben Parametern enthält. Das einzige was diese Funktion allerdings macht, ist die Information das drawPNG aufgerufen wurde weitergeben (wie auch immer) und den Return-Code das alles Ok war zurückgeben.
Dann linke ich libdirectfb (im aller letzten Schritt, wenn libdirectfb-x.x.so erstellt wird) --auxiliary use_fake_lib, und ersetze die Lib auf der Box mit dieser. Außerdem kopiere ich fake_lib auf die Box (am besten ins selbe Verzeichnis wie libdirectfb).
Setze ich nun den Linke von fake_lib zu use_fake_lib, würde jedes mal wenn die Funktion drawPNG aus der libdirectfb aufgerufen würde, stattdessen die Funktion aus fake_lib aufgerufen. Wenn use_fake_lib nicht existiert, wird die Funktion aus libdirectfb aufgerufen.
Das heißt ich kann über den Link steuern, wann tatsächlich etwas gezeichnet wird und wann nicht.

Hat libdirectfb der Box was mit der Bibliothek aus http://www.directfb.org zu tun?
Dann wären z.B. die Methoden CreateImageProvider und RenderTo potentielle Kanditaten zu Loggen.



/* create the image provider that will load the image */
dfb->CreateImageProvider( dfb, "tux.png", &provider );
/* render the image to the screen */
provider->RenderTo( provider, primary, NULL );

<Wunsch>Ist da etwa schon 'ne Art logging drin.</Wunsch>

[andreas.koch]

Hat libdirectfb der Box was mit der Bibliothek aus http://www.directfb.org zu tun?
Dann wären z.B. die Methoden CreateImageProvider und RenderTo potentielle Kanditaten zu Loggen.

Das ist die Lib, die Siemens in evtl. modifiziert Version benutzt, in den GPL-Sourcen von Siemens ist dies aber enthalten.

<Wunsch>Ist da etwa schon 'ne Art logging drin.</Wunsch>
Das weiß ich leider auch nicht, glaube aber nicht (debugging output gibts wohl, der wird aber vermutlisch auf stdout/stderr landen).

Grüße

Andreas