graphlcd (base, vdr-plugin) touchcol branch (archiv)

    In der graphlcd.conf eher so:
    ---
    Options=PARANOIA=off
    ---
    aber "l4m132c_tool" wertet die graphlcd.conf nicht aus. Das graphlcd Plugin tuts.


    cu

    Ah jetzt geht's, danke!!!

    VDR: yavdr-ansible/22.04 LTS auf Intel NUC (BOXNUC6CAYH), 2x Kingston KVR16LS11/4, One For All URC 2981

    VDR-Server: yavdr-ansible/22.04 LTS in ESXi VM

    Fehlt nur noch die Anpassung für das l4m132c Tool bei mir, oder übersehe ich da wieder was?

    VDR: yavdr-ansible/22.04 LTS auf Intel NUC (BOXNUC6CAYH), 2x Kingston KVR16LS11/4, One For All URC 2981

    VDR-Server: yavdr-ansible/22.04 LTS in ESXi VM

    Herzlichen Dank wastl.


    Ich habe übrigens bei Verwendung von libusb ähnlich wie bei HID ab und an immer noch das Problem
    dass das Display einfriert. Aber lange nicht so häufig wie bei HID, es kommt ab und an mal
    vor. Wenn ich es mal wieder habe, werde ich mal Logs zur Verfügung stellen. Ich hoffe du findest dann
    mal Zeit dem Problem auf die Schliche zu kommen. Aber wie gesagt bei HID viel häufiger, mit libusb
    bin ich viel glücklicher, da das Display auch viel schneller aufbaut.


    Danke und LG Urknall

    VDR: yavdr-ansible/22.04 LTS auf Intel NUC (BOXNUC6CAYH), 2x Kingston KVR16LS11/4, One For All URC 2981

    VDR-Server: yavdr-ansible/22.04 LTS in ESXi VM

    Einmal editiert, zuletzt von urknall ()

    Keine_Ahnung:


    wie laeuft bei den diversen xbmc+vdr-konglomeraten eigentlich das zusammenspiel (kenne zwar beide, aber jew. nur unabhaengig vom anderen).
    zb bei yavdr: laeuft da hauptsaechlich xbmc und vdr wird aus xbmc heraus gestartet oder vdr startet xbmc?
    laufen dann beide gleichzeitig? (dh kann vdr aufnehmen waehrend man mit xbmc zb. fotos / filme schaut?) oder pausiert jew. eines davon?

    Zitat von wastl

    zb bei yavdr: laeuft da hauptsaechlich xbmc und vdr wird aus xbmc heraus gestartet oder vdr startet xbmc?
    laufen dann beide gleichzeitig? (dh kann vdr aufnehmen waehrend man mit xbmc zb. fotos / filme schaut?) oder pausiert jew. eines davon?


    Also bei yaVDR starten wir prinzipiell den VDR und dann je nach Frontendeinstellung zusätzlich das gewünschte VDR-Frontend (xine, vdr-sxfe) oder XBMC. Beim nachträglichen Start von XBMC läuft der VDR ebenfalls weiter (ist auch deshalb sinnvoll, da wir über das xvdr-plugin des VDRs Live-TV und Aufnahmen des VDR für XBMC bereitstellen. Für den VDR wird die Reaktion auf die Fernbedienung deaktiviert, sobald XBMC gestartet wird. Für das softhddevice müssen die entsprechenden Skripte zum suspenden der Ausgabe noch entwickelt werden.


    Graphlcd wird davon aktuell nicht beeinflusst, man sieht also was der VDR da im Hintergrund tut (wobei es sicher auch ganz interessant wäre das Display auf Wunsch auch für XBMC nutzen zu können).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von seahawk1986

    Graphlcd wird davon aktuell nicht beeinflusst, man sieht also was der VDR da im Hintergrund tut (wobei es sicher auch ganz interessant wäre das Display auf Wunsch auch für XBMC nutzen zu können).


    Geht ja, einfach graphlcd deaktivieren und per lcdproc aufs Display ausgeben lassen (per glcdlib oder serdisplib Ausgabetreiber als Textdisplayemulation). So mache ich das aktuell mit freevo.


    Alternativ könnte man auch nen xbmc/freevo Plugin schreiben was seine "Displayausgaben" per dbus an graphlcd schickt (anstatt zu lcdproc) und so xbmc/freevo ihre Ausgabe auf dem schönen Graphlcd Grafik-Display ausgeben können. Braucht dann nur ne Unterstützung vom Skin.


    cu

    wastl:


    Es ist gerade eben wieder passiert, Display eingefroren:



    Vielleicht kannst du damit ja schon was anfangen und hast eine Idee, ansonsten würde ich mich
    über Instruktionen freuen, wie wir dem Problem genauer auf die Spur kommen können.


    LG Urknall

    VDR: yavdr-ansible/22.04 LTS auf Intel NUC (BOXNUC6CAYH), 2x Kingston KVR16LS11/4, One For All URC 2981

    VDR-Server: yavdr-ansible/22.04 LTS in ESXi VM

    nicht wirklich eine ahnung.


    aendere mal in serdisp_connect_usb.c folgendes: ca zeile 1070:


    von

    Code
    #if 0
      	int ii;
      	fprintf(stderr, "ep: 0xx  length: %d: ", usbitems->out_ep, usbitems->streampos);
      	for (ii = 0; ii < usbitems->streampos; ii++)
        	fprintf(stderr, "x ", usbitems->stream[ii]);
      	fprintf(stderr, "\n");
#endif
      	sd_error(SERDISP_ERUNTIME, "%s(): L4M_E-5i/LCD commiting buffer failed, error: %s", __func__, strerror(errno));


    auf

    Code
    /*#if 0*/
      	int ii;
      	fprintf(stderr, "ep: 0xx  length: %d: ", usbitems->out_ep, usbitems->streampos);
      	for (ii = 0; ii < usbitems->streampos; ii++)
        	fprintf(stderr, "x ", usbitems->stream[ii]);
      	fprintf(stderr, "\n");
/*#endif*/
      	sd_error(SERDISP_ERUNTIME, "%s(): L4M_E-5i/LCD commiting buffer failed, error: %s", __func__, strerror(errno));
      	sd_runtimeerror = 1;


    ACHTUNG: der bloede editor macht hier '% 0 2 x' (leerzeichen hinzugefuegt, damit es hier nicht auch verwurschtet wird) zu einem nicht darstellbaren sonderzeichen oder so.
    es ist aber ohnedies nur das #if/#endif auszukommentieren und die zeile mit sd_runtimeerror = 1; hinzuzufuegen.



    das sollte den zuletzt geschriebenen datenstrom - bevor das display sich verabschiedet - hinausschreiben.
    das sd_runtimeerror bewirkt, dass nix weiter mehr versucht wird (und somit das log nicht zugemuellt wird).


    das ganze schreibt auf stderr hinaus! => daher vdr entsprechend starten (von command line aus oder so)


    oder ansonsten folgendes (dann wird das sauber ins /var/log/messages geloggt) und du kannst vdr wie gewohnt starten:




    achtung: ungetestet!


    EDIT: portal-editor hatte code-text massakriert

    Servus,


    hatte in letzter Zeit viel um die Ohren und erst jetzt wieder Zeit das Thema weiter zu verfolgen:



    Hier mal der erste Freeze von heute, ich werde das weiter beobachten und weitere Debugs liefern, falls sie unterschiedlich sein sollten...


    LG Urknall

    VDR: yavdr-ansible/22.04 LTS auf Intel NUC (BOXNUC6CAYH), 2x Kingston KVR16LS11/4, One For All URC 2981

    VDR-Server: yavdr-ansible/22.04 LTS in ESXi VM

    VDR: yavdr-ansible/22.04 LTS auf Intel NUC (BOXNUC6CAYH), 2x Kingston KVR16LS11/4, One For All URC 2981

    VDR-Server: yavdr-ansible/22.04 LTS in ESXi VM

    Mal ne kurze Zwischenfrage zur serdisplib 2.x...
    gibt es die Möglichkeit sie so zu bauen das die benötigten Libs dynamisch gelinkt werden? Ich meine nicht das explizite Laden zur Laufzeit mit dlopen sondern das andere. Übersehe ich da was?


    BTW: Mir ist aufgefallen das einige Dateien/Verzeichnisse beim Distclean nicht gelöscht werden
    ---
    serdisplib.pc
    serdisplib.spec
    stamp-h
    buildfiles/serdisplib_2.00.bb
    DOCS/Doxyfile
    DOCS/html
    include/serdisplib/serdisp_control.h
    ---
    Wobei ich hier gerade noch die svn 2012-01-30 habe und mit auch nicht sicher bin obs so gehört oder nicht. Wollts nur erwähnen weils mir auffiel.


    BTW2: Das Debianpaketbauwerkzeug meldet für die automatische Rechtschreibprüfung einige Fehler:
    ----
    I: serdisplib-tools: spelling-error-in-binary usr/bin/multidisplay Informations Information
    I: serdisplib-tools: spelling-error-in-binary usr/bin/serdisplearn programm program
    I: serdisplib-tools: spelling-error-in-binary usr/bin/testserdisp Informations Information
    I: libserdisp2: spelling-error-in-binary usr/lib/libserdisp.so.2.00 commiting committing
    ---


    cu

    Zitat von Keine_Ahnung

    Mal ne kurze Zwischenfrage zur serdisplib 2.x...
    gibt es die Möglichkeit sie so zu bauen das die benötigten Libs dynamisch gelinkt werden? Ich meine nicht das explizite Laden zur Laufzeit mit dlopen sondern das andere. Übersehe ich da was?

    ja. gibt es schon ziemlich lange: --disable-dynloading


    ist eh gut, wenn mal wer anderer damit herum spielt, habe es zwar schon in allen moeglichen konstellationen getestet, aber ich wuerde nicht die hand ins feuer legen fuer 100%ige fehlerfreiheit :)


    korrigiert, werden jetzt geloescht.

    nun ebenfalls korrigiert.

    Zitat von wastl

    ja. gibt es schon ziemlich lange: --disable-dynloading


    ist eh gut, wenn mal wer anderer damit herum spielt, habe es zwar schon in allen moeglichen konstellationen getestet, aber ich wuerde nicht die hand ins feuer legen fuer 100%ige fehlerfreiheit :)


    Ich habe irgendwie gerade den Anspruch nen Debian Paket zu bauen wo alles funktioniert ;)


    Wobei --disable-dynloading es noch nicht wirklich ist. So wie ich das sehe werden dann die drei (?) libs (libpthread , libSDL und libusb) direkt in die libserdisp.so eingelinkt (also mit eingefügt). Aber die ganzen Abhängigkeiten dieser Libs bleiben weiterhin bestehen (?).

    Code
    root@dirk-vdr:/usr/local/src/serdisplib-2.x+svn339/debian# ldd libserdisp2/usr/lib/libserdisp.so.2
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb759d000)
        /lib/ld-linux.so.2 (0xb773a000)


    Was IMHO für nen Linux mit Paketverwaltung wäre, wäre das selbe was jetzt bei den tools auch passiert (--disable-statictools).


    BTW: Wenn testserdisp den Treiber "REMOTE" nicht anbietet dann stimmt was mit den Laden der Netzwerklibs (libsocket.so, libnsl.so, libnet.so) nicht? Weil diese finde ich nirgends (aus welchen Projekt/Paket stammen die denn?). serdispd startet Problemlos und wartet, aber keines der Tools mag den REMOTE Treiber akzeptieren um was zum serdispd zu senden.


    BTW2: In serdisp_connect_usb.c hast du noch 3x "commiting" anstelle von "committing".


    cu

    <sarcasm>
    'debian' und 'alles funktioniert': ist das nicht ein widerspruch?
    </sarcasm>
    ok. der dzt. stand v. serdisplib/svn traegt jetzt auch nicht gerade dazu bei :)
    aber darum ist es ja auch noch keine stable-version ...


    committing: yep. in der tat. habs lokal bereits korrigiert, aber dann nicht committed, weil noch einiges debug-zeug drin ist wegen des sch*** aeh schoenen libusb0-compatibility-layers, mit dem ich noch kaempfe.


    das mit den abhaengigkeiten muss ich mir ansehen, das passt tatsaechlich nicht. aber die dependency-list von deinem testserdisp-beispiel laeuft schon sehr aus dem rahmen. die bekomme ich bei mir nicht einmal annaehernd hin, egal welche kombinationen ich versuche ... sogar asound, pulse und der ganze schmarrn (wird das bei debian ueber die libSDL hineingezogen?). sogar libcaca!!


    ad remote: wenn er beim configure-output hier drin ist:


    enabled(+) / disabled(-) drivers
    ================================
    + sed153x, pcd8544, sed156x, i2c, t6963, sed133x, nokcol, ks0108, lh155, ssdoled, l4m, goldelox, stv8105, acoolsdcm, directgfx, rs232, lc7981, ddusbt, framebuffer, remote
    - displaylink


    sollte er auch funktionieren ... du musst natuerlich --enable-experimental dafuer aktivieren (das ganze netzwerkzeug ist immer noch hochexperimentell und auch noch nicht fertig)

    Zitat von wastl

    <sarcasm>
    'debian' und 'alles funktioniert': ist das nicht ein widerspruch?
    </sarcasm>


    Das lasse ich jetzt mal unkommentiert ;)

    Zitat von wastl


    ok. der dzt. stand v. serdisplib/svn traegt jetzt auch nicht gerade dazu bei :)
    aber darum ist es ja auch noch keine stable-version ...


    Jup, ich finde da gerne Fehler.


    Zitat von wastl

    das mit den abhaengigkeiten muss ich mir ansehen, das passt tatsaechlich nicht. aber die dependency-list von deinem testserdisp-beispiel laeuft schon sehr aus dem rahmen. die bekomme ich bei mir nicht einmal annaehernd hin, egal welche kombinationen ich versuche ... sogar asound, pulse und der ganze schmarrn (wird das bei debian ueber die libSDL hineingezogen?). sogar libcaca!!


    Ja, das kommt von SDL, passt aber schon. Wobei aber SDL eigentlich gar nicht gegen jedes Tool gelinkt werden sollte. Weil direkt wird es ja von den Tools nicht genutzt wenn ich das richtig sehe.


    Wobei ich bei --disable-dynloading auch nicht sehe das da der serdisplib überhaupt irgendwas hinzugelinkt wird. Bei --disable-dynloading wird die Lib auch kleiner.


    Ich reiche dann hier im Postings mal zwei komplette Build Log nach, einmal mit --enable-dynloading und einmal mit --disable-dynloading


    Edit: https://www.dropbox.com/sh/mnaw649geme1j46/O3bSkZAwoF


    Zitat von wastl

    ad remote: wenn er beim configure-output hier drin ist:


    enabled(+) / disabled(-) drivers
    ================================
    + sed153x, pcd8544, sed156x, i2c, t6963, sed133x, nokcol, ks0108, lh155, ssdoled, l4m, goldelox, stv8105, acoolsdcm, directgfx, rs232, lc7981, ddusbt, framebuffer, remote
    - displaylink


    sollte er auch funktionieren ... du musst natuerlich --enable-experimental dafuer aktivieren (das ganze netzwerkzeug ist immer noch hochexperimentell und auch noch nicht fertig)


    Genauso ist es bei mit, aber bei "testserdisp -h" wird "REMOTE" nicht als Treiber angezeigt.


    Edit: OK, das war meine Blödheit ;) Es geht natürlich, ich hatte beim Test noch die alte Lib aktiv.
    Mir ist nur nicht ganz klar wie ich das nun aufrufe
    --
    ./testserdisp -n REMOTE -p net:15243
    Error: Unable to open net:15243, additional info: connection type 'net' is not supported
    --
    habe schon alles durchprobiert.


    Edit: Aha :)
    ----
    ./testserdisp -n REMOTE -p SRV:lcdname@localhost
    ----
    Läuft, schöne Sache. Also die Net Sache geht mit --enable-dynloading.


    cu

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden