Posts by Tomekki

    Aha, interessant .
    Das bedeutet, dass der Controller grundsätzlich in der Lage sein sollte meinen TFT anzusteuern *verhaltene Freude*.

    Das Problem ist, dass ich kein weiters Zubehör -wie die Kabel- besitze und mir der Verdrahtungsplan nur bedingt hilft.

    Daher habe ich bei dem Verkäufer freundlich nach dem Datenblatt angefragt.
    Mit Glück sendet er mir die Pinnbelegung (oder ähnliches) zu.

    Falls einer von euch detailliere Informationen hat, wäre ich natürlich dankbar.

    Gruß, Tomek

    Hallo,
    ich würde gerne wissen, ob ich mein TFT-Display von meinem alten Laptop
    als Monitor für ein VDR verwenden kann?

    Nach Recherchen habe ich herausgefunden, dass mein TFT-Display den LVDS Standart unterstützt.

    Mir ist per Zufall ein TFT-Controller (Faroudja Deinterlacer FLI 2300) in die Hände gefallen:
    [Blocked Image: http://img207.imageshack.us/img207/8943/cimg3728yb0.th.jpg]
    Deswegen auch die Idee das alte TFT-Display weiterzuverwenden :)

    Hier alle infos die ich zu dem TFT-Controller auftreiben konnte:

      * Der TFT-Controller wird in Sonyo's TM396WX-71N31 Fernseher verbaut.

      * Auf vdr-wiki.de hat ein gewisser Wirbel die Hardware bereits vorgestellt (siehe auch Verdrahtungsplan).

      * Falls dieser TFT-Controller für einen von euch auch interessant ist, habe ich auch einen Handler
      gefunden, der diesen Controller über ebay vertreibt. Allerdings ohne weiteres Zubehör.

      * Auf der Platine sind die Chips von Gensis FLI2300 & JagASM verlötet.

      * Das Datenblatt für den FLI2300 habe ich hier gefunden.

    Vielen Dank, Gruß Tomekki

    Quote

    Original von horchi
    was steht oben im Theme File, dort sollte 720 x 576 stehen.
    horchi


    Ja, das stimmt. Daraufhin habe ich auch mal folgendes probiert:

    Code
    [Theme]
    
    
    Item=Theme,name=DeepBlue,dir=DeepBlue,width=800,height=600,version=0.2.0,startImage=backgrounds/start-blue.jpg,endImage=backgrounds/end-blue.jpg;


    In beiden Fällen habe ich die schwarzen Streifen. Ist 720 x 576 etwa die Maximalgröße?

    Hi horchi,

    Quote

    Original von horchi
    was steht im log wenn er nicht startet, ist dort ein Hinweis zu finden?

    Auszug aus meinem log (/var/log/messages):

    Das log gibt leider nichts her. Nur von '/usr/share/vdr/rcscript/post-start-50-svdrp.sh failed' ist die Rede.

    Gibt es noch weitere Logdateien?

    Hallo,
    ich habe noch eine "kosmetische" Frage.

    Ich habe bei der Ausgabe via graphtft-fe (0.1.7.alpha) einen schwarzen Trauerstreifen auf der rechten und der unteren Kante. Wie kann ich diesen abschalten?

    Hier mein Konsolenaufruf:

    Code
    /opt/graphtft/graphtft-0.1.7.alpha/graphtft-fe/graphtft-fe -h 127.0.0.1 -r -W 800 -H 600 -e 3

    Ich habe ebenfalls einen 800 x 600 Pixel großen Monitor.

    thx

    Gruß, Tomekki

    Hallo horchi,
    ab Version 0.1.8_alpha funktioniert graphtft bei mir nicht mehr.
    Ich setzte Gentoo mit graphtft-fe ein.

    # Problem 1 (graphtft-fe seitig)
    Die Datei graphtft-fe/comthread.cc lässt sich nicht bauen, da ein Anführungszeichen an der falschen Stelle zu stehen scheint.

    Code
    # ./build.sh
    comthread.cc: In member function 'virtual void ComThread::run()':
    comthread.cc:92: error: expected `)' before 'status'
    make: *** [comthread.o] Error 1

    # Problem 2 (vdr seitig)
    VDR startet nicht, wenn ich als Option '--plugin=graphtft -d none'
    anhänge. Wenn ich '--plugin=graphtft -d /dev/fb0' anhänge startet vdr sauber.
    Leider wird beim Absturz kein core-file erzeugt, sonst hätte ich das backtrace gepostet.

    Gruß, Tomekki

    Hallo FireFly,
    ich habe ein x86_64 System (Gentoo).
    Ich setzte vdr 1.4.7 ein. Eben habe ich es auch mit 1.5.9 probiert. Auch hier habe ich den gleichen Fehler.


    gcc:

    Code
    # gcc -v
    Using built-in specs.
    Target: x86_64-pc-linux-gnu
    Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --enable-multilib --enable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
    Thread model: posix
    gcc version 4.1.2 (Gentoo 4.1.2)

    Gruß, Tomekki

    Hallo,
    ich kann das Elchi-Skin in der Version 0.1.1pre2 nicht kompilieren. Kann mir hier jemand weiterhelfen?

    Auszug des Kompilierens:

    Code
    g++ -march=nocona -O2 -pipe -fPIC -fPIC -fPIC -fPIC -fPIC -c -DCONFDIR=\"/etc/vdr\" -DUSE_CHANNELSCAN -DUSE_CUTTERLIMIT -DUSE_CUTTERQUEUE -DUSE_CUTTIME -DUSE_DOLBYINREC -DUSE_DVDARCHIVE -DUSE_GRAPHTFT -DUSE_JUMPPLAY -DUSE_LIEMIKUUTIO -DUSE_PLUGINMISSING -DUSE_SORTRECORDS -DUSE_WAREAGLEICON -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"skinelchi"' -DHAVE_IMAGEMAGICK -I/usr/include/  skinelchi.c
    skinelchi.c:25: error: expected unqualified-id before string constant
    skinelchi.c:25: error: expected initializer before string constant
    make: *** [skinelchi.o] Error 1

    An Zeile 25 von skinelchi.c steht folgendes:

    Code
    static const char *VERSION      = "0.1.1pre2";

    Ich wundere mich doch sehr, dass eine Konstantenzuweisung Probleme bereitet. :schiel Übrigendes, wenn ich diese Zeile auskommentiere lässt sich das Plugin bauen.


    Gruß, Tomekki

    Finally !:) :

    Das war für mich als Javaentwickler neu: Ein Stacktrace vom Debugger ohne
    die laufende Anwendung :)

    Gruß, Tomekki

    Hallo horchi,
    bei der Ausgabe von gdb bekomme ich bis jetzt nur die spärliche Ausgabe:


    Das wird dir sicher nicht helfen. Hmm. dabei habe ich vdr mit debug-Informationen kompiliert.
    Ich bleib dran, wäre aber über Hilfestellungen dankbar. Ich habe halt bis jetzt nicht viel mit Linixprogrammierung zu tun gehabt.

    Gruß, Tomekki

    Hallo horchi,
    ich verwende die Version vdr-graphtft-0.1.7_alpha auf
    meiner Gentoo Maschine:

    Ich versuche gleich mal das Backtrace hinzubekommen.

    Vielen Dank für deine Geduld!
    Gruß, Tomekki

    Hallo horchi,
    die Ausgabe nachdem ich deinen Patch angewendet habe, sieht wie folgt aus:

    Code
    01:16:36,856 Trying connecting to '127.0.0.1' at port (2039)
    01:16:36,856 Connection to '127.0.0.1' established
    01:16:37,599 Got welcome
    01:16:37,659 Error: Communication problems, closing line! status was (-93)
    01:16:37,659 Retrying in 5 seconds
    01:16:42,690 Trying connecting to '127.0.0.1' at port (2039)
    01:16:42,690 Connection to '127.0.0.1' established
    01:16:42,827 Got welcome
    01:16:42,855 Error: Communication problems, closing line! status was (-93)
    01:16:42,855 Retrying in 5 second
    Quote

    Original von horchi
    Du verwendest die fe Version aus dem gleichen tar wie auch das graphTFT Plugin?


    Ja, das tue ich.

    Mir ist grad noch aufgefallen, dass sich VDR nach dem Verbindungsversuch von graphTFT neustartet. Die Logdatei (/var/log/messages) sieht dabei Fehlerfrei aus:


    Ja ich weiß, ich muss mal meine Uhr stellen ;)

    Ich hoffe die Informationen Helfen dir weiter ...

    Gruß, Tomekki

    Hallo horchi,
    ich war mit dem Port 2001 wirklich auf auf dem Holzweg. Bei dem Port handelt es sich um das SVDRP (Simple VDR Protokoll) um VDR fernzusteuern.
    Wieder was dazugelernt :)

    Mit dem richtigen Port erhalte ich die leider folgenden Fehler:

    Code
    # DISPLAY=:0.1
    # ./graphtft-fe -h 127.0.0.1 -n -r -f -W 800 -H 600 -e 3
    21:55:58,189 Trying connecting to '127.0.0.1' at port (2039)
    21:55:58,189 Connection to '127.0.0.1' established
    21:55:58,891 Got welcome
    21:55:58,919 Error: Communication problems, closing line!
    21:55:58,919 Retrying in 5 seconds

    Ich verwende VDR in Version 1.4.7, falls dies interessant ist.

    Hast du noch eine Idee was bei mir falsch laufen könnte?

    Gruß, Tomekki

    Hallo horchi,
    ja, es läuft nur vdr auf diesem Port. Das habe ich auch mit netstat geprüft und in meiner vdradmin.conf habe ich ebenfalls diesen Port eingetragen und kann mit vdradmin (wenn es läut) über diesen kommunizieren.
    Außerdem habe ich zum Testen mal den freien Port 1234 ausprobiert; In diesem Falle bekomme ich auch eine eindeutige Fehlermeldung dass die Verbindung nicht zur Stande kommt. Zudem erscheint auch die Meldung "Connection to '127.0.0.1' established" nicht.

    Ich versuche heute Abend mal die TCP-Kommunikation abzuhören, möglicherweise hilft das weiter.

    Muss ich eventuell VDR auch neu kompilieren?

    Gruß, Tomekki

    Hallo horchi,
    wow, eine fe-Version von graphtft würde meine ganzen framebuffer Probleme
    in Luft auflösen.

    Ich bekomme beim Start von graphtft-fe den Fehler:
    "Got unexpected protocol (842149920), aborting"

    Kannst du dir auf diese Fehlermeldung einen Reim machen?

    Was bewirkt eigentlich der Schalter -n (not Managed)?

    Gruß, Tomekki

    Hallo peje.

    Quote

    Original von peje
    an der Baustelle graphtft über X könnte man auch noch bauen, oder sollte das mit dem ebuild auch gehen?
    cu peje

    In dem ebuild fehlt (noch ;)) die Unterstützung für directFB. Hiermit wäre eine gemischte Ausgabe von normalen X-Anwendungen und echten DirectFB-Anwendungen möglich.

    Quote

    Original von hd.brummy
    Alles was directFB betrifft ist im ebuild kommentiert; [...]


    Hier ist also deine Baustelle :)

    Gruß, Tomek

    Hallo hd.brummy,
    danke für deine zeitnahe Antwort.

    Ich habe jetzt zum erstem mal einen ebuild von innen gesehen, war gar nicht so schlimm ;).

    Ich habe bereits einen funktionierenden vesa Framebuffer. Diesen habe ich in Grub so eingerichtet:

    Code
    title=Gentoo Linux 2.6.22-rc1 (vesa splash LiveCD)
    root (hd0,0)
    kernel /boot/kernel-2.6.22-rc1 root=/dev/md3 video=vesafb:ywrap,mtrr:3,ywrap vga=0x317 splash=verbose,theme:livecd-2007.0 CONSOLE=/dev/tty0
    initrd=/boot/fbsplash-livecd-2007.0-1024x768

    Die Streifen sind nach wie vor da. Bevor ich weiter frage probiere eine andere Framebuffer Ausgabe aus.

    Stimmt, der gentoo-de overlay ist wirklich etwas angestaubt und ist heraus geflogen.

    Die Ausgabe via directFB wäre für den Anwender am einfachsten.
    Falls du dieses oder ein anderes VDR-ebuild extern testen möchtest,
    bin ich gerne dazu bereit (habe ein x86_64 system). Du kannst mich direkt ansprechen; siehe pn.

    Gruß, Tomekki

    Hallo,
    ich bekomme mit graphTFT nur unleserliche Streifen über
    meine Grafikkarte angezeigt. Ich habe gestern meine
    Versuche abgebrochen und hoffe ihr habt noch eine Idee.

    Über das VDR-OSD Menü kann ich auf das Plugin zugreifen, so
    dass ich davon ausgehe, dass es ordentlich installiert wurde.

    Habe ich noch etwas vergessen?

    In der originalen INSTALL von vdr-graphtft-0.1.7.alpha werden noch die
    folgenden Pakete als Abhängigkeiten angesprochen:
    * imlib2
    * DirectFB
    * ffmpeg
    * libsoftmpeg

    Die ersten habe ich auch installieren können:

    Code
    [ebuild   R   ] media-libs/imlib2-1.4.0  USE="X gif jpeg nls png tiff zlib -bzip2 -doc (-mmx) -mp3" 0 kB
    [ebuild   R   ] dev-libs/DirectFB-1.0.0  USE="gif jpeg mmx png sdl sse truetype zlib -debug -fbcon -fusion -sysfs -v4l -v4l2" 0 kB
    [ebuild   R   ] media-video/ffmpeg-0.4.9_p20070616-r1  USE="X imlib mmx sdl truetype zlib -a52 -aac (-altivec) -amr -debug -doc -encode -ieee1394 -network -ogg -oss -test -theora -threads -v4l -vorbis -x264 -xvid" 0 kB

    Das Packet libsoftmpeg konnte leider nicht installieren,
    da das abhängige Packet 'FusionSound'
    sich nicht bauen lies. Ich benötige doch gar keine Audiounterstützung, oder?

    Gruß, Tomekki

    Ich habe das Problem gefunden.
    Es lag an einem fehlenden Audio Decoder Plugin (konkret mad) des xine-lib Paketes.

    Es folgt die Ausgabe meiner xine-lib plugins nach dem Neukompilieren:


    Danke für eure Aufmerksamkeit.

    Gruß, Tomekki