Ja bei deinem neueren Plugin war der evtl. bei?
Kannst du da mal gucken?
Ich hab ja auch schon ein paar Reboots gemacht, aber trotzdem immer SIMLCD...
Meine preferences:
Ja bei deinem neueren Plugin war der evtl. bei?
Kannst du da mal gucken?
Ich hab ja auch schon ein paar Reboots gemacht, aber trotzdem immer SIMLCD...
Meine preferences:
Ich glaube nicht, daß es ein extra Treiber für den Controller gibt. Laut Wiki ist das im vdr plugin integriert.
Wiki
Ich schau trotzdem gern nach, wenn Du mir sagst, wo ein Treiber liegen sollte.
Vielleicht blöde Frage, Du startest aber auch vdr und nicht vdr-devel wenn Du diese conf angepaßt hast?
/etc/vdr/plugins/plugin.graphlcd.conf
...ansonsten natürlich auch im devel Zweig entsprechend anpassen.
Nee ich starte schon vdrdevel, aber es gibt ja sinnlose Plugins, wo die conf im vdr-Pfad liegt.
Such doch bitte einfach mit find oder so nach 6963.
Mit showpic kommt dasselbe.
Muss ich nach dem Ändern der .conf irgendwie das Plugin neu starten? Da sollte ein Reboot doch reichen, oder?
Ich hab jetzt halt beide Plugins mit angepassten conf drauf.
Werde gleich mal Pins 20 verbinden, obwohl eigentlich sinnlos lt. kilroy.
Hasttest Du mal showpic mit und ohne Angabe der conf versucht?
Edit: Wie sieht Dein showpic Aufruf (inkl. Ausgabe) aus?
Nur nochmal zur Sicherheit, damit wir nicht aneinander vorbeireden.
Gibt es die Datei /etc/vdrdevel/plugins/plugin.graphlcd.conf ? Dann auch in dieser das SIMLCD durch t6963c ersetzen oder sitze ich nun auf dem Schlauch?
vdr und auch vdr-devel brauchen jeweils ihre eigenen Plugins und somit eigene conf files.
P.S.: Find findet nichts...
vdr-hh:~# showpic -c /etc/graphlcd.conf -d t6963c /var/lib/vdrdevel/plugins/graphlcd/logos/BTV_m.glcd
Unknown Controller.
Using 'simlcd' instead...
vdr-hh:~# showpic -d t6963c /var/lib/vdrdevel/plugins/graphlcd/logos/BTV_m.glcd
Unknown Controller.
Using 'simlcd' instead...
vdr-hh:~#
Ich habe beide plugin-graphlcd.conf editiert, sowohl in vdr als auch in vdrdevel.
Ich kann halt nicht beschwören, dass das Display korrekt dran ist, aber das dürfte wohl egal sein für diesen Fehler. Es leuchtet halt blau die Hintergrundbeleuchtung, die ich in der Helligkeit am Poti einstellen kann. Das AVBoard-Kontrast Poti bewirkt nix. Lt. Datenblatt soll das AVBoard ja ungef. -9V erzeugen. Ich werde wohl doch mal die -12V von der Tochterplat. anklemmen müssen.
Muss ich jetzt Pin20 am Display noch auf Masse setzen?
Vielleicht kann mir ja mal einer die beiden confs mailen, dann muss ich die nich in Win mit Textpad erzeugen bzw. eine andere conf umbenennen und Inhalt ersetzen (noch dem kopieren ;-)?
Ich habe übrigens die neuere Platinenversion und wohl auch ne Austauschröhre (und nen Widerstand), aber die funzt ja.
Anschluß so:
Günstige 240x128 GLCDs bei eBay
und Pin4+5 auf der Tochterplat. verbunden.
vdr-hh:~# cat /etc/graphlcd.conf
WaitMethod=2
WaitPriority=0
[t6963c]
Driver=t6963c
Device=/dev/parport0
Width=240
Height=128
#UpsideDown=no
Invert=yes
#RefreshDisplay=1
Wiring=Windows
FontSelect=6
#AutoMode=yes
StatusCheck=novdr-hh:~#
Alles anzeigen
Hab noch was rausgefunden:
in meiner version scheint der nur t6963 zu heissen ohne c...
vdr-hh:~# showpic -c /etc/graphlcd.conf -d t6963c -s 650 $(ls /etc/vdr/plugins/graphlcd/splash/start/*.glcd) &
[1] 2798
vdr-hh:~# ls: /etc/vdr/plugins/graphlcd/splash/start/*.glcd: Datei oder Verzeichnis nicht gefunden
Unknown Controller.
Using 'simlcd' instead...
showpic v0.1.0
showpic is a tool to show an image on a LCD.
The image must be in a special format (*.glcd).
You can create such images with the convpic tool.
Usage: showpic [-c CTR] [-p IOP | -d DEV] [-x SZX] [-y SZY] [-s Sleep] [-uie] file [more files]
-c --contr sets the controller (default: simlcd)
currenty available are:
simlcd gu140x32f gu256x64-372 gu256x64-3900 hd61830 ks0108 ks0713 sed1330 sed1520 t6963 framebuffer image
-p --port sets the port address (default: 0x378)
-d --device sets the parport device
-x --sizex sets the x-resolution (default: 240)
-y --sizey sets the y-resolution (default: 128)
-u --upside_down rotates the output by 180 degrees (default: no)
-i --invert inverts the output (default: no)
-w --wiring wiring (T6963) (0 - standard, 1 - windows, 2 - feegy, default: 0)
wiring (GU256x64-3900) (0 - standard DMA, 1 - parallel, 2 - serial, 32 - Satyr DMA, default: 0)
-f --fontsize font size (T6963) (0 - 6x8, 1 - 8x8, default: 0)
-a --automode use auto mode (T6963) (default: no)
-e --endless show all images in endless loop (default: no)
-s --sleep set sleeptime between two images [ms] (default: 100 ms)
-b --brightness set brightness for display if driver support it [%] (default: 100 %)
-t --timing set timing method (0 - usleep, 1 - nanosleep,
2 - nanosleep (sched_rr), 3 - gettimeofday,
default: 2)
You can either specify a port or a device. The output with ports is faster,
but You need root privileges.
examples: showpic -c ks0108 -x 128 -y 64 vdr-logo.glcd
showpic -c t6963 -d /dev/parport0 -x 160 -y 128 -u -i vdr-logo.glcd
showpic -c sed1520 -p 0x278 -x 128 -y 64 -u -i vdr-logo.glcd
vdr-hh:~# showpic -c /etc/graphlcd.conf -d t6963 /var/lib/vdrdevel/plugins/graph
lcd/logos/BTV_m.glcd
Unknown Controller.
Using 'simlcd' instead...
[1]+ Exit 1 showpic -c /etc/graphlcd.conf -d t6963c -s 650 $(ls /etc/vdr/plugins/graphlcd/splash/start/*.glcd)
vdr-hh:~# showpic -d /etc/graphlcd.conf -c t6963 /var/lib/vdrdevel/plugins/graphlcd/logos/BTV_m.glcd
ERROR cannot initialize cGraphLCDDevice
vdr-hh:~# showpic -c t6963 -d /dev/parport0 -x 240 -y 128 -u -i /var/lib/vdrdevel/plugins/graphlcd/logos/BTV_m.glcd
Alles anzeigen
Die letzte Zeile ergab keine Fehlermeldung mehr! Aber auch keine Displayänderungen.
Achso:
vdr-hh:~# ls -la /dev/parport0
crw-r--r-- 1 root root 99, 0 2006-04-18 15:30 /dev/parport0
vdr-hh:~#
Das findet sich noch im syslog:
Apr 18 20:28:55 vdr-hh showpic: graphlcd plugin: SIMLCD initialized.
Apr 18 20:28:55 vdr-hh showpic: graphlcd plugin: logo /var/lib/vdrdevel/plugins/graphlcd/logos/BTV_m.glcd loaded.
Apr 18 20:31:18 vdr-hh showpic: graphlcd plugin: ERROR cannot claim /etc/graphlcd.conf. Err:Inappropriate ioctl for device (cParallelPort::Init)
Apr 18 20:32:36 vdr-hh kernel: ppdev: user-space parallel port driver
Apr 18 20:32:37 vdr-hh kernel: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
Apr 18 20:32:37 vdr-hh kernel: parport0: irq 7 detected
Apr 18 20:32:37 vdr-hh showpic: graphlcd plugin: Testing ECP mode...
Apr 18 20:32:37 vdr-hh showpic: graphlcd plugin: working!
Apr 18 20:32:37 vdr-hh kernel: ppdev0: registered pardevice
Apr 18 20:32:37 vdr-hh showpic: graphlcd plugin: T6963 initialized.
Apr 18 20:32:37 vdr-hh showpic: graphlcd plugin: logo /var/lib/vdrdevel/plugins/graphlcd/logos/BTV_m.glcd loaded.
Apr 18 20:32:37 vdr-hh kernel: ppdev0: claim the port first
Apr 18 20:32:37 vdr-hh kernel: ppdev0: negotiated back to compatibility mode because user-space forgot
Apr 18 20:32:37 vdr-hh kernel: ppdev0: unregistered pardevice
Alles anzeigen
Hiermit schonmal danke an alle Helfer!
Also ich bin überfragt, einzig fällt mir auf, das Dein parport User und Gruppe root gehört. Läuft der vdr / vdr-devel unter root? Wenn ja, weiß ich nicht weiter
da bin ich nicht sicher, ich bin als root per ssh eingeloggt, aber wodrin der vdr läuft bin ich überfragt. Wie gucke ich das nach? Ich bin halt noch nicht so linuxfirm.
ok, vdrdevel läuft 2x als root.
achja, vdrdevel läuft ja als root...
Hast Du denn das Display schonmal unter Windows ausprobiert? Da haste vermutlich kein AV Board für die Spannungsversorgung und mußt z.B. auf die Netzteilspannungen zurückgreifen.
Da ich das AV Board nicht kenne, würde ich dann die Fehlerquellen soweit möglich reduzieren und ggfs. direkt an den Parallelport gehen (wenn das av board diesen nicht nur durchschleift)
Ansonsten bin ich echt überfragt
Das AVBoard schleift ihn nur durch bis auf die Kontrastspannung, die per Poti regelbar ist.
Was passiert bei euch, wenn das display abgeklemmt ist? Weil der Fehler, dass er immer simlcd nimmt, dürfte doch unabhängig von einer Verb. zum Display sein, oder guckt er nach, ob er den 6963 ansprechen kann?
Ich bekomme keinen Fehler, wenn es abgeklemmt ist (habe nur power abgezogen).
Wenn ich mein Ausgabe nach einem showpic mit Deiner von oben vergleiche, dann kann ich keinen großen Unterschied erkennen. Einzig wenn bei mir t6963c steht, ist bei Dir ppdev0 angegeben
Apr 18 22:50:17 vdr showpic: t6963c: Testing ECP mode...
Apr 18 22:50:17 vdr showpic: t6963c: working!
Apr 18 22:50:17 vdr showpic: t6963c: T6963 initialized.
Apr 18 22:50:17 vdr kernel: ppdev0: registered pardevice
Apr 18 22:50:17 vdr kernel: ppdev0: negotiated back to compatibility mode because user-space forgot
Apr 18 22:50:17 vdr kernel: ppdev0: unregistered pardevice
Apr 18 22:50:23 vdr showpic: t6963c: Testing ECP mode...
Apr 18 22:50:23 vdr showpic: t6963c: working!
Apr 18 22:50:23 vdr showpic: t6963c: T6963 initialized.
Apr 18 22:50:23 vdr showpic: glcdgraphics: image /var/lib/vdr/plugins/graphlcd/logos/KABEL 1_l.glcd loaded.
Apr 18 22:50:23 vdr kernel: ppdev0: registered pardevice
Apr 18 22:50:23 vdr kernel: ppdev0: claim the port first
Apr 18 22:50:23 vdr kernel: ppdev0: negotiated back to compatibility mode because user-space forgot
Apr 18 22:50:23 vdr kernel: ppdev0: unregistered pardevice
Alles anzeigen
Nach allem würde ich zu einem Hardwareproblem tendieren.
Das syslog sieht aber auch etwas merkwürdig aus. Du hast vdr beim Test mit showpic vorher
gestoppt?
ZitatDas syslog sieht aber auch etwas merkwürdig aus. Du hast vdr beim Test mit showpic vorher gestoppt?
Nein, das stand nirgends, hatte eben beim Basteln aber eh eher kurze und schlüssige Erlebnisse bzw. eins und zwar ein rauchiges...
Naja, hoffe es hat nicht das Netzteil und das Display gerafft. Mir war ein Draht vom Tochterboard abgerissen (braun) und den hatte ich eben wieder angelötet in Gewohnheit an GND... Die Drähte sind mantelfrei, der ist heruntergetropft, hatte zufällig ne Antistatiktüte untergelegt.
Ist wohl mindestens ein Hw-Prob, hatte vorher festgestellt, dass die -12V aus irgendeinem unerfindlichen Grund nicht ausm AVBoard kamen und deshalb die -12V umgeklemmt auf die Tochterplat. und dann gesehn, dass der Draht ab war...
Aber im Ernst: Kann der graphlcd-Trb. bzw. das Plugin erkennen, ob dieser Controller im Display ein bzw. mit dem parport verbunden ist?
Hatte die lange conf eben vorher noch erfolglos getestet.
Wenn man das Flachbandkabel zum AVBoard geglässt, dann sieht das Display genauso aus. Das blaue ist also nur die Hintergrundbel. leider
Einige Kontroller bieten die Möglichkeit, nicht zur Daten zu empfangen, sondern auch
zurückzusenden. Ob oder inwieweit dieses beim T6963 genutzt wird kann ich Dir nicht
sagen. IIRC lief mein früheres Display (mit hd61830) auch im SPP Modus der parallelen
Schnitstelle. Andere Kontroller benötigen wohl EPP o.ä. für die bidirektionale
Kommunikation.
Für die nächsten Tests mit showpic bitte den vdr vorher stoppen und mal mittels
kontrollieren, ob auch wirklich keiner mehr läuft.
@ SurfaceCleanerZ
Wenn ich mich recht erinnere, erzeugt das AV-Board keine negative Spannung! (zumindest bis Rev. 1.3)
Ich hatte STB mal in einem anderen Fall gefragt. Das Display muß die negative Spannung selber erzeugen und an einem Pin ausgeben und an einem anderen Pin wieder aufnehmen. Dazwischen wird dann der Poti des AV-Boards geschaltet. Ich selber habe im Moment ein solches Display verbaut (KS108 Controller), jedoch nicht am AV-Board angeschlossen.
Ich fand die Anleitung des AV-Boards diesbezüglich ein bisschen irreführend. Ich denke, du wirst nicht drum herum kommen, die -12V von der Tochterplatine oder vom ATX Netzteil zu beziehen.
@ all
Hat jemand mal die -12V bereits vom ATX Netzteil abgezwackt? Wie macht man das am geschicktesten?
Max
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!