Beiträge von wastl

    So I have cleaned up and I noticed also that when installing all the libs get copied to /usr/local/lib whilst the plugin was looking at /usr/lib. It was necessary to move them to /usr/lib otherwise the plugin could not find the libs. This is also the reason why it was not loading ....


    /usr/local/lib is standard unix destination for non-system (non-packaged) libraries. but most ready-made distributions don't include /usr/local/lib in their ldconfig configuration. so either you set LD_LIBRARY_PATH to /usr/local/lib, or you include /usr/local/lib in /etc/ld.so.conf.d/, or (recommended) you set DESTDIR either in Make.config or via an environment variable to /usr when compiling and installing the libraries.



    debugging the library:


    gdb some_library.so will give absolutely _no_ information (because you can't execute a library).


    you'll have to debug the whole vdr process when running:


    gdb --args vdr <all the parameters and options and plugin stuff>
    eg:


    gdb --args vdr -P 'graphlcd -d usb_reelfp'



    EDIT:
    DESTDIR should be set to /usr, not /usr/lib (because the essential variable is LIBDIR, and this one is defined as $(DESTDIR)/lib). i've corrected this typo in the posting.

    did you install graphlcd-base before compiling vdr-plugin-graphlcd AND take care that there's no old version interfering?


    and vdr-plugin-graphlcd should be the most recent version of touchcol-branch!


    (both graphlcd-base and vdr-plugin-graphlcd have a (maintained) touchcol and a (no longer maintained) master branch. these _must_ not be mixed!)


    /wastl

    das ist nicht der touchcol-branch! (ich kuemmere mich ausschliesslich - wie auch mehrfach hier erwaehnt - nur um diesen)


    da liegen bereits welten zwischen dem master-branch und touchcol-branch.


    (unvollstaendige) doku zum touchcol-branch: http://www.linuxtv.org/vdrwiki…/Graphlcd-plugin/touchcol


    holen der touchcol-branches von graphlcd-base und vdr-plugin-graphlcd (siehe auch seite 1 dieses threads und oben genannte doku):


    Code
    git clone git://projects.vdr-developer.org/graphlcd-base.git -b touchcol graphlcd-base.git.touchcol
    git clone git://projects.vdr-developer.org/vdr-plugin-graphlcd -b touchcol vdr-plugin-graphlcd.touchcol


    zu den dokus: das ist wohl richtig: die alten dokus gehoerten langsam aber sicher entsorgt (und die vom touchcol-thread erstellt / gewartet / mit inhalt gefuellt).


    und dann wohl der touchcol-branch zum master-branch bestimmt ...


    EDIT: fast vergessen: 'fuzzybear' sollte natuerlich gegen den touchcol-branch patchen :)

    ich seh da beim 3.link keinen code!?


    wuerde aber ohnedies nur code akzeptieren, der gegen den aktuellen git-stand v. touchcol-branch geteset und einfach via 'patch' einzuspielen ist (da ich das zeug ja selbst nicht testen kann). am besten inkl. README.<displayname> und ergaenzungen fuer graphlcd.conf.

    SurfaceCleanerZ


    ad t6963c: der code ist nicht von mir (habe nur auf 32bit interne darstellung aufgebohrt), dementsprechend wenig erfahrung habe ich damit.


    ev. ist die abschirmung nicht ausreichend oder die kabellaenge zu lang. du kannst auch mal als gegenprobe mit dem t6963-treiber der serdisplib testen (da habe ich - wenn ich mich richtig erinnere - ein etwas anderes timing implementiert, das besser mit schlechter abschirmung etc. zurecht kommt).


    ad reel_fp: lese ich zum ersten mal (oder ich habe darueber gelesen und es nicht registriert). sagt mir gar nix.
    zumindest hat mich niemand darauf angesprochen bzgl. code-beisteuerung oder aehnlichem ...

    als argument gegen eine angleichung:


    was, wenn ein plugin auf abwaertskompatibilitaet auslegt ist?


    ich teste das graphlcd-plugin nach wie vor gegen 1.4.x, 1,6,0 und ein paar 1.7.x versionen (sogar mit einem einzigen makefile ;)


    und es ist ja auch bei genug anderen projekten gang und gaebe, dass das 'hauptprojekt' eine andere versionierung hat als darauf aufbauende erweiterungspakete (die nicht an eine bestimmte version festgenagelt sind / sein sollten).


    und eine versionsnummer sollte ja auch den entwicklungsstand / -reife eines produktes anzeigen (ich weiss: schoene heile welt).
    aber ganz sicher ist das nicht der fall, wenn auf einmal ein brandneues plugin, welches aus (ueberspitzt) 3 1/2 zeilen besteht und 'trari trara' im osd v. vdr ausgibt, ploetzlich die erwartungsvolle versionsnummer 2.0.0 in sich traegt ...
    (dass gerade in der open source welt viele durchaus produktive und stabile projekte 0.x haben, ist durchaus eine andere geschichte ...)


    /wastl

    news (graphlcd-base):

    • glcdgraphics: bug fix in glcd.c, moved methods Scale() and Blend() to
      image.c, added static methods for loading/saving image, pbm.c: changed algo for generating filenames of senquential image files (blah-00001.pbm instead of blah.pbm-00001)
    • showpic and
      convpic working again
    • convpic cleaned up, now accepts all image formats supported by libglcdgraphics, if outfile is omitted it will be automatically generated from infile, only GLCDs or PBMs are permitted for output files
    • showpic: added parameters for
      scaling and centering image, now all image formats supported by libglcdgraphics are accepted, when generating an animated GLCD all input files must match the dimension of the first image. not matching images will be ignored.
    • small bugfixes, improved logging outputs, etc.

    achtung: vdr-plugin-graphlcd muss neu kompiliert werden!

    news (graphlcd-base):

    • showpic: fix rendering bug
    • Makefiles: rename PRESTRIP to HAVE_STRIP and unset it by default

    das anzeigeproblem in showpic ist auf die schnelle gefixt (zwischenbuffer eingefuehrt, ohne dem scheint es nach der 32bit-farbumstellung nicht mehr zu funktionieren).
    showpic kann aber nach wie vor nicht skalieren oder farbraum reduzieren, aber es kann, wenn mit image/graphicsmagick-support kompiliert, alles, was image/graphicsmagick versteht, jetzt wieder anzeigen.
    strip: habe die bezeichnung an die anderen angeglichen,
    habe aber das stripping per default ausgeschaltet (darum soll sich gefaelligst das paketsystem/skript/... kuemmern (wenn es das nicht ohnedies automatisch macht wie zb. bei fedora/redhat wenn ich das richtig im kopf habe)).
    achtung:
    convpic ist nach wie vor 'broken' (da wird wohl ein wenig mehr zu fixen sein :)

    kurze zwischeninfo: deine bmps sind in ordnung, in einem skin eingebunden funktionieren sie fehlerfrei auch innerhalb v. graphlcd (eben getestet mit einem 240x128x1 display).


    das problem mit convpic und showpic ist, dass ich da wohl beim uebergang v. 1bpp auf 32bpp fuer die interne darstellung mich nicht wirklich um diese 2 tools gekuemmert habe, da werde ich wohl die showpic-eigenen bildklassen wegschmeissen und die v. glcdgraphics verwenden ...


    EDIT: das glcd ist allerdings defekt (wgn. defektem convpic)

    korrektur:


    (schon lange nix mehr am plugin gemacht ausser makefile und kleine bugfixes - deshalb nicht daran gedacht):


    es geht sehr wohl, aber nur ueber einen umweg:


    plugin mit --display=none starten und dann zur laufzeit das/die gewuenschte(n) displays via SVDRP-commands hinzufuegen.


    Zitat


    "CONNECT [<display> [<skin>]] Connect given display or reconnect all displays if called w/o parameter.",
    "DISCONN [<display>] Disconnect given display or all displays if called w/o parameter.",

    [sorry, hatte ich uebersehen]

    Mir ist gerade aufgefallen das man das Plugin nicht ohne Display starten kann. Es wird dann per default der Framebuffer als Display genommen. Ich denke das ist noch nen Relelikt aus den Zeiten als man die Displays noch nicht dynamisch connecten/disconnecten konnte.
    Wäre es möglich das zu ändern?


    nein.


    die displays, die man dynamisch connecten/disconnecten kann, sind usb-basierende (auch nicht in allen kombinationen) oder auch noch framebuffer. nicht aber solche, die am parallelport haengen (egal welches protokoll (i2c, spi, ...))


    /wastl

    ich bezog mich in meiner kritik ja auch auf leute, die nur ihre distro im auge haben und darueber hinaus nichts sehen (wollen). und die gibt es leider. gerade im vdr-bereich. und _das_ ist fuer mich kleingeisterei.


    dass keine_ahnung im prinzip diesselbe auffassung vertritt wie ich und mit seinem posting eigentlich nicht distrospezifika, sondern eine allgemein gehaltene entwicklung gemeint hat, hat er oben ja korrigiert.

    hotzenplotz5


    bitte das naechste mal mit sinnerfassendem lesen probieren!


    ich trete ja dafuer ein, programme sauber zu erstellen (inkl.allgemeiner konfig., install., ...)
    der antrieb dahinter kann aber nicht irgendeine distro/paketersteller sein, sondern eine weiter gefasste, ueber einzelne distros hinausgehende einstellung beim entwickler.


    ich vertrete hier in keiner weise irgendwelche festverdrahtungen - im gegenteil. wer mich kennt (du offenbar nicht) weiss auch, dass ich anregungen / aenderungen, wenn sie schoen dazupassen, gerne uebernehme und fuer anregungen auch dankbar bin. gerade Keine_Ahnung sticht immer wieder durch sehr gute ideen hervor.