[ANNOUNCE] graphlcd 0.1.6

  • Hi,
    ist der Patch schon drin?
    [geloest] graphlcd und gu256x64-355 neues wiring .. wer kann das machen?


    Nur damits nicht vergessen wird irgendwann, wenn übernächstes Release, bin grad drüber gestolpert...


    Und zu Zoolook: Wer Fehler im Code finden und beheben kann sollte doch nützlich sein... War nur ein unverbindlicher Vorschlag und kein Drängeln!!!!


    randy: Hatte dir mal wikipedia Logos gemailt, sollen die nicht rein?


    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

    Einmal editiert, zuletzt von SurfaceCleanerZ ()

  • Zitat

    Originally posted by wastl
    ich glaube, du hast den leichten, in zynismus versteckten, unmut v. randy nicht mitbekommen.

    Hatte ich sogar nachdem ich gepostet hatte, erst gelesen, auch wenn sein Post mehrere Minuten vor meinem erschien und meiner so kurz ist, ich wurde zwischendurch abgelenkt und drückte "Post reply" erst später :)


    Zitat

    Originally posted by wastl
    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.

    Tja, kann ich verstehen, möglicherweise sind die Kollisionen umfangreich. Schade aber um jene Patches die auch umfangreicher sind und nicht bloß Feature-wünsche sind wie Radiotext, Span im plugin, sondern showstopper beseitigen (utf8_v2 in base) und der utf8-Patch im Plugin der nun wirklichj auch minimal ist.


    Kann man denn einen aktuellen Stand in einem unstable Zweig sehen, auf der neuen Projektseite? Nur so, damit man sich auch als (vielleicht noch) Aussenstehender ein Bild machen kann, über mögliche Kollisionen der noch ausstehenden Patches mit den derzeitigen Entwicklungen (Fasst randy gerade überall hin mit colormode?)? Ich meine gehört zu haben, Git sei mächtig gut in solchen Sachen, versshiedene Branches mal wieder zu mergen...


    Zitat

    Originally posted by 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 ...

    Verwende ich bisher noch nicht, werde mal gucken wie das mit dem Radiotext so ist, das andere erscheint mir noch als Schnickschnack...


    MfG,
    Lucian



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

  • Zitat

    Originally posted by Zoolook

    Hatte ich sogar nachdem ich gepostet hatte, erst gelesen, auch wenn sein Post mehrere Minuten vor meinem erschien und meiner so kurz ist, ich wurde zwischendurch abgelenkt und drückte "Post reply" erst später :)


    aehm, einmal wenn ich nicht zynisch bin... :)
    ich wollte als "erstes" ja eh alle patches sammeln, um so mehr, desto besser;
    wenn sich jetzt noch 2 leute mehr darum kuemmern koennen (auch stichwort quality
    management / reviews), sollte das ja locker machbar sein.


    Zitat


    Kann man denn einen aktuellen Stand in einem unstable Zweig sehen, auf der neuen Projektseite? Nur so, damit man sich auch als (vielleicht noch) Aussenstehender ein Bild machen kann, über mögliche Kollisionen der noch ausstehenden Patches mit den derzeitigen Entwicklungen (Fasst randy gerade überall hin mit colormode?)? Ich meine gehört zu haben, Git sei mächtig gut in solchen Sachen, versshiedene Branches mal wieder zu mergen...


    nein, habe keinen branch gemacht, kann aber gerne ein .tar.gz rummailen. ist halt
    "bloody edge" und ja, es ist alles angefasst worden; bis dato wurde ja das bild als
    bytes/char pro 8 pixel gemacht (siehe set8pixels), jetzt ist es uint32/4bytes pro pixel;
    daher will ichs auch noch nicht ins git reinschieben, das ist noch viel zu viel bastel.
    aber vereinfacht natuerlich auch die routinen, das ganze "if byte aligned..." ist rausgefallen,
    auch werden farbige logos dann gehen und ich dneke bereits ueber antialiasing nach...
    (siehe framebuffer und grosse 320er displays)


    Zitat

    Originally posted by 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 ...

    Verwende ich bisher noch nicht, werde mal gucken wie das mit dem Radiotext so ist, das andere erscheint mir noch als Schnickschnack...


    MfG,
    Lucian[/quote]


    span und rds sollten rein, das mit rds hatte ich als announce gelesen gehabt, aber
    vergessen aufs todo zu schreiben...


    PS: Mreiner ist schon im projects.vdr-dev geadded.



    -- randy

  • Zoolook


    weisst du zufaellig, wer den radiotext-lcd-service.diff erstellt/geschrieben hat?
    den verstehe ich nicht (will ihn mal testhalber in meine 0.2.x-version einbauen), aber ich versteh nicht ganz, wozu ueberhaupt der teil innerhalb von

    Code
    #if VDRVERSNUM < 10300


    angegriffen wird, da das ptitle da drin sowieso fuer den hugo ist?
    das ganze radiotext-zeug wird ja erst schlagend, wenn VDRVERSNUM >= 10300 ...


    oder uebersehe ich da etwas?


    /wastl



    korrektur: es ist nur das erste fuer den hugo. das zweite ist im #else-zweig ...

  • Zitat

    Originally posted by wastl
    Zoolook


    weisst du zufaellig, wer den radiotext-lcd-service.diff erstellt/geschrieben hat?


    Ist doch egal, oder ;)? Die Version scheint ohne LCR-Service (ich nehme an, Unterstützung für das Least Cost Router Plugin zum Abfragen vordefinierter Sparvorwahlen) zu sein. Die mit LCR-Unterstützung hat wohl hd_brummy mal für Gentoo irgendwo aufgetrieben, ihn sollten wir mal fragen.


    Gruß,
    Lucian


    P.S. Ich habe mich auch auf vdr-developer registriert, aber die eMail mit dem Aktivierungslink die verschickt wurde kommt und kommt nicht, kann das so lange dauern, oder liegt es an meiner email-Addresse (auf SourceForge und dann umgeleitet auf gmx)?



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

  • Vor ziemlich genau 6 Jahren, fragte ich powarman in einer eMail ob er das derzeitig noch monolitische graphlcd-plugin doch nicht in eine Bibliothek und das VDR-Plugin selber aufspalten würde, denn ich hatte schon damals vor den Treiber meines noritake 800A zu schreiben und auch die bibliothek die dann auch so entstand, in LCDproc verfügbar zu machen (glcdlib). Ich finde seine damalige Antwort interessant:


    Hat er denn einiges in Richtung Client/Server in den 0.2.er Sourcen angedeutet? Was haltet Ihr davon?


    Lucian



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

  • beim einbauen des radiotext-patches bin ich auf einen fehler in einer behauptung meinerseits gestossen:


    graphlcd-base-0.1.x reicht NICHT fuer graphlcd-0.2.x aus (da hat sich dummerweise noch eine alte .so versteckt gehabt auf meinem vdr, durch die das dann trotzdem gegangen ist).


    die gute nachricht aber: es reicht aus, das verzeichnis 'glcdskin' in den graphlcd-base-0.1.x-tree zu kopieren und im Makefile kompilieren und installieren zu lassen (es wird eine zusaetzliche .so erzeugt: libglcdskin).


    werde dann meine diesbez. postings suchen und korrigieren.


    update:
    radiotext funktioniert schon! (leider ohne scrolling, da das vom graphlcd-0.2.x noch nicht unterstuetzt wird, aber es funktioniert zumindest)


    /wastl


    DAMNIT: kann postings nur 14400 zeiteinheiten (sekunden oder minuten, mir nicht gemerkt) nach abschicken aendern :(

  • Meine Akt.Mail kam nach ner Minute...

    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

    Original von randy
    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);


    Ich halte mich bewusst erstmal zurück. Klar geht vieles einfacher, wenn viele mithelfen, aber meine C++-Kenntnisse sind nicht sehr umfangreich. Im Moment habe ich zudem sowohl im "Hardware-Bereich" als auch im "Software-Bereich" andere Projekte laufen, die im Moment meine komplette Freizeit abdecken.


    Für den Fall, dass ich später doch noch hinzustoße, melde ich mich nochmal. Ich hoffe aber, dass randy einen Blick auf die Codequalität behält und ggf. meckert. Eine der größten Bedenken, die ich jetzt durch den aufkommenden euphorismus sehe, ist nämlich, dass die Codequalität leidet. Gerade wenn ich mit meinem C++-Halbwissen unkontrolliert bastle wäre das nicht ausgeschlossen. Eigentlich ein guter Grund dafür, dass ich meine gewünschten Änderungen erstmal für den Anfang als Patch im Issue-Tracker auf projects.vdr-developer.org anhänge.


    Nachtrag: Wegen dem Wiring: Der Patch stellt das Wiring einfach komplett um, was so sicher nicht richtig ist. Jeder, der das Display nach dem alten Wiring aufgebaut hat, wird nach diesem Patch sein Display nicht mehr betreiben können. Richtig wäre eine Umschaltmöglichkeit, wie diese in anderen Treibern schon eingebaut ist.

  • randy
    wenns recht ist checke/pulle ich das skin-zeug in das graphcd-base repository.
    dann koennen wir das bestehende graphlcd-base-0.2.0-pre1 getrost vergessen, da dann alles zurueckportiert sein sollte (und diesesmal sollte ich hoffentlich nichts uebersehen haben ;)


    im untersten Makefile werde ich ein

    Code
    INCLUDE_SKINS=1


    einfuegen, das bei bedarf auf 0 gesetzt werden kann und dann das ganze ohne skins kompiliert wird.
    bis auf das Makefile gibt es keine ueberschneidungen zu bestehendem code, das 'glcdskins' ist unabhaengig und erstellt sein eigenes .so (libglcdskin, das, das ich uebersehen hatte). wenn jemand graphlcd-0.1.x verwendet, stoert ihn die existenz oder nichtexistenz von libglcdskin nicht.


    ich habe den code auch bereits auf gcc 4.3 level gebracht.


    /wastl


    zu den edits dieses postings: ich muss wirklich noch lernen, mit git umzugehen ...

  • Hi,
    cool! Klingt sehr interessant!


    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

  • so. skin-support ('glcdskin') ist im 0.1.x-repo v. graphlcd-base.


    habe das direkt aus dem 0.2.0-pre1 tar.gz uebernommen, inklusive aenderungen, damit es durch den gcc 4.3 geht.


    bitte jene, die graphlcd-plugin 0.2.x verwenden, testen.


    /wastl


    PS: spiele zzt. mit dem radiotext-patch herum (fuer 0.2.x), habe den ziemlich veraendert, damit oefter refreshed wird und das aber ressourcensparend (zzt. alle 5 secs, im falle einer aenderung in den RDS-daten).
    falls jemand daran interessiert ist, kann ich den patch hier posten (werde ihn erst einchecken, wenn es ein 'offizielles' graphlcd-plugin 0.2.x repo gibt).

  • ich habe mir heute das git
    git clone git://projects.vdr-developer.org/vdr-plugin-graphlcd.git
    heruntergeladen.
    In /etc/graphlcd.conf steht:


    vendor: 0x1509,
    product: 0x925d

    hiddev_devinfo in dm140gink.c gibt
    vendor: 1509
    product: ffff925d


    zurück. Ändert man in graphlcd.conf product zu 0xffff925d funktioniert der Aufruf von lcdtestpattern in tools/


    weiter bin ich noch niocht!

    VDR1: Gehäuse: Fractal Design mit ASROCK H97Pro 4 und yavdr-ansible (focal),

    VDR2: Gehäuse: Origin M10 mit ASROCK H81M-ITX und yavdr-ansible (bionic)

    sowie diverse VM unter Proxmox zum Testen.

  • jogek


    falsch: [das sieht eher nach einem bug deiner os-distribution aus?]


    idVendor und idProduct sind auf jew. 2 byte festgelegt.
    dh jew. 0x0000 - 0xFFFF



    korrektur: glaube den fehler gefunden zu haben:
    in dm140gink.h sind beide als int definiert. da gibts wohl beim einlesen ein problem int vs. u_int16 vs. short vs. vorzeichenbit.


    edit2:
    kannst du mal bitte folgendes versuchen im dm140gink.c:
    in zeile ca. 160 folgende zeile

    Code
    if(vendor==device_info.vendor && product==device_info.product)


    auf

    Code
    if((short)vendor==(short)(device_info.vendor) && (short)product==(short)(device_info.product))


    aendern und dann mit den urspruenglichen product/vendorIDs testen.



    /wastl

  • Zitat

    Originally posted by DaRookie
    wer ist denn fürs Einbetten der Logos zuständig?
    Ich hätte da ein paar Logos in Größe *_l.glcd anzubieten...


    hallo,


    bitte einfach als "issue" im developer anlegen;


    http://projects.vdr-developer.…jects/graphlcd/issues/new
    da kann man auch files hochladen.


    danke,
    -- randy

  • wastl


    kann leider erst heute abend testen, aber:


    in hiddev_devinfo sind vendor und product als s16 (signed short) definiert. Warum aber werden beide unterschiedlich


    vendor: 1509
    product: ffff925d


    zurückgegeben?

    VDR1: Gehäuse: Fractal Design mit ASROCK H97Pro 4 und yavdr-ansible (focal),

    VDR2: Gehäuse: Origin M10 mit ASROCK H81M-ITX und yavdr-ansible (bionic)

    sowie diverse VM unter Proxmox zum Testen.

  • muesste man sich genauer anschauen.


    der test mit den 'alles auf short casten' ist ja eigentlich auch inkorrekt (richtig waere 'uint16_t' wenn ich mich richtig erinnere). aber es waere damit mal alles auf dersselben basis und - wenn damit die korrekte vendor/productID-darstellung funktioniert - meine vermutung bestaetigt, dass genau dieses eine if fuer den bedarf deines workarounds verantwortlich ist.


    /wastl

  • Zitat

    Original von jogek
    in hiddev_devinfo sind vendor und product als s16 (signed short) definiert. Warum aber werden beide unterschiedlich


    vendor: 1509
    product: ffff925d


    zurückgegeben?


    weil 0x925d auf short gesehen eine negative Zahl ist, bei der beim cast auf int das Vorzeichen erweitert wird.


    0x1509 ist dagegen positiv.


    Grüße
    Andreas

Jetzt mitmachen!

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