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

wastl

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/index.…gin/skinsupport

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

3PO

Vielen 1000 dank @ wastl.

endlich kann mein l4m320t nun im vollen Umfang nutzen.

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.

wastl

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

3PO

Zitat von 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:

Code

vdr01 ~ # l4m320t_tool -p "USB:4243/ee20" -C
resetting calibration ... done
>>> tap on first cross ... timeout reached!




please restart calibration
timeout reached
^C
vdr01 ~ #

Alles anzeigen

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

Zitat

uncomment DEFINES += -DGRAPHLCD_SERVICE_FEMON_VALID in the Makefile.

... geht auch die Signalanzeige.

wastl

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

3PO

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

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:

Code

.....
May 03 00:31:53 [vdr] SDCONNusb_commit(): L4M320T/LCD commiting buffer failed, error: Kein passendes Gerät bzw. keine passende Adresse gefunden
May 03 00:31:53 [vdr] SDCONNusb_readstream(): generic interrupted read could not read from device: Kein passendes Gerät bzw. keine passende Adresse gefunden (6)
                - Last output repeated 24 times -
May 03 00:31:53 [vdr] SDCONNusb_commit(): L4M320T/LCD commiting buffer failed, error: Kein passendes Gerät bzw. keine passende Adresse gefunden
May 03 00:31:53 [vdr] SDCONNusb_readstream(): generic interrupted read could not read from device: Kein passendes Gerät bzw. keine passende Adresse gefunden (6)
                - Last output repeated 13 times -
May 03 00:31:53 [vdr] SDCONNusb_commit(): L4M320T/LCD commiting buffer failed, error: Kein passendes Gerät bzw. keine passende Adresse gefunden
May 03 00:31:53 [vdr] SDCONNusb_readstream(): generic interrupted read could not read from device: Kein passendes Gerät bzw. keine passende Adresse gefunden (6)
May 03 00:31:53 [vdr] SDCONNusb_commit(): L4M320T/LCD commiting buffer failed, error: Kein passendes Gerät bzw. keine passende Adresse gefunden
May 03 00:31:53 [vdr] SDCONNusb_readstream(): generic interrupted read could not read from device: Kein passendes Gerät bzw. keine passende Adresse gefunden (6)
......

Alles anzeigen

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

Keine_Ahnung

Zitat von wastl

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

wastl

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

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

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

Zitat von wastl

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

fnu

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

wastl

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

3PO

Zitat von wastl

l4m320t_tool

Zitat von wastl

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.

wastl

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

3PO

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

Zitat von wastl

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

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

Keine_Ahnung

Zitat von wastl

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

wastl

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

3PO

Zitat von wastl

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

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.

Keine_Ahnung

Zitat von wastl

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

wastl

@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

Jetzt mitmachen!