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

    Guckst du hier.


    Edit: sorry - das ist ja für yaVDR - aber vielleicht hilfts dir trotzdem...


    Gruß
    superelchi

    #1: yaVDR 0.5 - Asus A5IONT-I, 4 GB Ram - 750 GB 2,5" HD - DD Cine S2 V6 - Silverstone Sugo SG06 - Pearl DPF - Hama MCE Remote
    #2: yaVDR 0.5 - Intel DH67BL, 4 GB Ram - Asus GT610 - 40 GB SSD - 500 GB 2,5" HD - DD Cine S2 V5.5 - Silverstone Milo ML03 - Pearl DPF - Hama MCE Remote

    Hi,
    du meinst für easyvdr 0.9 oder 0.95?


    Wäre ich auch dran interessiert, aber derzeit gibts wichtigere Baustellen!


    mfG,
    Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente
    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte     GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:     Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

    Hallo,


    wie ist das mit Gen2VDR V3? Gibt es dazu schon eine Anleitung? Hat doch sicher schon jemand probiert... Bei mir scheitert es schon am emergen von graphlcd-base. Das holt sich das git, aber nicht den touchcol Zweig...

    news:


    • habe wieder mal ein wenig was fuer meine library (serdisplib) gemacht: der trunk fasst jetzt v1.98.x + v1.97.x zusammen zum neuen zweig v2.x.
      trunk firmiert dzt. noch unter 'pre 2.00', wird aber bald eine fertige 2er release hervorbringen (in sachen dokumentation faellt noch einiges)
    • weder v.1.97.x noch v.1.98.x werden weitergefuehrt. die (inoffiziellen) spielereien aus v.1.98.x leben aber weiter und muessen via ./configure mit --enable-experimental aktiviert werden (client/server-zeug, lirc-kompatible events fuer c't-includ, ...). alles andere (displaylink, GPIs, GPOs) ist jetzt 'offiziell' teil der library.
    • neuerung: serdisp_defaultdevice(): durch verwendung dieser routine wird in den meisten faellen die angabe der device-angabe ueberfluessig (zb: OUT:, die meisten USB:.... angaben, ...). achtung: nur in v2.x (trunk) vorhanden!
    • der aktuellste GIT-commit von graphlcd-base verwendet bereits -falls vorhanden - serdisp_defaultdevice(). dh. der eintrag 'Controller=' ist in verbindung mit [serdisp] nur mehr in wenigen faellen notwendig

    Hi,

    Zitat

    nur mehr in wenigen faellen notwendig

    bei parallelen? Oder geht dort jetzt Autoerkennung?


    mfG,
    Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente
    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte     GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:     Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

    nochmal: autoerkennung wirds bei parallel NIE spielen!


    das mit serdisp_defaultdevice() hat auch genau nix mit autoerkennung zu tun.


    wenn jetzt kein Controller= angegben ist, wird, falls fuer das display kein extra defaultdevice definiert ist im code, einfach weiterhin 'PAR:/dev/parport0' genommen. aber das war auch vorher schon so ...

    Hi,
    aber das Problem, dass, wenn ein falsches glcd angewählt ist der VDR nicht durchstartet ist immer noch (wartet aufs glcd)?


    mfG,
    Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente
    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte     GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:     Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

    Zitat von SurfaceCleanerZ

    Hi,
    du meinst für easyvdr 0.9 oder 0.95?


    Hi
    ich meine die akutelle Stable Version "Installierte Version: 0.8.06"



    Gruß Lars

    VDR-Client: Passivgehäuse Hush mini-ITX, Technotrend TT-Premium S-2300 DVB-S
    VDR-Server: Netgear Stora mit Debian 2.6.32-6-kirkwood Kernel, S2-lilianin, Technotrend S2-3600 DVB-S, 2x500GB mit Raid1

    Hi,


    wollte es gerade auf meinem easyVDR 09.50 maken - leider mit Fehler.


    Hat wer einen Tip:


    Code
    In file included from l4m320t_tool.c:81:0:
../include/serdisplib/serdisp_connect_usb.h:35:17: schwerwiegender Fehler: usb.h: Datei oder Verzeichnis nicht gefunden
Kompilierung beendet.
make[1]: *** [l4m320t_tool.o] Fehler 1
make[1]: Verlasse Verzeichnis '/usr/src/serdisplib-1.98.x_svn/tools'
make: *** [all] Fehler 1

    #S1: Gigabyte GA-H77M-D3H, Intel 1610 Celeron, 4GB RAM, Cine S2 6.5 + Duoflex S4, NVIDIA GT 630, IBM SSD 240GB, Atric IR Einschalter, DVD-Brenner mit easyvdr 3 oder MLD5
    #S2 (offline) POV MB-D510-MATX, 2GB, GT 220, TT 1600
    #C1: RPi3 MLD5.1

    scheinbar hilft ein einfaches apt-get install libusb-dev :)


    leider bekomm ich auch nach installation von ImageMagick beim make von graphlcd-base.git.touchcol folgendes:


    #S1: Gigabyte GA-H77M-D3H, Intel 1610 Celeron, 4GB RAM, Cine S2 6.5 + Duoflex S4, NVIDIA GT 630, IBM SSD 240GB, Atric IR Einschalter, DVD-Brenner mit easyvdr 3 oder MLD5
    #S2 (offline) POV MB-D510-MATX, 2GB, GT 220, TT 1600
    #C1: RPi3 MLD5.1

    Einmal editiert, zuletzt von masterpete ()

    Fehlt wohl ein apt-get install pkg-config



    nun gehts weiter.

    #S1: Gigabyte GA-H77M-D3H, Intel 1610 Celeron, 4GB RAM, Cine S2 6.5 + Duoflex S4, NVIDIA GT 630, IBM SSD 240GB, Atric IR Einschalter, DVD-Brenner mit easyvdr 3 oder MLD5
    #S2 (offline) POV MB-D510-MATX, 2GB, GT 220, TT 1600
    #C1: RPi3 MLD5.1

    Keine Idee, aber denselben Fehler mit einer ganz anderen Konfiguration:


    ich habe ein DM140-GINK-Display. Sowohl mit dem dm140vfd-Plugin als auch mit LCDd bekomme ich in unregelmäßigen Abständen den Oops. Es scheint also tatsächlich ein Kernelproblem zu sein (hier auch yavdr 0.4 mit 2.6.38-13):



    Gibt's dazu schon Neuigkeiten?


    Sebi

    Hi,


    das graphlcd-plugin zeigt beim epgsearch-plugin nach der Uhrzeit immer eine riesige leere Spalte an bis dann der Text kommt. Könnte sich das jemand bei Gelegenheit mal anschauen?


    Gruß

    Zitat von monchi80

    das graphlcd-plugin zeigt beim epgsearch-plugin nach der Uhrzeit immer eine riesige leere Spalte an bis dann der Text kommt. Könnte sich das jemand bei Gelegenheit mal anschauen?


    Das liegt daran das die erste Spalte durch die vielen "-" so breit ist.


    cu

    long time no see ...


    aber jetzt gehts wieder weiter:


    news (graphlcd-base):

    • verbessertes logging (wo wird syslog-ausgabe generiert, syslog-flooding sollte jetzt behoben sein)
    • zusaetzliches feature fuer progress bar: gradient

    das gradient-feature kennt zwei optionen: gradient="total|current|vertical" und gradientcolor="<farbe>"

    • gradientcolor: die farbabstufungen werden zwischen color und gradientcolor berechnet
    • total: die farbabstufungen werden ueber die maximale groesse des progress bars berechnet
    • current: die farbabstufungen werden nur ueber den tatsaechlich angezeigten progress bar berechnet
    • vertical: die farbabstufungen werden ueber die dicke des progress bars berechnet

    beispiele (geordnet nach screenshots):

    • <progress ... color="0xDDC0FFC0" gradientcolor="0xFF2222FF" gradient="total" direction="0" current="{PresentProgress}" total="{PresentDuration}"/>
    • <progress ... color="0xDDC0FFC0" gradientcolor="0xFF2222FF"
      gradient="current" direction="0" current="{PresentProgress}"
      total="{PresentDuration}"/>
    • <progress ... color="0xDDC0FFC0" gradientcolor="0xFF2222FF"
      gradient="vertical" direction="0" current="{PresentProgress}"
      total="{PresentDuration}"/>

    zu beachten:

    • gradient 'overruled' peak (dh. sobald gradient verwendet wird, ist keine peak-anzeige mehr moeglich).
    • es muss sowohl die option gradient als auch gradientcolor definiert sein damit die gradient-funktion aktiviert wird.

    achtung: eventuell muss auch das vdr-graphlcd plugin neu kompiliert werden (kleine API-erweiterung, die zwar nicht zum plugin durchschlagen sollte, aber man weiss ja nie bei c++)

    Ich würde es begrüßen, wenn bei einer Übernahme in yavdr auch glcdprocdriver mit der Korrektur von Keine_Ahnung (glcdprocdriver-0.0.6-touchcol.diff) ausgeliefert würde. Damit würde dann auch beim Bauen von lcdproc der glcdlib-Teil mitgebaut werden.
    Nur auf diesem Weg habe ich es geschafft, xbmc auf meinem Display (t6963c basiert) eine anständig große Ausgabe beizubringen.

    vdr-2.6.7

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Ich glaube das wäre eher was für den yaVDR Bugtracker


    wastl: Was mich neulich mal beschäftig hat ist das dynamische laden der libserdisp.so, das ist ja unter Debian/Ubuntu ne Dauerbaustelle. Keine Ahnung wie die anderen Distributionen das handhaben.
    Unter Debian/Ubuntu gibts die libserdisp.so nur wenn das libserdisp2-dev Paket installiert ist. Die Idee ist das man verschiedene Libversionen gleichzeitig installiert haben kann. Aber nur das Dev Paket einer Version, das erzeugt dann nen Link zur passenden Libversion "libserdisp.so -> libserdisp.so.2.00".


    Sollte man den so Namen nicht per pkg-config abfragen so das direkt versucht wird die "libserdisp.so.2" zu laden?


    Oder ist das nen reines Debian/Ubuntu Problem und die anderen Distributionen machen das alles ganz anderst?


    cu

    eigentlich ist pkg-config eine reine devel-geschichte und gehoert nicht in den 'normalen' paketbereich. dessen ausgaben werden ja auch normalerweise nur beim entwickeln benoetigt. im devel-paket sind ueblicherweise jene dinge, die fuer die entwicklung benoetigt werden (docs, header, statische lib (.a), .pc-file fuer pkg-config, ...).


    wer immer auf die idee gekommen ist, bei 'normalen' bibliothekspaketen _keinen_ .so-link zu generieren, ich bin es jedenfalls so gewohnt (verwende jetzt schon sehr lange unix (nicht nur linux)), dass der standardweg es sein sollte, eine bibliothek via -lsomename zu linken (was sich ja dann zu libsomename.so (oder unter windows somename.dll) ausloest). und keine direkten -l/path/to/libsomename.so.47.11. das ist imho sowieso eine ziemliche unart.


    ich kenne debian/ubuntu eher nur aus der benutzersicht (wenn es sich nicht vermeiden laesst), ich kann mir aber nicht vorstellen, dass das generell dort so ist, dass standardmaessig keine .so-link generiert werden. ev. beim maintainer der serdisplib pakete fuer debian/ubuntu nachfragen, weshalb er das so macht?


    /wastl

    Hi,


    Zitat von monchi80

    Hi,


    das graphlcd-plugin zeigt beim epgsearch-plugin nach der Uhrzeit immer eine riesige leere Spalte an bis dann der Text kommt. Könnte sich das jemand bei Gelegenheit mal anschauen?


    Gruß


    im git von epgsearch sind die Patches von KeineAhnung nun übernommen. Damit kann nun mit einem


    PLUGIN_EPGSEARCH_SEPP_ITEMS=---


    z.B. in der Make.config vom VDR gesetzt werden, wieviele "-" ausgegeben werden sollen, damit die Anzeige bei graphlcd nicht leidet.
    Die meisten Skins (ausser den VDR-eigenen) ersetzen "---" durch eine durchgezogene Linie, sodass das normale OSD dadurch nicht beeinflusst wird.


    Gruß,
    winni

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden