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

Hallo,

ich bin weiter gekommen.
Ich habe momentan keinen Zugang zum HTPC, deswegen konnte ich auch nur graphlcd-base testen.
Das Problem scheint also nicht im Plugin zu liegen. Der Fehler zeigte sich mit showpic einfach nicht bei kleinen Bildern.
Hab mit folgendem Befehl ein Schachbrettmuster erzeugt und angezeigt:

convert -size 320x240 pattern:checkerboard -colors 2 -colorspace gray -normalize chessboard.png && showpic -c /etc/graphlcd.conf -d ax206dpf chessboard.png

Vorher hab ich graphlcd-base mit imagemagick-support kompiliert.
Die beiden angehängten Bilder zeigen, wie es ist (mit linkdelight_3) bzw. wie es sein sollte.
Ich habe mal ausgezählt, ab welchem Pixel das Muster verschoben ist und siehe da: 8193 = 2^13 + 1.

Ich hoffe das hilft euch weiter den Bug zu finden, wo auch immer er liegen mag.

Vielen Dank soweit!
olebowle

Habs gerade mal bei mir probiert:
- Neueste graphlcd-base aus dem Git.
- Fünf verschiedene Displays (unterschiedliche Hw, Firmware 0.320).
- Zusätzlich linkdelight_3 auf Pearl-Hardware (flimmert zwar etwas, aber sonst okay).
- Dein "Checkerboard" Test.
Alle Displays zeigen das Schachbrett korrekt an. An graphhlcd / Treiber / Firmware liegt es also nicht.

Ich tippe mal, dass dein Dpf einen Schuss hat. Zeigt es denn den Testscreen (Menü - Setup - Screen Testpattern) korrekt an?

Gruß
superelchi

Das Testbild wird richtig angezeigt. Ich kann mir schlecht vorstellen, dass alle 3 LCDs denselben Treffer haben. Zumindest will ich das mal nicht hoffen.

Als Firmware für linkdelight_3 hab ich folgendes Binary von dir benutzt: [HOWTO] Pearl DPF Easy Hacking
Ich hab die Firmware nämlich nicht bauen können. Zunächst mal musste ich den angehängten Patch anwenden. Aber selbst dann bekomme ich beim buildall-Skript:

Building linkdelight_3
cat: .buildno: Datei oder Verzeichnis nicht gefunden
Makefile:277: *** missing separator.  Schluss.
cat: .buildno: Datei oder Verzeichnis nicht gefunden
Makefile:277: *** missing separator.  Schluss.

und das vermutlich bei allen LCD-Targets.

Hier mal die gesamte Abfolge:
- svn co https://dpf-ax.svn.sourceforge.net/svnroot/dpf-ax
- cd dpf-ax/trunk
- Patch anwenden
- make (siehe angehängtes build.log)
- cd fw
- via Menü verbinden
- sudo python2 identify.py /dev/sr1
- sudo python2 fulldump.py /dev/sr1
- via Menü ausschalten
- Menü halten + Reset
- anstecken
- sudo ./hiddetach
- sudo python2 restore.py ~/Desktop/fw_disp_linkdelight_x.bin -f (das ist wiederum dein Binary)

Um auszuschließen, dass ich vielleicht doch eine neuere Originalversion hab, hier mal die md5sums der fulldumps:

d19a80d1eda22dad909b3a980b7008f9  linkdelight_2_full_backup.bin
b4d35f6b9fd578242a15a3529d4a4823  linkdelight_3_full_backup.bin

Wenn ich jetzt doch aus Versehen Version 2 und 3 vertauscht hätte (was ich bezweifle), würde das den Fehler erklären bzw. kann ich ohne Probleme einfach mal die andere Version flashen?

Edit:
Es hat ein TAB in Zeile 277 des Makefiles gefehlt.
Das mit dem Bauen des Binaries wird hier unter Archlinux ohnehin nicht einfach. Denn obwohl ich sdcc installiert habe fehlt mir sowohl asx8051, als auch aslink. Ist das Binary vom o.g. Link aktuell?

Da der Fehler ja anscheinend nix mit graphlcd zu tun hat, schlage ich vor wir machen hier weiter.

Gruß
superelchi

Zitat von olebowle

Das mit dem Bauen des Binaries wird hier unter Archlinux ohnehin nicht einfach. Denn obwohl ich sdcc installiert habe fehlt mir sowohl asx8051, als auch aslink. Ist das Binary vom o.g. Link aktuell?

aslink und asx8051 sind nur bis sdcc 2.9.0 enthalten. Neuere sdcc-Versionen kommen ohne 8051 binaries. Für Ubuntu gibt es mit cc1111 einen Fork von sdcc 2.9.0, der die beiden enthält.

Zitat von Flowdalic

aslink und asx8051 sind nur bis sdcc 2.9.0 enthalten. Neuere sdcc-Versionen kommen ohne 8051 binaries. Für Ubuntu gibt es mit cc1111 einen Fork von sdcc 2.9.0, der die beiden enthält.

Danke für den Tip, damit hat es funktioniert.

Hallo,

bin seit einiger Zeit auch auf die touchcol-Branches von graphlcd-base und vdr-graphlcd umgestiegen, es läuft aber bei mir noch nicht so ganz sauber. Ich muß noch hinzufügen, dass ich mein Display (noritake800) nur im DirectIO-Modus nutzen kann. Sehr oft kann ich beim VDR einen Absturz während des Kanalwechsels reproduzieren, im Logfile von VDR steht dabei nichts gescheites, deswegen habe ich mal alles mit Debugsymbolen gebaut, um zu einem backtrace via coredump gelangen zu können. Der Absturz passiert auch wenn ich die Anzahl der Plugins auf 3 reduziere (ein skin, graphlcd und softhddevice) und VDR in der Konsole starte:

vdr --watchdog=0 --epgfile=/var/tmp/_media-databases/epg.data --log="3.7" --video=/video0 --port=6419 --lirc=/var/run/lirc/lircd --record=/usr/share/vdr/bin/vdrrecord-gate.sh --no-kbd --grab=/mnt/other/MediaPool/Media/vdr-grabbed --shutdown=/usr/share/vdr/bin/vdrshutdown-gate.sh  --plugin='skinenigmang -l /usr/share/vdr/skinenigmang --logodir=/usr/share/vdr/skinenigmang --epgimages=/video/epg_image_cache' --plugin='softhddevice -v vdpau -a hdmi:CARD=NVidia_1,DEV=1,AES0=0x04,AES1=0x82,AES2=0x00,AES3=0x00 -p iec958 -d :0.0 -g 1920x1080+0+0 -s -D' --plugin='graphlcd -c /etc/vdr/plugins/graphlcd/graphlcd.conf -d noritake800 -p /etc/vdr/plugins/graphlcd/skins.custom -s default-VdrSym'

Wenn ich dann anfange zu zappen, ist nach einigen Sendern Schluß, backtrace kann man hier sehen. Danach zu urteilen scheint es der Aufruf zum Verändern der Hellligkeit des Displays zu sein, was dies verursacht, aber warum da in port.c:57 das schief geht, verstehe ich nicht. Ich habe auch probiert, die Zugriffe auf den Parallelport mit einem Mutex zu schützen , bringt auch nichts. Weiß da jemand Rat?

Alternativ, wenn ich auf PPDEV umstelle, funktioniert gar nichts, das Display wird nicht mal initialisiert (egal, ob als user vdr oder root). Vielleicht muß ich noch im Code bei noritake800.c nachbessern, kann mir jemand sagen, welches von den von graphlcd-base unterstützten Displays mit /dev/parport0 gut funktioniert, damit ich mir den Code da angucken soll? Ansonsten glaube ich dafür die Voraussetzungen zu erfüllen, korrigiert mich bitte, wenn da was nicht in Ordnung sein sollte:

vdr@HTPC2 /var/portage/layman/gen2ovl-googoo2/app-misc/graphlcd-base $ dmesg | grep parport
[   17.416307] parport_pc 00:05: reported by Plug and Play ACPI
[   17.416362] parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
[ 5230.579630] parport_pc 00:05: disabled
[ 5231.194356] parport_pc 00:05: activated
vdr@HTPC2 /var/portage/layman/gen2ovl-googoo2/app-misc/graphlcd-base $ lsmod | grep ppd
ppdev               	5944  0
parport            	26711  3 imm,ppdev,parport_pc
vdr@HTPC2 /var/portage/layman/gen2ovl-googoo2/app-misc/graphlcd-base $ lsmod | grep par
parport_pc         	25489  0
parport            	26711  3 imm,ppdev,parport_pc
vdr@HTPC2 /var/portage/layman/gen2ovl-googoo2/app-misc/graphlcd-base $ ls -al /dev/parport0
crw-rw---- 1 root lp 99, 0 Nov 15 01:30 /dev/parport0
vdr@HTPC2 /var/portage/layman/gen2ovl-googoo2/app-misc/graphlcd-base $ getent group | grep vdr | grep lp
lp:x:7:lp,sabayonuser,vdr,root

Gruß,
Lucian

Zitat von Zoolook

bin seit einiger Zeit auch auf die touchcol-Branches von graphlcd-base und vdr-graphlcd umgestiegen, es läuft aber bei mir noch nicht so ganz sauber. Ich muß noch hinzufügen, dass ich mein Display (noritake800) nur im DirectIO-Modus nutzen kann. Sehr oft kann ich beim VDR einen Absturz während des Kanalwechsels reproduzieren, im Logfile von VDR steht dabei nichts gescheites, deswegen habe ich mal alles mit Debugsymbolen gebaut, um zu einem backtrace via coredump gelangen zu können. Der Absturz passiert auch wenn ich die Anzahl der Plugins auf 3 reduziere (ein skin, graphlcd und softhddevice) und VDR in der Konsole starte:

Hat sich nun erledigt, bei mir funktioniert nun auch endlich der PPDEV-Modus, in welchem ich keinen Absturz provozieren kann. Ich habe ein bisschen an cParallelPort und am noritake800-Treiber gefixt und commitet. Wer schon touchcol benutzt, bitte probiert den letzten Stand aus, ich hoffe es gibt damit keine Regression, zumindest nicht wenn man PPDEV nutzt...

Gute Nacht,
Lucian

Hi,

mir gerade aufgefallen, dass die Funktion "Helligkeit bei Nutzerinaktivität" nicht funktioniert, wenn gerade Aufgenommen wird.

Aus aktuellen Anlass (weil gerade jemand danach gefragt hat)... wäre es möglich das simlcd Windows Programm (zum simlcd Graphlcd Treiber) mit auf die Project Homepage unter Downloads zu packen? https://dl.dropbox.com/u/16648062/simlcd.zip?

Sibbi (der Author) hat nix degegen wenn es dort zur Verfügung gestellt wird.

cu

Wozu braucht es hier Windows? Ist der Displaytreiber nicht autark?

Zitat von Mreimer

Wozu braucht es hier Windows? Ist der Displaytreiber nicht autark?

Nun ja, wenn man die Ausgabe unter Windows nutzen will dann brauchts nen Windows Client Programm, liegt irgenwie in der Natur der Sache

Die Hauptzielgruppe hierfür dürften Skin Developer sein die gerne Windows zum Developen nutzen.

BTW: Ich habe das archiv nochmal gepackt https://dl.dropbox.com/u/16648062/1/simlcd.zip
und mal schnell nen Installer dazu gemacht https://dl.dropbox.com/u/16648062/1/SimLCD-setup.exe

Edit: Habs gerade nochmal upgedatet, JETZT ist da die final Version.

cu

Hallo allerseits,

habe mir für das Display picoLCD Graph 256x64 einen Treiber für graphlcd-Plugin aus dem touchcol-Branch geschrieben (Source von yavdr 0.5).
Die Entwicklung basiert auf dem Treiber für lcd4linux.

1) Testet noch jemand mit?
2) BTW: Das Display hat fünf Tasten (Home, Back, Hoch, Runter, OK). Kann man damit was bei graphlcd anfangen?

Ich würde den Treiber gerne der Allgemeinheit zukommen lassen. Wie kann ich das denn tun?

Viele Grüße und ein gutes neues Jahr,

vdrstarter

Zitat von vdrstarter

Ich würde den Treiber gerne der Allgemeinheit zukommen lassen. Wie kann ich das denn tun?

Wenn's getestet ist, haenge einfach ein Diff gegen aktuelles git von graphlcd-base in einem issue als "Feature" auf vdr-developer.org aan, dann koennen wir es integrieren.

Ciao, Lucian

Ok, mein Treiber in Form eines "git diff" als Feature-Request im System.

Für alle Interessierten - habe das Skin l3x Version 0.8 mit dem Display in Verwendung. Finde, die Kombination paßt gut zusammen. Danke für das Skin.

Grüße,

vdrstarter

Guten Morgen,

das Plugin Makefile habe ich im "touchcol" Branch umgekrempelt, damit es den neuen Vorgaben von VDR entspricht. Es kann auch nun selber Resourcen installieren, bei Bedarf, davon sind jeweils die Docs und die TTFs abschaltbar, da sie unter Gentoo komprimiert, bezw. aus dem System gesymlinkt werden.
Falls das Resourcen-Dir nicht ermittelt werden kann, wird nun von /usr/share/vdr/plugins/graphlcd ausgegangen, sollte in allen noch supporteten VDR-Versionen funktionieren, bitte testen.
Der Support fuer die obsolete Internationalisierung (i18n.h / i18n.c) ist auskommentiert, koennen wir das komplett heraus nehmen?

Have phun, Lucian

Eine Kleinigkeit die mir vorhin bei ner schnellen Durchsicht des neuen Makefiles aufgefallen ist... channels.alias wäre im confdir besser aufgehoben als im resdir. Das müssen die meisten User eh anpassen also ist es eher eine Konfigurationsdatei.
Ferner könnte man überlegen ob das Makefile beim install prüft ob diese Datei am Ziel schon besteht und diese dann nicht überschreibt.

BTW: graphlcd.conf per default ins confdir verschoben!? Dann braucht man sie doppelt weil die base Tools in /etc suchen.

cu

Hi,

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

nun sollte es klappen.

Zitat von wastl

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

Tue ich nicht wirklich, ich hatte unter Gentoo gegen 1.6.0 aus dem Source Tree das Kompilieren getestet, aber dabei vergessen vom installiertem 1.7.35 die /usr/lib64/pkgconfig/vdr.pc und die installierten VDR-Header zumindest temporär umzubenennen oder zu entfernen, daher klappte es bei mir auch mit VDRDIR und dem ganzen Rest.

Zitat von wastl

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.

Das hier habe ich nun im Source-Tree von vdr-1.4.7 angepasst, noch mit den oben erwähnten Vorkehrungen.

Zitat von wastl

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

Ok, war nur 'ne Frage

Zitat von Keine_Ahnung

Eine Kleinigkeit die mir vorhin bei ner schnellen Durchsicht des neuen Makefiles aufgefallen ist... channels.alias wäre im confdir besser aufgehoben als im resdir. Das müssen die meisten User eh anpassen also ist es eher eine Konfigurationsdatei.
Ferner könnte man überlegen ob das Makefile beim install prüft ob diese Datei am Ziel schon besteht und diese dann nicht überschreibt.

Das ist so 'ne Sache. Du hast ja Recht das manche User die Datei editieren, aber dadurch dass die Skins, die ja letztendlich Resourcen sind, unter die RESDIR-Hierarchie landet, wird im Code des Plugins nach channels.alias eben in RESDIR gesucht, auch wenn das ueber eine Variable die glaube ich CfgDir heisst gemacht wird. Ich wuerde da eher den Code so anpassen, dass an beiden Orten nach dieser Datei gesucht wird, so wird man immer mit upstream-Versionen der channels.alias bei einem Upgrade versorgt, und trotzdem kann das Plugin dann auch eigene Änderungen mit dazu nehmen (oder den Vorrang geben, dann muß der User selber schauen ob er beim Upgrade seine eigen Datei noch von der Neuen updatet, so dass er auch die Neuigkeiten, und seine eigenen Änderungen hat).

Zitat von Keine_Ahnung

BTW: graphlcd.conf per default ins confdir verschoben!? Dann braucht man sie doppelt weil die base Tools in /etc suchen.

