Beiträge von wastl

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

    mentox:
    eigentlich sollte sowohl femon als auch direkt signalinfo ueber VDR funktionieren (zweites ab vdr 1.7.26).
    welche version v. femon-plugin verwendest du? hast du es auch geladen?


    @3-CP0:
    serdisplib kann framebuffer-devices ansteuern (in der SVN-version). inkl. sonderbehandlung fuer displaylink (damage report).
    der framebuffer selber und die zu verwendende aufloesung muss aber zuvor mit betriebssystemmitteln konfiguriert werden (fbset). serdisplib greift dann ueber den treiber 'framebuffer' darauf zu.
    optionen:
    'FBDEV' .. standard: /dev/fb0
    'DAMAGE' .. standard: keine extrabehandlung. fuer udlfb (framebuffer modul fuer displaylink) empfohlen: DAMAGE=UDLFB


    es gaebe auch noch support fuer die libdlo (serdisplibtreiber 'displaylink'), aber von der kann ich nur abraten (entwicklung v. libdlo steht seit 2009, fehlerhaft bei hoeheren aufloesungen, keine kompression bei der uebertragung), serdisplib muesste auch extra damit kompiliert werden. auf der anderen seite wuerde man sich das herumeiern mit fbset & co. ersparen ...

    Im Menü werden die Werte auch nicht über femon dargestellt. Dort werden die Werte direkt aus dem VDR genommen, was graphlcd aber nicht kann

    stimmt nicht. kann vdr-plugin-graphlcd seit git-commit v. 2011-10-29 (vgl: http://projects.vdr-developer.org/git/vdr-plugin-graphlcd.git/commit/?h=touchcol&id=bbc8b87ab292360a46348e6dc8f2aaea48cb2b88)


    "{ServiceItem:femon,percent_snr}" und "{ServiceItem:femon,percent_signal}" sind 0

    neueste git-version v vdr-plugin-graphlcd? den bug haette ich eigentlich am 2012-03-27 behoben (vgl.: http://projects.vdr-developer.org/git/vdr-plugin-graphlcd.git/commit/?h=touchcol&id=f0c1141ba18d3bca4bea17841ee805d4b29a0c07)

    wenn du mit den fonts in plugins/graphlcd/fonts auslangen findest: fein, ansonsten noch ein wenig warten (moechte in der doku noch ein paar fontconfig-beispiele inkl. moeglichkeiten fuer fall backs usw. hineinschreiben).


    den skin bitte nicht nach dem treiber benennen (ein spezialisierter 256x64-skin wird auch fuer andere displays interessant sein). 'mentox' oder so wuerde sich anbieten. ausser du hast vor, meherer skins zu entwerfen :)


    den skin entw. irgendwo downloadbar machen oder mir mailen. ich werde ihn dann ins GIT werfen (muss aber vorher noch ein paar dinge bereinigen (zb. symbols aus der skin-definition wegbringen)).

    naja. die maske invertiert ja nur die signale. und davon gibt es in diesem fall 3 (/RD, /WR, C/D). die maske ist mit 11 angegeben = 1011. die null kannst du ignorieren, da parport 16 (INIT) nicht verwendet wird => mask = 1#11


    und damit kannst du dann genauso die 6 HI/LO-folgen wie im originalcode hinbasteln.


    warum das mit RDHI bzw. RDLO nicht funktioniert hat:
    /RD (oder auch nRD geschrieben) ist active low (heisst, dass RD aktiv ist, wenn es auf 0 gesetzt ist. der parport invertiert auf pin 14 aber ebenfalls (weil auch dieser active low ist) -> dh will man, dass NICHT vom display gelesen wird (RD also nicht aktiv ist), muss man im code RD auf 0 setzen. RD = 0, parport pin 14 macht 1 daraus, 1 heisst: RD ist nicht aktiv.
    weil aber RD im originalcode auf 1 gesetzt worden ist, konnte dein display mit windows-wiring nicht funktionieren, da dem display dadurch mitgeteilt worden ist: bitte vom display etwas auslesen!
    beim standard-wiring ist dieser fehler deshalb nicht aufgefallen, weil sowohl RDHI als auch RDLO mit 0x00 definiert sind ...


    anmerkung (der vollstaendigkeit halber):
    eigentlich ist die beruecksichtigung von RD im code ohnedies ueberfluessig, da es sich sowieso nie aendert bei der ganzen ansteuerung. es wuerde daher ausreichen, RD 'hardwired' auf high zu ziehen (= direkt mit +5V (via vorwiderstand) zu verbinden). dann wuerde man mit 2 anzusteuernden signalleitungen im code auskommen ...
    aber die 2 wirings haben sich nun mal so eingebuergert ...

    hab das ganze mal am papier durchgespielt (testen kann ich wie gesagt das ganze nicht an einem display).


    so wie's im bestehenden code fuer das windows-wiring definiert ist, kann's gar nicht gehen.


    eventuell reicht eine kleine aenderung, und es sollte funktionieren (nicht vergessen: im graphlcd.conf Wiring=Windows setzen bei [gu256x64-372]):


    alt:

    Code
    const unsigned char kWindowsWRHI = 0x00; // 01 / nSTRB
    const unsigned char kWindowsWRLO = 0x01; //
    const unsigned char kWindowsRDHI = 0x00; // 14 / nLINEFEED
    const unsigned char kWindowsRDLO = 0x02; //
    const unsigned char kWindowsCDHI = 0x00; // 17 / nSELECT
    const unsigned char kWindowsCDLO = 0x08; //


    neu:

    Code
    const unsigned char kWindowsWRHI = 0x00; // 01 / nSTRB
    const unsigned char kWindowsWRLO = 0x01; //
    const unsigned char kWindowsRDHI = 0x02; // 14 / nLINEFEED
    const unsigned char kWindowsRDLO = 0x00; //
    const unsigned char kWindowsCDHI = 0x00; // 17 / nSELECT
    const unsigned char kWindowsCDLO = 0x08; //


    (es werden nur die definitionen fuer RDLO und RDHI ausgetauscht. denn die koennen im vorliegenden code nicht stimmen. nehme an, dass der urspruengliche entwickler ausschliesslich mit standard-wiring getestet hat.)


    ist dann zwar immer noch nicht sauber (eigentlich gehoeren bei den signalfolgen RDHI und RDLO ausgetauscht, aber das mache ich dann, wenn positive rueckmeldung von dir kommt.


    bitte testen!

    du verwendest ja dieses wiring:

    Code
    Strobe (01)   nWR   (17)   (Write)
    nSEL   (17)   R/S   (19)   (Register Select, C/D)
    Line	(14)   nRD   (21)   (Read)


    dann bitte auf das aendern des folgenden abschnittes beschraenken:

    Code
    const unsigned char kWindowsWRHI = 0x00; // 01 / nSTRB
    const unsigned char kWindowsWRLO = 0x01; //
    const unsigned char kWindowsRDHI = 0x00; // 14 / nLINEFEED
    const unsigned char kWindowsRDLO = 0x02; //
    const unsigned char kWindowsCDHI = 0x00; // 17 / nSELECT
    const unsigned char kWindowsCDLO = 0x08; //


    (da brauchts dann auch keine mask. mit ein bisschen bool'scher algebra sollten die zeilen oben leicht angepasst werden koennen)
    und deine version benoetigt noch eine zusaetzliche zusaetzliche signalschaltung (port->WriteControl() + nSleep())


    der GU256X64_372-treiber ist leider noch immer nicht verifiziert ob er funktioniert nach der touchcol-umstellung .. (wenn er von keinem vermisst wird, wandle ich ihn in einen 355er um ...)
    ich kann leider weder noch (372 vs. 355) testen (habe nur ein paar gu128x18 oder so herumliegen die noch auf ansteuerung warten ...)



    nachtrag:


    eigentlich sollten 372 und 355 zueinander kompatibel sein (lt. div. beitraegen im netz). kann es sein, dass du ein etwas laengeres kabel + schlechte abschirmung hast, so dass dein display die etwas schnellere ansteuerung (mit 3 statt 4 pegelschaltungen) nicht vertraegt? (ist nur geraten, aber ich habe ja selber schon viel mit solchen signalansteuerungen herumgespielt und da haengt es immer wieder mal von kabellaenge/schirmung/... ab).

    mit welcher GIT-version wurde das kompiliert?


    die API-aenderung, in der UsesDevice() weggekommen ist (vdr 1.7.26), ist naemlich bereits seit 2012-03-11 beruecksichtigt (siehe auch:
    http://projects.vdr-developer.org/git/vdr-plugin-graphlcd.git/commit/?h=touchcol&id=3c20bf87becd03e85151e4c6b8d5ff0cc5651980)


    ich habe zwar jetzt nicht mit 1.7.28 getestet (noch 1.7.27 im einsatz), aber zumindest das mit UsesDevice() sollte kein problem mehr darstellen ...

    wow. da ist tatsaechlich inline assembler enthalten ...
    hab mich wohl bis dato noch nicht bis nach port.[ch] verirrt und ist mir daher noch gar nicht aufgefallen ...


    das werde ich in ein #if defined(__linux__) && (defined(__i386__) || defined(__x86_64__)) .. #endif
    einwickeln.
    dann ist das nur auf die intel-kompatiblen archs beschraenkt ...

    news (graphlcd-base):

    • Image/GraphicsMagick: use much more relieable sample() instead of scale() for scaling images:
      problems with distorted scaled icons/images or other display errors should now be history.
    • monochrome images: fix monochrome bug in imagefile.c:
      bgcolor and color should be working again for monochrome icons/symbols
    • improved relieability of eq()/ne()/gt()/lt()/ge()/le() if comparing 'mixture' of string / bool / value
    • fixed a bug which could lead to an infinite loop under rare circumstances (if a content part contains a spare # without a variable name)
    • permit and evaluate $( )$ expressions to enable direct embedding of functions in the content part of elements such as <text/>:
      eg: <text>$(add(#SomeVar,#SomeOtherVar))$</text>
      attention: $()$ is not verified (yet) when parsing the skin. if it contains syntactical errors, the unprocessed term will be displayed at runtime.
    • clang can now be used instead of g++.
      'CXX=clang make' now compiles the whole graphlcd-base using clang.
    • added support for fontconfig font name representations:
      eg.: <font id="FontInfo" url="fc:Sans Serif:bold:size=12"/>
      attention: specifying a size term (eg. 'size=12') is mandatory!

    news (vdr-plugin-graphlcd):

    • fixed a bug that has been introduced in a former update and rendered some services unusable

    der touchcol-skin ist auch nicht wirklich auf skalierbarkeit ausgelegt sondern zieml. auf 320x240 hingearbeitet. sieht man auch an den einander ueberlappenden schriftzuegen.
    am besten, du nimmst dir den default-skin als grundlage. der sollte viel besser skalieren.


    sdl: da wird dann nicht auf ein physikalisches display ausgegeben, sondern auf der x11-oeberflaeche ein SDL-fenster aufgemacht, welches man dann mit einem screenshot-programm (z.b. ksnapshot) 'abfotografieren' kann. beispiele gibt es in diesem thread einige (fast alle bilder von mir).

    naehere erlaeuterungen? fotos?
    damit vielleicht andere einen 'plan' davon haben koennen, wo's spiesst?


    screenshots kann man btw. bequem via sdl-treiber machen:
    einfach in graphlcd anhaengen:


    Code
    [test_sdl]
    Driver=serdisp
    Device=out:
    Controller=sdl
    Options=depth=1;width=128;height=64


    und dann "test_sdl" verwenden bei -d

    'run' ist ein gdb (gnu-debugger) befehl. wenn das zeichnen nach dem gpi test normal funktioniert, bringt ein springen in den gdb (ctrl c) freilich nix.
    da ist es sinnvoller, wenn du die relevanten zeilen aus /var/log/messages schickst wenn das display bei dir haengt.

    gemaess der ausgabe sieht's aber nicht danach aus, dass das display haengen geblieben ist?
    kann er nach dem 'enter' druecken (abbruch v. gpi test 0) dann noch normal zeichnen? bei mir haengt dann die dem gpi test nachfolgende operation.

    ah, der bug ist mittlerweile in fedora behoben, darum habe ich nicht mehr daran gedacht.


    du musst bei dir wohl noch ein LD_PRELOAD=/lib64/libpthread.so.0 davor haengen (haengt vom verwendeten system ab was genau). scheint ein bug bei aktuellen gdb-installationen zu sein.


    dh zb also:


    LD_PRELOAD=/lib64/libpthread.so.0 gdb --args src/testserdisp -n ctinclud -p usb:7c0/1501


    siehe auch:
    http://stackoverflow.com/quest…new-threads-generic-error


    (bei 64bit wohl statt lib -> lib64 oder so ...)

    sind es dieselben haenger? dh. haengt es nur dann, wenn auch die fernbedienungscodes ausgelesen werden? oder haengt es auch im 'normalen' displaybetrieb (ohne IR aktiv)?


    bei IR haengt es bei mir nur mit der libusb, und auch da nur, sobald libusb1 + libusb0 compatibility layer verwendet wird. bei echter libusb0: kein problem).


    kannst du folgenden test machen (mit gdb):


    gdb --args src/testserdisp -n ctinclud -p usb:7c0/1501


    bei (gdb) 'run' eingeben


    am prompt von testserdisp 'gpi test 0' eingeben
    ein paar mal mit der fernbedienung spielen, dann mit 'enter' den testmodus abbrechen
    'p 1' eingeben, display sollte haengen (es zeichnet nix mehr)
    'ctrl c' druecken
    (du bist wieder im gdb)
    'bt' eingeben und die ausgabe hier pasten



    du kannst das auch mit iow24 machen (dh. einfach -p weglassen oder dort iow24:/dev/usb/iowarrior1 angeben



    firmware: keine ahnung, ich habe das display genauso in verwendung, wie ich es damals vor ca. 100 jahren von ralf bekommen habe :)
    kann man den nachbau selber flashen?