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

    wastl
    ich habe femon geladen da es je im menu sichtbar ist und auch werte anzeigt. version 1.7.17 .. muss ja die nehmen da vdr 1.7.28 ;o)
    da der vdr auch abstürzt wenn ich femon per svdrp abfrage scheint es ein femon bug zu sein.
    vg mentox



    EDIT: so version 7 ist da .. Anpassungen von Copper übernommen. Sollte jetzt auch auf anderen Display hüpsch sein. Signalstärke verkleinert um den WAF zuerhöhen :D


    [Blockierte Grafik: http://img.tapatalk.com/59b61eba-1210-1af6.jpg]

    mentox:


    die gleichen versionen wie bei mir:

    Code
    echo "plug " |nc localhost 6419|grep femon
214-femon v1.7.17 - DVB Signal Information Monitor (OSD)


echo "plug femon qual" |nc localhost 6419
220 butthead.localdomain SVDRP VideoDiskRecorder 1.7.28; Sun Jul 15 20:50:51 2012; UTF-8
900 81 on device #0


    als attachment 2 bilder, das erste mit nicht aktiviertem femon plugin (da zieht dann <block condition="not({ServiceIsAvailable:femon})">text mit schriftzug 'no femon'</block>), das zweite mit aktiviertem femon (da zieht dann <block condition="{ServiceIsAvailable:femon}">der ganze femon anzeigekrempel</block>).

    so version 8
    bis auf das menu ist jetzt alles dynamisch ..


    grüße mentox


    PS kann man die posts zu meinem skin evtl auslagern? solangsam tuts mir leid den thread zu zu missbrauchen

    Zitat von mentox

    kann man die posts zu meinem skin evtl auslagern? solangsam tuts mir leid den thread zu zu missbrauchen


    wäre vielleicht keine verkehrte Idee, die Skins mit Bildern in der Art wie hier abzulegen. Auch der Ort würde sich ja anbieten.


    Gruß Fr@nk

    ich waere zzt gar nicht so traurig, wenn die skins derzeit noch hier gepostet werden, da ich noch ein/zwei sachen einbauen moechte - inkl. bessere struktur fuer images/icons/.. + flexiblerer zugriff darauf. die allgemeinen symbols fliegen auf jeden fall noch aus dem skin hinaus. da sollen wirklich nur noch skin-spezifische symbols/icons/.. dann enthalten sein. wenn das gegeben ist, koennen die skins dann ruhigen gewissens auf so einer seite gesammelt werden.

    Zitat von mentox

    dann aber nicht unter text2skin sondern eine rubrik für graphlcd .. oder?


    sicher,


    zu prüfen wäre auch, ob dort noch was geht, sieht dort ja irgendwie tot aus. Man könnte bsw. mal Izeman dazu befragen (Izegrey skin) .
    Skin.vdr-developer.org scheint eine andere Domain zu sein, wäre aber der passende Ort dafür. Du kannst ja schon mal vorarbeiten ;)


    Gruß Fr@nk

    Leider lässt sich graphlcd bei mir nicht mehr bauen:


    Zitat von wastl

    gefixt. ....


    Geht leider immer noch nicht. :(


    so. MaxRGB bzw. QuantumRange werden jetzt beide vermieden. rechne den betreffenden wert jetzt on-the-fly aus (mit einer hoffentlich unproblematischen, ueber alle moeglichen versionen v. Graphics/ImageMagick verwendbaren methode (image.depth()) selbst aus)


    konnte aber nicht mit der allerneuesten version v. ImageMagick (6.7.9) testen, da ich nur 6.7.0 installiert habe. aber habe in den sourcen v. 6.7.9 nachgesehen, und da ist depth bzw. image.depth() immer noch als size_t definiert ...

    Hi,


    mit älteren Versionen scheint es aber nicht zu laufen. Ich verwende MLD und das nutzt in der stable die Oneiric-Sourcen. Da ist ImageMagick noch in der Version 6.6.0 drin. Bauen tut es, aber im Betrieb werden merkwürdige Farben ausgegeben.


    Gruß

    yavdr-ansible - Asus A55BM-A/USB3 - A4-6300 - Samsung 830 SSD 64 MB - WD AV-GP 3TB - MSI GTX 1050 Ti - DD Cine S2 6.5 - LG CH12NS30 - OrigenAE S14V

    war das vorher auch schon so oder ist das erst seit der aktuellen aenderung so?


    dh: wenn du in glcdgraphics/extformats.c in zeile ca. 134 folgendes aenderst:


    Code
    size_t qrange = (size_t)pow(2.0, (*it).depth()) - 1;


    auf


    Code
    size_t qrange = MaxRGB;

    (in 6.6.0 sollte das mit MaxRGB / Quantum noch kein problem darstellen)


    dann spiegelt das den alten stand wider.


    wenn es auch dann falschfarben gibt, war das problem schon vorher existent. dann bitte beispielbild/icon + screenshot.


    damnit. konnte es eben nachvollziehen.


    ImageMagick macht mich zzt. ein wenig fertig. das mit dem fehlen v. Quantum ist ein bug in den includes v. Magick++ (cast in der API v. Magick++ auf (Quantum), ohne dass das zugehoerige include mit inkludiert wird). will aber vermeiden, den umschiffen zu muessen durch eigene includes (es gibt dann doch ein paar dinge, worin sich GraphicsMagick und ImageMagick unterscheiden - eben auch bei den includes)


    dh. da werde ich wohl ein wenig herumspielen muessen.


    vielleicht weiss auch jemand eine saubere methode bei ImageMagick/GraphicsMagick, ein beliebiges PixelPacket in RGBA8888 umwandeln zu lassen ohne den umweg ueber QuantumRange/MaxRGB.

    monchi80 + @C-3P0:


    koennt ihr bitte folgendes ausprobieren:


    Code
    if ( isMatte && pix->opacity == qrange ) {


    ersetzen durch


    Code
    if ( isMatte && Magick::Color::scaleQuantumToDouble(pix->opacity) * 255 == 255 ) {


    und


    Code
    bmpdata[iy*width+ix] = (uint32_t)( (int(255 - (pix->opacity * 255 / qrange)) << 24)  | (int(pix->red * 255 / qrange) << 16) | (int(pix->green * 255 / qrange) << 8) | int(pix->blue * 255 / qrange));


    ersetzen durch


    Code
    bmpdata[iy*width+ix] = (uint32_t)(
                                    	(int(255 - (Magick::Color::scaleQuantumToDouble(pix->opacity) * 255)) << 24)  |
                                    	(int( Magick::Color::scaleQuantumToDouble(pix->red) * 255) << 16) |
                                    	(int( Magick::Color::scaleQuantumToDouble(pix->green) * 255) << 8) |
                                     	int( Magick::Color::scaleQuantumToDouble(pix->blue) * 255)
    Zitat von wastl

    [...] ImageMagick macht mich zzt. ein wenig fertig. das mit dem fehlen v. Quantum ist ein bug in den includes v. Magick++ (cast in der API v. Magick++ auf (Quantum), ohne dass das zugehoerige include mit inkludiert wird). will aber vermeiden, den umschiffen zu muessen durch eigene includes (es gibt dann doch ein paar dinge, worin sich GraphicsMagick und ImageMagick unterscheiden - eben auch bei den includes)


    dh. da werde ich wohl ein wenig herumspielen muessen.


    vielleicht weiss auch jemand eine saubere methode bei ImageMagick/GraphicsMagick, ein beliebiges PixelPacket in RGBA8888 umwandeln zu lassen ohne den umweg ueber QuantumRange/MaxRGB.


    Ich bin mir jetzt nicht sicher, ob das das ist, was Du meinst, aber bei Gentoo kann man das via Useflags festlegen:


    ich will keine define-kaskaden hiefuer und scho gar keine USEFLAGS oder irgendsoeinen muell, sondern eine moeglichst allgemeine loesung.


    lt. api-doku sollte das obige (scaleQuantumToDouble()) passen und es waere auch die allgemeine loesung unabhaengig v. div. defines / 32vs.64bit / Graphics- vs. ImageMagick ....
    darum bitte testen!


    ausser es scheitert wieder am (Quantum)-Problem mit dem fehlenden include ...

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden