[ANNOUNCE] graphlcd 0.1.6

  • Die Antwort von randy habe ich auf die Schnelle falsch verstanden und hatte auf die Schnelle auch nicht die Möglichkeit den Quellcode zu prüfen.


    Auch der "V1"-Patch von hier:
    http://www.vdrportal.de/board/…?postid=780666#post780666
    ist *nicht* integriert. Ich habe die Aussage von randy so verstanden, dass er den V1-Patch übernommen hat und die einige Zeit später gefolgte V2 nicht bemerkt hat. Aus diesem Zusammenhang hatte ich mich unberechtigterweise etwas geärgert, dass ein fehlerhafter Patch (scheinbar) unkontrolliert übernommen wurde. Wie gesagt: Mein Fehler.


    Der Patch aus obigem Link lässt sich ohne Probleme auch auf die 1.6 patchen. Kann also noch verwendet werden. Da der Patch eine gewisse Komplexität hat, wäre es nicht verkehrt den Patch vor dem Übernehmen genauer zu betrachten. Wo der Memory-Leak lag und wie er gefixt wurde, das habe ich verstanden. Nicht ganz klar komme ich mit dem doch etwas komplexen Algorithmus zum Zerlegen der UTF-8 Strings.


    randy : Warum verwendet ihr eigentlich kein GIT oder ähnliches? Hätte mir beim schnellen Prüfen des Codes doch sehr geholfen und ist auch für die Community nett, wenn man verfolgen kann, was wann gemacht wird.

  • Quote

    Originally posted by Mreimer
    randy : Warum verwendet ihr eigentlich kein GIT oder ähnliches? Hätte mir beim schnellen Prüfen des Codes doch sehr geholfen und ist auch für die Community nett, wenn man verfolgen kann, was wann gemacht wird.


    seit powerman einen neuen maintainer gesucht hat, liegt das project unter vdr-developer;
    git unter http://projects.vdr-developer.…tories/show/graphlcd-base bzw.
    http://projects.vdr-developer.…itories/show/plg-graphlcd


    readme/changelos und download hinweise unter http://projects.vdr-developer.org/wiki/graphlcd


    mach mir doch mal einen valgrind vom memleak. dann koennen wir mal weiterschauen.


    -- randy

  • woohaa
    <edit>
    in den git-repos habe ich es noch nicht gefunden, darum wohl auch das 'teaser' in deinem post.


    oops. man sollte das testbild genauer anschauen. dann wuerde man sehen, dass das noch 'mitten in der entwicklung' ist ;-)
    </edit>
    kannst du mir das mal schicken? haette ein paar farbdisplays (u.a. ein OLED, wo farbausgabe ja s**geil ausschauen sollte).
    und ideal zum testen sollte freilich die SDL-ausgabe sein.


    werde jetzt auch wieder etwas mehr tun (nach urlaub + neuem rechner).


    /wastl


    ergaenzung:
    habe mir btw einen displaylink-adapter zugelegt. den will ich als naechstes einbauen in meine lib (falls brauchbar in sachen performance).

  • laesst du eigentlich die XML-skins wie sie waren? (ausser natuerlich mit zusaetzlichem erweitertem 'color'-parameter)


    wie ist dann die farbe zu konfigurieren? color="rgb(rrggbb)" ? interessant waeren hier auch farbvariable.
    (a la:
    variable id="Colour1" value="rgb(471100)">


    <rectangle ... color="#Colour1">
    )



    oder so (grad gesehen, dass bei verwendung v. #471100 fuer einen farbwert die bedeutung des '#' zweideutig werden wuerde ...)


    /wastl

  • Wird das auch Framebuffer unterstützen? Fände ich ja eine super Alternative zum graphTFT. Das bringt meinen VDR nämlich bei einigen Aktionen zum Absturz. Wenn ich z.B. die Programminfo der aktuellen Sendung anschaue kackt der VDR ab. Rufe ich danach die EPG Info nochmal auf ist dann alles OK. Mach ich das am nächsten Tag stürzt VDR wieder ab usw. Ist also irgendwie en langzeit-Problem. Und der Grafikaufbau bei langen Menüs (Setup Menü von Skinelchi z.B.) ist auch grottig lahm. Früher hatte ich ein 128x64 SW LCD mit graphLCD. Das lief wesentlich geschmeidiger. Freue mich schon auf die erste Testversion!
    Mach es bitte bitte nicht so komlex wie graphTFT. Halt es einfach und schnell wie es jetzt ist.

  • komplex ist relativ. ich faende wie gesagt die xml-basierten skins, die powarman fuer 0.2.0 eingefuehrt hat (bzw. angefangen haette), genial. wenn einer xml nicht leiden kann dem moege das ganze vielleicht zu komplex erscheinen. ich finde es sehr flexibel und dennoch relativ einfach beherrschbar. ausserdem ist schon sehr viel vorarbeit geleistet. ein paar erweiterungen vielleicht noch, aber man kann bereits jetzt sehr viel damit machen.
    und framebuffer-support hat ja nix mit der erweiterung zu tun, die randy gerade vornimmt ...


    /wastl

  • Quote

    Original von wastl
    komplex ist relativ. ich faende wie gesagt die xml-basierten skins, die powarman fuer 0.2.0 eingefuehrt hat (bzw. angefangen haette), genial. wenn einer xml nicht leiden kann dem moege das ganze vielleicht zu komplex erscheinen. ich finde es sehr flexibel und dennoch relativ einfach beherrschbar. ausserdem ist schon sehr viel vorarbeit geleistet. ein paar erweiterungen vielleicht noch, aber man kann bereits jetzt sehr viel damit machen.
    und framebuffer-support hat ja nix mit der erweiterung zu tun, die randy gerade vornimmt ...


    /wastl


    Fullack. Ich hab auch mit xml kein Problem. Nur wenn ich mir z.B. anschaue, dass graphTFT für das Music Plugin eine Sonderlocke dreht nur, damit das Skining erhalten bleibt denke ich halt, dass da zu viel des Guten getan wird. Es entstehen Abhängigkeiten insbesondere von anderen Plugins und deren Versionen, die einen erheblichen Mehraufwand bei der Pflege des Systems bedeuten.
    Manch einer wird jetzt vielleicht sagen - hey, ist doch nix dabei. Du holst dir halt nicht den aktuellen Source von einem Plugin sondern von dreien und machst dann einmal make plugins und fertig.
    Das ist so einfach aber nur bei Leuten, die ihren VDR aus Sourcen zusammenbauen (was für mich zutrifft aber trotzdem...)
    Gerade die Einsteiger mit ihren binär bezogenen VDRs stehen dann plötzlich aussen vor, nur weil eben ein bestimmtes Plugin für ihre VDR-Distro nicht in der richtigen Version vorliegt.
    Und wenn dann noch bestimmte Patches dazu kommen wird es dann irgendwann auch für die Sourcenstricker komplex.

  • Hallo,


    ich hatte vor etwa einer Woche die Sourcen von graphlcd-base und vom vdr-graphlcd-Plugin aus dem Git geholt, um Gentoo Ebuilds dafür zu bauen, die ich dann auch an hd_brummy weiter leiten werde, geholt. Nun, ich stellte auch fest, was andere in diesem Thread gemeldet hatten, dass irgendwelche wichtige bis "nice-to-have" Patches noch fehlen, und seit ich diese Sourcen aus dem Git geholt habe, bis heute, wenn hat sich daran nichts geändert. Ich möchte keineswegs die Arbeit derer Ihr Euch angenommen habt schlecht reden, denn ich weiß sehr wohl wie das mit der Freizeit ist (geht mir auch so).
    Ich möchte nur mithelfen, da ich eh' in letzter Zeit einiges an Bestandsaufnahme existierender, noch benötigter Patches für 0.1.6 sowie auch Valgrind-Analyse und Verbesserungen am Treiber meines eigenen Displays gemacht habe. Bis zum Probieren von 0.2 seitens Waghalsiger zu denen auch ich gehöre dürfte noch ein bisschen Zeit vergehen, auf der neuen Projektseite finde ich noch keinen Hinweis auf die neuen 0.2-er Branches, von daher würde ich Euch dankbar sein, wenn Ihr die fehlenden Patches in einer baldigen 0.1.7-er Version übernehmen würdet, ich denke damit müssen wir noch einen Weile auskommen, und ein neues Release der "alten" Variante würde vielen Normalusern wie auch Packagern das Leben einfacher machen, und Euch auch Feedback auf eine konsistentere Basis liefern...
    Nun zu den Patches. Ich habe mal auf meinem Webspace nochmal alle hinterlegt und liste sie nochmal hier auf, auch wenn einige schon in diesem Thread oder verlinkt auf andere schon mal vorkommen:


    1. für graphlcd-base-0.1.6.20100408:


    2. für vdr-graphlcd-0.1.6.20100408:


    Auch wenn mit all diesen Patches nun alles nahezu perfekt läuft (im Vergleich zu den Abstürzen generell, und speziell den Timing-Problemen bei meinem Display), habe ich immer noch folgendes Problem: Immer wenn ein Sender mit EPG-Infos auf dem Display angezeigt wird, ist der Sendername schlecht gerendert, egal ob ein Logo dabei ist oder nicht, sobald ich auf einem ohne EPG-Daten schalte, erscheint der Name korrekt gerendert. Genauso wird Text aus "Popup"-Meldungen oder generell das Menue korrekt gerendert, ich habe da mal ein animiertes GIF angehängt, welches ich mittels des "image"-Displays von graphlcd, eingestellt auf 128x64 wie mein Noritake 800A erstellt habe. Weiß da jemand Rat oder Patch ;) ?


    Gruß,
    Lucian

    Images

    • graphlcd.gif


    8)


    Gentoo overlay mit VDR (und nicht nur) ebuilds, vdrcm, GLCDprocDriver

    The post was edited 5 times, last by Zoolook ().

  • Wenn ich mich nicht irre, dann kommt der SPAN-Patch direkt aus dem SPAN-Plugin. Dort findet sich sicher auch ein Hinweis auf den Original-Autor um ihn entsprechend im Changelog zu erwähnen.


    Die Bitte diesen Patch aufzunehmen kann ich nur unterstreichen. Ist wirklich nett, die kleine Visualiserung auf dem LCD ;)

  • Hi,
    wie wäre es Zoolook als Entwickler aufzunehmen?


    Die neue gepatchte Base fänd ich auch interessant, sollte ja auch mit 0.2 tun...


    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

  • na, hoert sich doch gut an; wenn mreiner und zoolook sich user auf projects.vdr-dev machen,
    kann ich sie als entwickler setzen (r/w git);


    wuerde dann vorschlagen, das ihr euch um die fehlenden patches kuemmert und eine 0.1.7
    "stable" zusammenstellt, und danach skinning support fuer die "neue" 0.2.0er anfangt;


    ich wuerde gerne den colormode weitermachen, bis das sauber geht, weiss nur noch nicht
    wie man das dann am besten merged ;)


    -- randy

  • Quote

    Originally posted by SurfaceCleanerZ:
    wie wäre es Zoolook als Entwickler aufzunehmen?

    Vorweg, wenn Ihr damit einverstanden seid ;)...
    Gruß,
    Lucian


    8)


    Gentoo overlay mit VDR (und nicht nur) ebuilds, vdrcm, GLCDprocDriver

  • ich glaube, du hast den leichten, in zynismus versteckten, unmut v. randy nicht mitbekommen.


    vor 0.1.6 wurden patches gesammelt. all die, die beim durchstoebern gefunden und an randy herangetragen worden sind, wurden von ihm integriert (bis auf den unrund-patch, weil der einer erweiterung (=konfiguration) bedarf und darum ist er wohl auch als issue mit status 'feedback' gefuehrt).


    zzt. nimmt er sich den colormode fuer die basis (interessant fuer plugin version 0.1.6 und 0.2.0) und plugin v 0.1.x vor, dann koennen die weiteren patches hineingezaubert werden. wenn jetzt da parallel entwickelt und herumgepatcht werden wuerde, wuerde es dann wohl irgendwann mal sehr spannend werden (hint: merging ...).


    darum: gemach gemach.


    /wastl


    ergaenzung:


    in deiner patch-liste sind btw. sehr interessante dinge zu finden. das mit radiotext und spectrumanalyzer muss ich ja glatt mal ausprobieren. von denen hoere/lese ich hier zum ersten mal ...