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

  • hi,


    lange angekuendigt und vorgenommen, nun ist es realitaet:
    mein herumgepfusche an graphlcd ist online.


    kurze zusammenfassung:

    • unterstuetzung fuer farbe (urspruenglich von randy, darauf aufbauend von mir dann noch zieml. beackert)
    • unterstuetzung v. touchpad (einstweilen nur l4m320t)
    • anreicherung des skin-supports um weitere elemente/attribute/features
    • zusammenfassung der aenderungen ist im 'HISTORY' v. graphlcd-base zu finden (bis auf das, was ich vergessen habe, aufzuzaehlen :)
    • im vdr-plugin-graphlcd ist ein skin fuer das l4m320t enthalten ('touchcol'), dass fuer mich zum herumspielen dient.


    benoetigte software-versionen:

    • aktuelle SVN-version v. serdisplib (am besten vom 1.98-zweig)
    • serdisplib muss mit ./configure --enable-experimental erstellt werden (ansonsten funktioniert der support fuer GPIs nicht (touchpad))
    • sowohl v. graphlcd-base als auch von vdr-plugin-graphlcd muss der jeweilige branch 'touchcol' verwendet werden
    • skin 'touchcol' wie gewohnt ins verzeichnis <path_to_vdr_stuff>/plugins/graphlcd/skin kopieren (parallel zu 'default').
    • da dieses zeug sowieso nur mutige und fachkundige testen werden, erspare ich mir weitere erklaerungen zu kompilierung, installation, plugin-parameter, ...


    die 2 git branches koennen geholt werden zb mit:


    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



    aktuelle serdisplib zb mit:

    Code
    svn checkout  https://svn.code.sf.net/p/serdisplib/code/serdisplib/trunk serdisplib-2.x_svn



    das ganze dann mit dem skin touchcol aktivieren und dann sollte eigentlich schon knallbunte ausgabe am l4m320t erscheinen und dieses sogar mit herumtapserei zu bedienen sein.
    skin 'touchcol' ist mit focus auf das l4m320t erstellt worden und in erster linie als testskin. auf anderen displays koennte es ev. nicht gut ausschauen ;)


    aber auch ohne touchpad sollte das ganze zumindest fuer farbausgabe durchaus interessant sein (und auch schwarzweiss-displays sollten funktionieren - muss aber eingestehen, dass ich in letzter zeit nur mit farbdisplays getestet habe - da kann es unter umstaenden zu problemen kommen bei der darstellung).


    werde aber in naechster zeit noch weitere skins committen (habe ein paar herumliegen, die ich aber schon lange nicht mehr angesehen habe und die einer ueberarbeitung beduerfen).


    EDIT:


    nicht alle treiber funktionieren derzeit.
    eine uebersicht ueber die derzeit funktionierenden treiber ist hier zu finden (inkl. wachsende dokumentation ueber den skinsupport, auch dank der mithilfe v. Keine_Ahnung).
    http://www.linuxtv.org/vdrwiki…aphlcd-plugin/skinsupport


    EDIT (2013-05-18):
    serdisplib: neuer SVN-speicherort fuer sourceforge-repositories; 1.98-branch ersetzt durch trunk.
    /wastl

  • Vielen 1000 dank @ wastl. :]


    endlich kann mein l4m320t nun im vollen Umfang nutzen. :tup


    Deim ersten Start zeige das LCD einen Parse-Error wegen fehlender Fonts, die konnte ich jedoch durch ein:


    Code
    cp /usr/share/fonts/dejavu/DejaVuSans-Bold.ttf /etc/vdr/plugins/graphlcd/fonts
    cp /usr/share/fonts/dejavu/DejaVuSansCondensed.ttf /etc/vdr/plugins/graphlcd/fonts


    beheben.
    --> Evtl. kannst Du ja die in den Skins verwendeten Fonts mit ins git aufnehmen?


    Da ich mein LCD waagerecht eingebaut habe, habe ich in der graphlcd.conf den Parameter "ROTATE=90" drin, leider aber habe ich dann aber am rechten Rand einen breiten schwarzen Balken.



    Die Touchfunktion funktioniert bei mir noch nicht. Muss da noch etwas konfiguriert werden?


    Gibt es eingenlich beim "l4m320t_tool" den Parameter "-t" wie beim "l4m132c_tool" nicht?



    [EDIT]


    Touchfunktion geht, nach einem Restart. :]

  • ad fonts: oops. vergessen. sind inzw. nachgereicht.


    l4m320t im hochformat? ist das nicht eine platzverschwendung im zusammenspiel mit graphlcd? auf der anderen seite kann man dafuer aber andere spielereien unterbringen ... hast du eigentlich femon installiert? wenn ja: siehst du die signalanzeige?


    skin 'touchcol' ist zieml. auf querformat hingetrimmt und nicht wirklich adaptierend (zumindest nicht planmaessig :) - ist ja auch ein testskin.
    sollte aber durch etwas herumspielen im skin hinzubiegen sein fuer hochformat.


    ad parameter -t bei l4m320t_tool: lt. auskunft v. linux4media/digital devices gibts in der firmware keinen clockmodus wie beim l4m132c (es ist zwar ein RTC verbaut - sonst wuerde ja die alarmfunktion nicht gehen - aber eine uhranzeige ist leider nicht vorgesehen. zumindest in den mir zur verfuegung stehenden firmwareversionen nicht).


    aja: habe ich eingangs zu erwaehnen vergessen: es fehlt im ganzen graphlcd-0.2.0 (und mein touchcol-zeug basiert ja darauf) noch ein paar anzeigen wie detailinfo im schedule-menue, detailinfos bei einem recording, sprachauswahl, ...


    /wastl

  • [...].l4m320t im hochformat? ...


    Eben nicht! ich möchte ja Querformat, deshalbe habe ich es ja mit "ROTATE=90" versucht.


    Femon ist installiert, wird aber nicht angezeigt. :(


    Touch geht leider auch nicht mehr, - ging mal kurz, dann nichtmehr. :(


    Calibrieren geht leider auch nicht, da kommt nur:



    "-i" gibt einen Fehler aus:


    Code
    vdr01 ~ # l4m320t_tool -p "USB:4243/ee20" -i
    serial number: RB4QHHO31FG3EOOZ
    mismatching firmware version information: ffffffff != 00000906
    calibration coordinates: offset x/y: 0/0,  scale x/y: 1300/1300
    vdr01 ~ #


    [EDIT]


    Nach lesen der README und

    Quote

    uncomment DEFINES += -DGRAPHLCD_SERVICE_FEMON_VALID in the Makefile.


    ... geht auch die Signalanzeige. ;)

  • querformat: ok. dann hab ich nicht exakt gelesen. dann sollte der skin eigentlich schon passen?! dann wundert mich der balken schon!


    femon muss mind. 1.7.8 sein (fuer 1.7.7 gibts einen patch (im patches/ verzeichnis)).


    touch: welche architektur hast du im einsatz? 32 oder 64bit? die verwendeten uint64_t fuer timestamps & co. bereiteten mir einige probleme, sollten aber inzw. gefixt sein.



    aber das problem scheint eh tiefer zu liegen: diese von dir beschriebenen probleme habe ich glaube ich (schon ein weilchen her) mit einer problematischen firmware-version bekommen (aber das war glaube ich bereits eine fw-version mit prodID ee21).
    display aus/einstecken schafft keine abhilfe?


    /wastl


    [EDIT]:
    achtung: femon und 1.7.7: das undefine alleine funktioniert zwar, aber ohne patch crashed dann beim beenden VDR (da der entw. v. femon hier etwas uebersehen hat - in 1.7.8 ist es gefixt).

  • Das mit femon habe ich in den Griff bekommen (sie EDIT oben). Wer lesen kann ist halt klar im Voteil. :lol2


    Ich habe ein 32 Bit OS


    Code
    vdr01 ~ #  uname -a
    Linux vdr01 2.6.35-gentoo-r12 #3 SMP PREEMPT Sun Nov 21 14:00:48 CET 2010 i686 Intel(R) Atom(TM) CPU 330 @ 1.60GHz GenuineIntel GNU/Linux
    vdr01 ~ #


    LCD aus- und einstecken bringt leider nix, dann kommt nur im Log:




    Evtl. kannst Du mir ja eine Firmware zukommen lassen, oder soll ich bei L4M nachfragen?

  • femon muss mind. 1.7.8 sein (fuer 1.7.7 gibts einen patch (im patches/ verzeichnis)).


    Hast du auch beachtet das es auch noch einen Backportzweig für die 1.6 VDR Version gibt? Da geht auch femon, aber die Abfrage im graphlcd-Plugin funktioniert dann nicht richtig (jedenfalls im alten 0.2.0er Zweig).


    Hast du da in der neuen Version schon irgendwas geändert?


    cu

  • das mit dem display ist ein wenig komisch. wann genau kommt das commit-problem? nur beim kalibirieren? im normalen betrieb funktioniert das display ja ohne problem? eigentlich waren die ee20-firmwares die unproblematischen.


    hast du eh das aktuelle l4m320t_tool in verwendung und nicht eines, das bereits am system installiert war?


    /wastl

  • Keine_Ahnung: vdr 1.6.x habe ich nicht beruecksichtigt (da nicht in verwendung), habe mir aber das femon 1.6.7 schnell mal geladen und kurz im code nachgesehen: es fehlt hier derselbe bugfix wie der von 1.7.7 auf 1.7.8 -> siehe README (allerdings genuegt fuer 1.6.7 der patch femon-1.7.7_fixsegfault_patch.diff wenn ich das richtig ueberflogen habe. und dann natuerlich das mit uncomment DEFINES += -DGRAPHLCD_SERVICE_FEMON_VALID noch.


    [EDIT]: hat eigentlich nix mit vdr 1.6.x zu tun: wie im README zu lesen ist: alle femon-versionen <= 1.7.7 werden nicht ohne aenderung funktionieren. die schritte sind im README angefuehrt. wuerde dann sogar bis abwaerts femon 1.1.5 unterstuetzt! (ist auch schon ein zeitl her dass ich die patches erzeugt und das im README geschrieben habe ...)


    /wastl

  • Keine_Ahnung: vdr 1.6.x habe ich nicht beruecksichtigt (da nicht in verwendung), habe mir aber das femon 1.6.7 schnell mal geladen und kurz im code nachgesehen: es fehlt hier derselbe bugfix wie der von 1.7.7 auf 1.7.8 -> siehe README (allerdings genuegt fuer 1.6.7 der patch femon-1.7.7_fixsegfault_patch.diff wenn ich das richtig ueberflogen habe. und dann natuerlich das mit uncomment DEFINES += -DGRAPHLCD_SERVICE_FEMON_VALID noch.


    Überfordert mich jetzt etwas weil ich gerade nicht in den Quellen nachschauen kann. Werds Morgen mal nachvollziehen.



    [EDIT]: hat eigentlich nix mit vdr 1.6.x zu tun: wie im README zu lesen ist: alle femon-versionen <= 1.7.7 werden nicht ohne aenderung funktionieren. die schritte sind im README angefuehrt. wuerde dann sogar bis abwaerts femon 1.1.5 unterstuetzt! (ist auch schon ein zeitl her dass ich die patches erzeugt und das im README geschrieben habe ...)[wastl


    Ich sachs mal so ;) Ich habe bei mir die aktuellste femon Version für den 1.6er VDR, und nachdem ich die femon Versionsabfrage im graphlcd (0.2.0) deaktiviert hatte gings auch super. Also ist in graphlcd die Abfrage irgendwie falsch.


    Wenn du Interesse hast das anzugehen *) dann kann ich gerne mal die aktuelle graphlcd Version ziehen und das mit dir im Dialog richtig durchtesten (d.h ich installiere mal alle supporteten femon Versionen und passe evtl. die Patches an).


    cu


    *) Mich drängts jetzt nicht unbedingt, die 0.2.0er läuft bei mir gut und ich hab da noch andere Änderungen drin die ich erstmal nachvollziehen müsste um auf die neue Version umzusteigen. Also ich will hier nicht hetzen.

  • wastl


    Schön mal wieder von Dir zu hören, da kann ich ja tatsächlich mein L4M320T wieder auspacken und die Touch-Funktion testen. Evtl. erinnerst Du Dich an die a-typische USB-ID ... ;)


    Regards
    fnu

    HowTo: APT pinning

  • fnu
    yep, ist auch schon seit einiger zeit im SVN committed. aber noch immer nicht in der trac-seite v. l4m320t dokumentiert :)


    Keine_Ahnung
    eine genauere fehlerbeschreibung wuerde schon helfen! (screenshot/foto, was funktioniert nicht, was passiert, ...)
    an vdr 1.6.x wirds eher nicht liegen, ich hatte das ganze auch mit vdr 1.3.x in verwendung (und femon 1.1.5 wenn ich mich richtig erinnere).


    mit 'die Abfrage im graphlcd-Plugin funktioniert dann nicht richtig' allein kann ich nicht viel anfangen!


    /wastl

  • l4m320t_tool


    das mit dem display ist ein wenig komisch. wann genau kommt das commit-problem? nur beim kalibirieren? im normalen betrieb funktioniert das display ja ohne problem? eigentlich waren die ee20-firmwares die unproblematischen.


    hast du eh das aktuelle l4m320t_tool in verwendung und nicht eines, das bereits am system installiert war?


    /wastl


    Das commit Problem kommt dann, wenn graphlcd und der VDR aktiv sind und ich, wie Du vorgeschlagen hast, ab und wieder anstecke.


    Das l4m320t_tool ist aktuell von gestern.


    Was mich wundert ist, dass das "Touchen" mal ganz kurz ging und dann nie mehr. :(

  • aeh, natuerlich nicht _waehrend_ dem betrieb ein/ausstecken. sondern vor start v. vdr.


    zum l4m320t_tool: es wird tatsaechlich das aktuelle binary verwendet? du hast es naemlich mit l4m320t_tool aufgerufen lt. deinem posting und nicht mit ./4m320t_tool oder anderer absoluter pfadangabe (beim ersten kanns passieren, dass ein altes binary aufgerufen - wenn es zuvor im systempfad gefunden wird, auch wenn du im aktuellen pfad des neuen binaries bist.


    das mit dem touch: hoffentlich ist es nicht wieder ein architekturproblem mit dem typ uint64_t. der hat mir schon des oefteren hineingesch... aehm gepfuscht.muss das ganze mal auf dem alten vdr-system (32bit) ausprobieren. aber es sieht nach deiner fehlerbeschreibung fast danach aus.


    das mit l4m320t_tool (wenn du tatsaechlich das aktuelle binary verwendet hast - bitte vorher noch pruefen, nicht dass ich einem phantom nachjage) ist allerdings ein anderes problem :(
    aktuelle firmware kann ich dir schicken, aber mit ganz grosser warnung: auf eigene gefahr! mit ein paar aelteren der neuen firmware-versionen, die ich habe, war das display dann tot und konnte nur mit einem psoc-flasher wiederbelebt werden (den ich damals mal v. digital devices zugeschickt bekommen hatte). dies sollte zwar in den neueren versionen behoben sein und ist auch dann nie mehr aufgetreten, aber ausschliessen kann ich's nicht.


    /wastl

  • zum l4m320t_tool: es wird tatsaechlich das aktuelle binary verwendet? du hast es naemlich mit l4m320t_tool aufgerufen lt. deinem posting und nicht mit ./4m320t_tool oder anderer absoluter pfadangabe (beim ersten kanns passieren, dass ein altes binary aufgerufen - wenn es zuvor im systempfad gefunden wird, auch wenn du im aktuellen pfad des neuen binaries bist.


    Es ist definitiv das aktuelle, ich habe mir ein ebuild für das git gebautgebaut. ;)


    das mit l4m320t_tool (wenn du tatsaechlich das aktuelle binary verwendet hast - bitte vorher noch pruefen, nicht dass ich einem phantom nachjage) ist allerdings ein anderes problem :(
    aktuelle firmware kann ich dir schicken, aber mit ganz grosser warnung: auf eigene gefahr! mit ein paar aelteren der neuen firmware-versionen, die ich habe, war das display dann tot und konnte nur mit einem psoc-flasher wiederbelebt werden (den ich damals mal v. digital devices zugeschickt bekommen hatte). dies sollte zwar in den neueren versionen behoben sein und ist auch dann nie mehr aufgetreten, aber ausschliessen kann ich's nicht.


    Die Frage ist halt, ob es an der FW liegen kann? Zumal ja auch ein Fehler bei der FW Version ausgegeben wird.


    Code
    vdr01 ~ # l4m320t_tool -p "USB:4243/ee20" -i
    serial number: RB4QHHO31FG3EOOZ
    mismatching firmware version information: ffffffff != 00000906
    calibration coordinates: offset x/y: 0/0,  scale x/y: 1300/1300
    vdr01 ~ #


    Wenn Du meinst, dass ein FW Update etwas bringt, dann teste ich das. Sollte es vor den Baum gehen, dann kann ich es zu L4M schicken, zur "Reanimation". :D


    BTW: Das Problem mit dem "Querformat" besteht nach wie vor...


  • Keine_Ahnung
    eine genauere fehlerbeschreibung wuerde schon helfen! (screenshot/foto, was funktioniert nicht, was passiert, ...)


    Sorry fürs stören, ich habs mir gerade nochmal genauer angeschaut. DGRAPHLCD_SERVICE_FEMON_VALID war der entscheindende Hinweis, der ist mir damals vollkommen entgangen als ichs installierte, und so war ich irgendwie der festen Überzeugung die femon Versionsabfrage ist fehlerhaft weil sie die femon Backports nicht berücksichtigt. Ich hatte damals als Lösung die Abfrage manipuliert und dabei nicht gerafft das ja eigentlich DGRAPHLCD_SERVICE_FEMON_VALID genau dafür gedacht ist.


    Ist also allso alles bestens so wie es ist.


    Wobei, nur so als Idee... (da hänge ich jetzt nicht dran, kam mir gerade nur so in den Sinn) wäre es nicht evtl. sinniger beim femon Patchen der femon Versionsnummer etwas anzuhängen (z.B. ein "p") so das GraphCD selber erkennen kann ob eine zu alte Version gepatcht wurde?



    Desweiteren, wäre esmöglich das du den Patch mit aufnimmst der das Display per SVDRP an-/ausschaltbar macht? Ist im Bugtracker zu finden, wenn du möchtest kann ich den auch für die neue Version anpassen und hier anhängen.


    cu

  • Keine_Ahnung
    davon, die versionsnummer zu aendern, halte ich nichts (da ich die sideeffects nicht abschaetzen kann). ausserdem ist es ja in der offiziellen version bereits behoben (seit 1.7.8). fuer die anderen versionen gibts ja das vorgehen gemaess README (sogar bis abwaerts zu 1.1.5). und dieses wird dann hoffentlich bis zum ende gelesen :)
    das mit SVDRP sagt mir jetzt nix, ich lese aber auch nur ein paar wenige bereiche im portal.


    @C-3P0
    firmware 906 war glaube ich die letzte version fuer ee20. alle spaeteren verwenden dann productID ee21. die 906 habe ich uebrigens auch auf dem display, mit dem ich zzt teste, laufen.


    kannst du mal testen, ob das touchzeug unabhaengig v. vdr/graphlcd funktioniert:


    testserdisp -n dd320t -p "usb:4243/ee20"


    und dort dann am prompt eingeben:
    gpi test 0


    dann herumtouchen und schauen, ob viele zeilen debuginfo erscheinen.


    (mit quit dann den spass wieder beenden).



    wieso bei dir ffffffff != 00000906 erscheint, kann ich jetzt auf die schnelle nicht sagen. heisst aber nur, dass eine der zwei methoden, mit denen ich die versionsnummer abfrage, fehlschlaegt. sollte aber freilich nicht sein. werde dann mal das neueste testserdisp auf meinem 32bit rechner testen ob das dort auch auftritt (und ich ev. in einer der letzten SVN-commits etwas verpfuscht habe).


    /wastl


  • Da tut sich leider garnichts. :(


    Code
    vdr01 ~ # testserdisp -n dd320t -p "usb:4243/ee20"
    
    
    enter 'help' to get help
    
    
    > gpi test 0
    listener added
    >


    Mehr kommt leider nicht.

  • fuer die anderen versionen gibts ja das vorgehen gemaess README (sogar bis abwaerts zu 1.1.5). und dieses wird dann hoffentlich bis zum ende gelesen :)


    Ich lese Readmes, wirklich :) Aber anscheinend manchmal nicht genau genug ;)


    Bei der SVDRP Sache gehts darum: http://projects.vdr-developer.org/issues/488


    Ich nutze das dafür um im Shutdownhook GraphLCD schonmal abzuschalten und dann das Shutdownbild zu laden.
    Ferner um es zu abzuschalten wenn ich Freevo starte, das nutzt nämlich lcdproc (das kann ja per graphlcd Ausgabetreiber auf graphlcd zugreifen). Und beides gleichzeitig geht ja nicht.


    wobei das sehr viele Leute benötigen, weil auch für XBMC ist das notwedig. Und das nutzen ja auch viele hier.


    cu

  • @C-3PO


    tja, jetzt bin ich langsam mit meinem latein am ende. auch auf meinem 32bit system: kein problem. wie gesagt: ebenfalls mit firmware 906:


    firmware version: 00000906.


    kannst du das display auf einem anderen rechner (und - wenn moeglich - eine nicht gentoo-basierte distro) testen?



    btw: kannst du ein bild v.d. fehlerhaften displayausgabe machen? das taete mich auch interessieren.


    /wastl

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!