Ok, das ist nicht nötig, habe ich rückgängig gemacht. Man braucht sie in dem Fall aber nicht unbeding doppelt, man kann gegen /etc/graphlcd.conf symlinken, oder man will sie doppelt, um eine vielleicht vereinfachte Version nur fuer das eigene Display und nur für VDR pflegt, mit anderen Einstellungen als die globalen, die ja wie von Dir erwähnt für die graphlcd-base Tools, aber auch eventuell für LCDproc wenn vdr-graphlcd deaktiviert ist, zuständig ist. Wie auch immer, man hat diese Freiheit auch so, über den Laufzeitparameter, deswegen bleibt's wie es vorher war.

Was ich noch ergänzend zu der channels.alias Problematik erwähnen wollte: Bei den Skins z.B., auch wenn man sie unter RESDIR ablegt, wenn man ein Eigenes braucht welches beim nächsten Upgrade nicht überschrieben werden soll, kann man es jetzt schon sonstwo ablegen (aber am elegantesten unter CONFDIR) und man muss dann nur den Pfad und den Skin-Namen in den Startparametern übergeben, trotzdem werden die Fonts aus RESDIR dann immer noch gefunden. Was ich jetzt gerade nicht getestet habe, und bin eigentlich auf Arbeit, ist ob man in der touchcol-Variante des Plugins skins aus dem Setup-Osd ändern kann. Wenn das der Fall ist, bietet es sich an mit dem Skinverzeichnis ähnlich vorzugehen, so dass sowohl die originalen Skins aus dem RESDIR, als auch die aus dem CONFDIR die der User selber pflegt zur Auswahl stehen.

Mit dem Risiko ein klein wenig OT zu werden, will ich da noch ein bisschen auf einen allgemeinen Umstand hinweisen, der aber auch vdr-graphlcd betrifft. Eigentlich ist das hier ein in vielen Plugins immer wiederkehrendes Problem welches jeder selber und oft anders löst, eine Logik die entscheiden soll, wann irgend ein Pfad oder eine Datei aus RESDIR wo eigentlich jene die von der Distribution installiert werden verwendet werden soll, und wann der kanonisch ähnliche Pfad oder gleiche Datei aus CONFDIR genommen werden soll, die von den Usern oder Sys-Admins lokal verändert werden. Noch käme hinzu ein intelligentes Mischen der beiden Quellen, in manchen Fällen. Weil es diese Problematik bei vielen Plugins gibt, (ein anderes Beispiel, VDR-Skins, die Channel-Logos anzeigen, da hat man das gleich Problem, der User koennte eigen Aliase haben, eigene Bildchen, wuerde aber gerne auch von jenen die der Distributor updatet ohne Kopfschmerzen profitieren, ohne sich um alle selber zu kuemmern, nur um seine, sofern er sie nicht upstream submittet). Eine ähnliche Problematik trifft auch bei anderem redundantem Code welches in vielen Plugins verstreut ist, ein Beispiel dafuer, ganz generisch, Laden und oft etwas grundlegendes Verarbeiten von Bildern (meistens Skalierungen) aus verschiedenen Formaten, dann implementiert jedes Plugin seinen Wrapper um Imagemagick oder imlib2 oder sonstwas herum, die im Grunde das gleiche tun. Das zusammen mit der Pfad-Problematik und mit sicherlich noch weitern in VDR-Plugins sind Kandidaten dafuer, dem Kls eine für VDR minimal-Invasive Schnittstelle vorzuschlagen, für sogenannte "Plugin Shared Libs" (PSL), die als eigene *.so die gegen eine gewisse VDR-Version gebaut werden, in das Plugin-Verzeichnis landen, aber vom VDR selber nicht als Plugins gestartert werden, sondern nur den eigentlichen Plugins zur gemeinsamen Nutzung zur Verfügung stellen. Dafür reicht es denke ich, von solchen "PSL-s" die Header ähnlich wie die VDR-Header unter ein Include Verzeichnis zu symlinken wenn man aus dem VDR-Tree baut (das muß im VDR-Makefile noch gepatcht werden), oder die Header im System zu installieren wenn man eigenständig baut. Was haltet ihr fachkundigen Mitstreiter davon, dem Kls sowas vorzuschlagen? Letztendlich soll es den Plugin-Entwicklern dienen, die sich dann auf gemeinsame APIs für gewisse PLS verständigen sollen, und sie dann diese gemeinsam genutzten PLS gemeinsam in eigenen Projekten pflegen sollten.

Grüsse, Lucian