Posts by wastl

    bei mir kompiliert es jetzt gar nicht mehr, weil die haelfte der (env.)variablen / nicht mehr gesetzt werden ...
    (VDRDIR ist nicht gesetzt und wird auch im Makefile, wenn es nicht als env.var. von aussen hereinkommt, dann nicht gesetzt -> alles weitere geht dann so ziemlich in die hose, weil es dann freilich auch kein PKGCFG usw gibt)


    wie legst du 'alle noch supporteten VDR-Versionen' fest?


    ich habe auch kein problem damit, dass das plugin mit vdr version 1.4.x zurecht kommt (ich habe keine angst vor ein paar ifdef-kaskaden :)
    teste das auch ab und zu mit einer alten 1.4.x installation.


    daher nein, i18n.[ch] fliegen nicht heraus.


    die div. flags statt mit = mit ?= festzulegen ist allerdings eine gute idee.


    /wastl

    ui. das sieht nicht gut aus.
    bei offset und scale sollten andere werte stehen, auch die serial number sollte laenger sein ...
    und die firmware-version ist eine 3-4-stellige zahl mit fuehrenden nullen ...


    funktioniert das display mit testserdisp? (ie: zeigt es das kreuz mit den zahlen 320 und 240)?

    ee23?


    von dem hoer ich zum ersten mal ... produziert digital devices ueberhaupt noch solche displays oder ist das ein altes modell, von dem ich gar nix weiss? vor einiger zeit hat mich digital devices ja angeschrieben, dass sie das mit den displays sein lassen.


    du kannst folgendes probieren (ohne gewaehr):


    in src/serdisplib_connect_usb.c:


    beim abschnitt


    Code
    1. #ifdef SDCONN_ENABLE_CYPRESS_MPFRAMES
    2. ,{0x4243, 0xee20, -1, SDHWT_USBL4M320T, 16384, 0x00, 16 }
    3. ,{0x4243, 0xee21, -1, SDHWT_USBL4M320T, 16384, 0x00, 16 }
    4. ,{0x23ae, 0xee21, -1, SDHWT_USBL4M320T, 16384, 0x00, 16 }
    5. #else
    6. ,{0x4243, 0xee20, -1, SDHWT_USBL4M320T, 64, 0x00, 16 }
    7. ,{0x4243, 0xee21, -1, SDHWT_USBL4M320T, 64, 0x00, 16 }
    8. ,{0x23ae, 0xee21, -1, SDHWT_USBL4M320T, 64, 0x00, 16 }
    9. #endif /* SDCONN_ENABLE_CYPRESS_MPFRAMES */


    die zeilen

    Code
    1. ,{0x23ae, 0xee23, -1, SDHWT_USBL4M320T, 16384, 0x00, 16 }


    und

    Code
    1. ,{0x23ae, 0xee23, -1, SDHWT_USBL4M320T, 64, 0x00, 16 }


    jew. einzufuegen.


    /wastl

    olebowle


    was mir eben noch eingefallen ist als test / eingrenzung:


    mach folgende 2 tests:


    einmal irgendein 320x240 bild via showpic anzeigen:
    zb: showpic -c /etc/graphlcd.conf -d ax206dpf somepic_320x240.jpg


    (voraussetzung: graphlcd ist mit imagemagick / graphicsmagick support kompiliert, ansonsten irgendein groesseres single frame glcd nehmen)


    2. test:
    ein animiertes bild anzeigen lassen, zb. eine start/stop-animation (zb vdr-starting_240x128.glcd (da gibts glaub ich keine groesseren, aber es sollte auch so eines ausreichen. EDIT: es soll sogar kleiner sein als 320x240, damit immer nur ein teil der ganzen flaeche neu gezeichnet wird - ich vermute genau da das problem im treiber).


    wenn die animation fehlerfrei angezeigt wird, dann wuerde graphlcd-base passen und ein fehler im vdr-plugin-graphlcd sein.
    ansonsten muss ich wie gesagt auf superelchi verweisen.

    olebowle
    ich kanns nicht nachvollziehen. habe aber auch eine aeltere firmware auf meinen ax206dpf-displays.


    schon mal bei superelchi nachgefragt ob er eine idee dazu hat (der hat den graphlcd-treiber fuer das ax206dpf geschrieben. vielleicht hat er im protokoll etwas geaendert so dass es jetzt probleme gibt oder irgendsoetwas in der art)


    verwendest du ein brauchbares mini-usb kabel (dh. nicht das mitgelieferte - bei den pearl-displays zumindest waren die zieml. minderwertig)

    dad401 :
    fehler ist gefixt, display dimmt jetzt auch bei der wiedergabe.


    olebowle :
    bin ich etwas ueberfragt. schaut lustig aus die ausgabe.
    kannst du sowohl von skin touchcol als auch default ein foto anhaengen?


    oder, falls serdisplib bei dir mit SDL-unterstuetzung gebaut worden ist und auch nur, wenn du eine X11-oberflaeche zur verfuegung hast, folgendes in graphlcd.conf dazuhaengen:


    Code
    1. [serdisp_sdl]
    2. Driver=serdisp
    3. Device=out:
    4. Controller=sdl
    5. Options=depth=24;width=320;height=240


    dann vdr-plugin-graphlcd starten mit


    Code
    1. -P "graphlcd -c /etc/graphlcd.conf -d serdisp_sdl -s touchcol"


    bzw.


    Code
    1. -P "graphlcd -c /etc/graphlcd.conf -d serdisp_sdl -s default"


    (SDL macht ein fenster auf der X11-oberflaeche auf! - ein SDL-Fenster kann auch schoen mit jedem beliebigen screenshot-programm 'abfotografiert' werden)


    wenn jemand einen android-daemon schreibt, welcher den ganzen bildschirm des android tablets nutzen und auch die touch-daten entgegen nehmen kann und zb. ueber das usb debug feature (oder wifi) dann ein bidirektionales protokoll realisiert, welches von einem eigenen treiber in graphlcd, serdisplib, ... angesprochen werden kann, dann sehe ich da kein problem.


    schreiben muesste das dann noch jemand (auf android-seite waere das zb. soetwas wie MyMobiler, nur die andere richtung :)
    vielleicht gibt es sowas schon fuer android (habe aber nix gefunden).
    der einbau dann auf serdisplib/graphlcd-seite sollte dann nicht so das grosse problem mehr sein ...

    kein unterschied zu: es kompiliert wegen (Quantum) nicht
    oder
    kein unterschied zu: size_t qrange = pow(2.0, (*it).depth()) ....


    weil das mit (*it).depth() verursachte sehr wohl probleme (falschfarben bei manchen bildern / symbolen).
    dh. wenn du keine problematischen bilder/symbole verwendest, wirst du zwischen der aktuellen und der qrange-loesung keinen unterschied merken.

    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 ...

    monchi80 + @C-3P0:


    koennt ihr bitte folgendes ausprobieren:


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


    ersetzen durch


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


    und


    Code
    1. 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
    1. bmpdata[iy*width+ix] = (uint32_t)(
    2. (int(255 - (Magick::Color::scaleQuantumToDouble(pix->opacity) * 255)) << 24) |
    3. (int( Magick::Color::scaleQuantumToDouble(pix->red) * 255) << 16) |
    4. (int( Magick::Color::scaleQuantumToDouble(pix->green) * 255) << 8) |
    5. int( Magick::Color::scaleQuantumToDouble(pix->blue) * 255)

    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
    1. size_t qrange = (size_t)pow(2.0, (*it).depth()) - 1;


    auf


    Code
    1. 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.

    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 ...

    gefixt.


    ImageMagick hat in einer aktuellen Version MaxRGB hinausgeworfen (deprecated, stattdessen soll QuantumRange verwendet werden), GraphicsMagick hat aber QuantumRange (noch) gar nicht definiert.
    Habe MaxRGB ersetzt durch QuantumRange, #ifdef hinzugefuegt fuer GraphicsMagick

    es hat zwar bis jetzt noch kein skin skinspezifische icons (zumindest mir unbekannt), aber das steht ja nicht im widerspruch zu meinen plaenen.
    ich moechte ja mehrere verzeichnisse zulassen, die dann der reihe nach durchsucht werden (mit standard skin-imagepfad als internem default an erster stelle).
    dem plugin koennen dann als parameter pfade angegeben werden, ein neuer tag {ImagePath} liefert davon den ersten pfad zurueck (falls jmd einen absoluten pfad benoetigt), aber das ziel geht eigentlich in eine (noch zu schreibende und zu benennende) funktion, die automatisch das am besten geeignete bild holt.
    a la:


    SuperMagicFunction('channels', {ChannelAlias})


    oder


    SuperMagicFunction('replay', 'stop')


    interessant wird in verbindung damit halt dann, wie die einzelnen verzeichnisse strukturiert werden. da es ausser Keine_Ahnung eh keinen zu interessieren scheint, werde ich das nach meinem gutduenken aufbauen (habe aber bereits eine idee, das dennoch so flexibel wie moeglich zu gestalten).


    das mit den channellogos/bezeichnungen ist hiefuer komplett unerheblich. das ist dann eher eine frage, wie {ChannelAlias} das aufloest ...


    bei der superduper funktion liegen zwar noch ein paar steine im weg (zumindest rede ich mir das ein), aber mal sehen ...

    es wurde irgendwann vor 100 jahren schon mal diskutiert, aber es hat sich dann doch im sand verlaufen.


    ein einheitliches ablageschema fuer von skins benoetigte bilder / symbole / icons / ...


    wenn es soetwas bereits geben sollte: hier bitte aufzeigen.


    wenn nicht, mein vorschlag:


    Code
    1. 'images' / <category> / <resolution in XxY > / <depth in XXbpp> / <type: 'still', 'animated'> / <filename>


    als beispiel graphlcd (auszug):

    Code
    1. 'images' | 'channels' | '40x29' | '01bpp' | 'still' | 'bla.png'
    2. | 'replay' | '64x48' | '04bpp' | 'animated' | 'bla.gif'
    3. | 'icons' | | '32bpp' | | 'bla.glcd'
    4. | 'background' | | 'bla.jpg'
    5. | 'startstop' |


    beispiele:
    images/startstop/320x240/01bpp/animated/start.glcd
    images/channels/64x48/32bpp/still/CORNYTV.png
    images/icons/40x29/01bpp/still/play.pnm


    RFC / request for comments


    anmerkung: ich hasse diesen forumseditor ...

    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.