graphlcd-base, touchcol branch: Problem beim Übersetzen für das Pearl Display

xheinrich · 12. Januar 2015

Guten Morgen,

versuche gerade, einen VDR auf den Raspberry Pi aufzusetzen. Den VDR 2.1.6 aus den Quellen komiliert nach der Anleitung von im vdr-wiki. Das geht auch soweit einschließlich einiger Plugins.
Nun möchte ich das PEARL Display, das hier schon ne Weile geflasht rumliegt am VDR betreiben. Habe die aktuelle Version aus dem git gezogen

Code

git clone git://projects.vdr-developer.org/graphlcd-base.git -b touchcol graphlcd-base.git.touchcol

Nach dem Compilerdurchlauf kommt nach dem Starten des VDR ein Fehler:

Code

graphlcd plugin: ERROR: Failed creating display object ax206dpf

Bin der Sache nachgegangen. In der Make.config war das HAVE_DRIVER_AX206DPF=1 noch nicht auskommentiert. Also auskommentiert, make clean, make all, make install. Das brachte leider keine Änderung!
Ich habe den Compiler-Durchlauf in eine Datei schreiben lassen:

Code

make[1]: Entering directory '/usr/local/src/graphlcd-base.git.touchcol/glcdgraphics'
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE -DHAVE_FREETYPE2 -I/usr/include/freetype2 bitmap.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE -DHAVE_FREETYPE2 -I/usr/include/freetype2 common.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE -DHAVE_FREETYPE2 -I/usr/include/freetype2 font.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE -DHAVE_FREETYPE2 -I/usr/include/freetype2 glcd.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE -DHAVE_FREETYPE2 -I/usr/include/freetype2 image.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE -DHAVE_FREETYPE2 -I/usr/include/freetype2 imagefile.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE -DHAVE_FREETYPE2 -I/usr/include/freetype2 pbm.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE -DHAVE_FREETYPE2 -I/usr/include/freetype2 extformats.c
g++ -g -O2 -Wall -Woverloaded-virtual -fPIC  -shared bitmap.o common.o font.o glcd.o image.o imagefile.o pbm.o extformats.o -L/usr/lib/arm-linux-gnueabihf -lfreetype -lz -Wl,-soname="libglcdgraphics.so.2" -o libglcdgraphics.so.2.1.0
ln -sf libglcdgraphics.so.2.1.0 libglcdgraphics.so
make[1]: Leaving directory '/usr/local/src/graphlcd-base.git.touchcol/glcdgraphics'
make[1]: Entering directory '/usr/local/src/graphlcd-base.git.touchcol/glcddrivers'
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  common.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  config.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  driver.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  drivers.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  port.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  simlcd.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  framebuffer.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  gu140x32f.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  gu256x64-372.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  gu256x64-3900.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  hd61830.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  ks0108.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  image.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  sed1330.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  sed1520.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  t6963c.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  noritake800.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  serdisp.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  avrctl.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  g15daemon.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  network.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  gu126x64D-K610A4.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC  -c -D_GNU_SOURCE  dm140gink.c
g++ -g -O2 -Wall -Woverloaded-virtual -fPIC  -shared common.o config.o driver.o drivers.o port.o simlcd.o framebuffer.o gu140x32f.o gu256x64-372.o gu256x64-3900.o hd61830.o ks0108.o image.o sed1330.o sed1520.o t6963c.o noritake800.o serdisp.o avrctl.o g15daemon.o network.o gu126x64D-K610A4.o dm140gink.o  -ldl -lpthread -Wl,-soname="libglcddrivers.so.2" -o libglcddrivers.so.2.1.0
ln -sf libglcddrivers.so.2.1.0 libglcddrivers.so
make[1]: Leaving directory '/usr/local/src/graphlcd-base.git.touchcol/glcddrivers'
make[1]: Entering directory '/usr/local/src/graphlcd-base.git.touchcol/glcdskin'
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC -I.. -c -D_GNU_SOURCE -DHAVE_FONTCONFIG  cache.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC -I.. -c -D_GNU_SOURCE -DHAVE_FONTCONFIG  config.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC -I.. -c -D_GNU_SOURCE -DHAVE_FONTCONFIG  display.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC -I.. -c -D_GNU_SOURCE -DHAVE_FONTCONFIG  font.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC -I.. -c -D_GNU_SOURCE -DHAVE_FONTCONFIG  function.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC -I.. -c -D_GNU_SOURCE -DHAVE_FONTCONFIG  object.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC -I.. -c -D_GNU_SOURCE -DHAVE_FONTCONFIG  parser.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC -I.. -c -D_GNU_SOURCE -DHAVE_FONTCONFIG  skin.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC -I.. -c -D_GNU_SOURCE -DHAVE_FONTCONFIG  string.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC -I.. -c -D_GNU_SOURCE -DHAVE_FONTCONFIG  type.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC -I.. -c -D_GNU_SOURCE -DHAVE_FONTCONFIG  variable.c
g++  -g -O2 -Wall -Woverloaded-virtual -fPIC -I.. -c -D_GNU_SOURCE -DHAVE_FONTCONFIG  xml.c
g++ -g -O2 -Wall -Woverloaded-virtual -fPIC -shared cache.o config.o display.o font.o function.o object.o parser.o skin.o string.o type.o variable.o xml.o -L../glcdgraphics -lglcdgraphics -L../glcddrivers -lglcddrivers -lfontconfig -Wl,-soname="libglcdskin.so.2" -o libglcdskin.so.2.1.0
ln -sf libglcdskin.so.2.1.0 libglcdskin.so
make[1]: Leaving directory '/usr/local/src/graphlcd-base.git.touchcol/glcdskin'
make[1]: Entering directory '/usr/local/src/graphlcd-base.git.touchcol/tools'
make[2]: Entering directory '/usr/local/src/graphlcd-base.git.touchcol/tools/convpic'
g++  -g -O2 -Wall -Woverloaded-virtual  -c -D_GNU_SOURCE -I../../ convpic.c
g++ -g -O2 -Wall -Woverloaded-virtual  -rdynamic convpic.o  -L../../glcdgraphics/ -lglcdgraphics -lstdc++ -o convpic
make[2]: Leaving directory '/usr/local/src/graphlcd-base.git.touchcol/tools/convpic'
make[2]: Entering directory '/usr/local/src/graphlcd-base.git.touchcol/tools/crtfont'
g++  -g -O2 -Wall -Woverloaded-virtual  -c -D_GNU_SOURCE -I../../ crtfont.c
g++ -g -O2 -Wall -Woverloaded-virtual  -rdynamic crtfont.o -L../../glcdgraphics/ -lglcdgraphics -lstdc++ -o crtfont
make[2]: Leaving directory '/usr/local/src/graphlcd-base.git.touchcol/tools/crtfont'
make[2]: Entering directory '/usr/local/src/graphlcd-base.git.touchcol/tools/genfont'
g++  -g -O2 -Wall -Woverloaded-virtual  -c -D_GNU_SOURCE -I../../ `freetype-config --cflags` genfont.c
g++ -g -O2 -Wall -Woverloaded-virtual  -rdynamic genfont.o -L../../glcdgraphics/ `freetype-config --libs` -lglcdgraphics -lstdc++ -o genfont
make[2]: Leaving directory '/usr/local/src/graphlcd-base.git.touchcol/tools/genfont'
make[2]: Entering directory '/usr/local/src/graphlcd-base.git.touchcol/tools/showpic'
g++  -g -O2 -Wall -Woverloaded-virtual  -c -D_GNU_SOURCE -I../../ showpic.c
g++ -g -O2 -Wall -Woverloaded-virtual  -rdynamic showpic.o  -L../../glcdgraphics/ -L../../glcddrivers/ -lglcdgraphics -lglcddrivers -lstdc++ -o showpic
make[2]: Leaving directory '/usr/local/src/graphlcd-base.git.touchcol/tools/showpic'
make[2]: Entering directory '/usr/local/src/graphlcd-base.git.touchcol/tools/showtext'
g++  -g -O2 -Wall -Woverloaded-virtual  -c -D_GNU_SOURCE -I../../ showtext.c
g++ -g -O2 -Wall -Woverloaded-virtual  -rdynamic showtext.o  -L../../glcdgraphics/ -L../../glcddrivers/ -lglcdgraphics -lglcddrivers -lstdc++ -o showtext
make[2]: Leaving directory '/usr/local/src/graphlcd-base.git.touchcol/tools/showtext'
make[2]: Entering directory '/usr/local/src/graphlcd-base.git.touchcol/tools/lcdtestpattern'
g++  -g -O2 -Wall -Woverloaded-virtual  -c -D_GNU_SOURCE -I../../ lcdtestpattern.c
g++ -g -O2 -Wall -Woverloaded-virtual  -rdynamic lcdtestpattern.o  -L../../glcdgraphics/ -L../../glcddrivers/ -lglcddrivers -lglcdgraphics -lstdc++ -o lcdtestpattern
make[2]: Leaving directory '/usr/local/src/graphlcd-base.git.touchcol/tools/lcdtestpattern'
make[1]: Leaving directory '/usr/local/src/graphlcd-base.git.touchcol/tools'

Alles anzeigen

Das sieht alles normal aus, nur dass der Treiber für das ax206dpf nicht eingebunden wird. Ich bin jetzt mit meinem Latein am Ende. Weiß jemand Rat?

SurfaceCleanerZ · 12. Januar 2015

Hi,
Tut der Treiber denn generell? Z. B. mit image oder dummy Plugin?
Fehlen evtl. Noch der Treiber selbst? Was passiert bei showpic?

Gesendet von meinem HTC One mit Tapatalk 2

xheinrich · 13. Januar 2015

Also grundsätzlich geht das offensichtlich, wenn ich showpic oder showtext aufrufe kommt keine Fehlermeldung. Aber natürlich auch kein Ergebnis auf dem LCD, weil der Treiber dafür fehlt.
Unter dem Verzeichnis glcddrivers sind die Quelltexte ax206dpf.c und.h vorhanden. Ich verstehe nicht, warum er die nicht mit übersetzt...

SurfaceCleanerZ · 13. Januar 2015

Hi,
Ich meinte dass du mal mit einem anderen Treiber testest. Gibt ja mehrere Dummy Treiber.

Gesendet von meinem HTC One mit Tapatalk 2

olebowle · 13. Januar 2015

Ich vermute da ist beim Auskommentieren etwas schief gegangen. In der Ausgabe beim Kompilieren von den glcddrivers sollte ein -DHAVE_DRIVER_AX206DPF erscheinen. Das ist bei dir aber nicht der Fall.

EDIT: Bzw. fehlt bei dir die libusb? Sprich liefert folgendes Kommando keine 1 zurück?

Code

pkg-config --exists libusb && echo 1

xheinrich · 13. Januar 2015

Zitat von SurfaceCleanerZ

Hi,
Ich meinte dass du mal mit einem anderen Treiber testest. Gibt ja mehrere Dummy Treiber.

Gesendet von meinem HTC One mit Tapatalk 2

Ich hoffe, ich hab das richtig verstanden. Als Treiber mal [image] ausgewählt und den vdr gestartet. Die images im /tmp - Verzeichnis schauen so aus, wie ich das erwartet hätte. Also grundsätzlich geht's.

xheinrich · 13. Januar 2015

Zitat von olebowle
Ich vermute da ist beim Auskommentieren etwas schief gegangen. In der Ausgabe beim Kompilieren von den glcddrivers sollte ein -DHAVE_DRIVER_AX206DPF erscheinen. Das ist bei dir aber nicht der Fall.

EDIT: Bzw. fehlt bei dir die libusb? Sprich liefert folgendes Kommando keine 1 zurück?
Code
pkg-config --exists libusb && echo 1

ergibt bei mir keine bzw. eine leere Rückgabe. Das (debian) Paket libusb-1.0-0 ist aber installiert?

olebowle · 13. Januar 2015

Da wird es bei Debian sicherlich ein libusb-dev Paket geben.

xheinrich · 13. Januar 2015

Zitat von olebowle

Da wird es bei Debian sicherlich ein libusb-dev Paket geben.

Gibt's. Habe ich installiert und danach make clean, make. Macht keinen Unterschied. Das 'Modul für ax206dpf wird nicht compiliert???
Muss ich mich jetzt durch allle Dateien quälen und das per Hand ändern, oder was kann ich machen?
Mich wundert es auch, dass ich scheinbar der erste bin, der das Problem hat. Den Display-Typ gibt es ja schon lange nicht mehr, die Probleme hätten früher auftauchen sollen...

olebowle · 13. Januar 2015

Und du hast das HAVE_DRIVER_AX206DPF=1 immer noch auskommentiert nehme ich an?

libusb-dev hätte eigentlich eine libusb.pc installieren sollen: https://packages.debian.org/wheezy/amd64/libusb-dev/filelist.
Damit sollte das Kommando von oben auch 1 liefern. Ich bin hier allerdings nicht der Debian Experte.

Du kannst natürlich auch Zeile 29 und 43 aus glcddrivers/Makefile löschen: http://projects.vdr-developer.…/glcddrivers/Makefile#L29.
Ist ein bisschen ein Hack, aber zum Testen wird es wohl gehen.

glotzipapa · 14. Januar 2015

Mich wundert, dass der Build überhaupt durchläuft. Die Parallelport-Displaytreiber werden gebaut und der Raspi hat ja keinen. Bei mir ist der Build (OpenEmbedded) an der Stelle abgebrochen. Ich habe mir einen Patch basteln müssen:

https://github.com/realglotzi/…move-legacy-devices.patch

BTW: Kernel 3.12 hat bei mir nicht gut funktioniert. Es gab immer wieder Hänger, wo es wohl Probleme mit dem USB gab. Erst seit ich auf 3.18 bin ist das weg. Außerdem ist der Betrieb des Display ziemlich teuer in Sachen Performance. ich lasse meine Raspis daher mit 1GHz laufen.

xheinrich · 14. Januar 2015

Zitat von olebowle

Und du hast das HAVE_DRIVER_AX206DPF=1 immer noch auskommentiert nehme ich an?

libusb-dev hätte eigentlich eine libusb.pc installieren sollen: https://packages.debian.org/wheezy/amd64/libusb-dev/filelist.
Damit sollte das Kommando von oben auch 1 liefern. Ich bin hier allerdings nicht der Debian Experte.

Du kannst natürlich auch Zeile 29 und 43 aus glcddrivers/Makefile löschen: http://projects.vdr-developer.…/glcddrivers/Makefile#L29.
Ist ein bisschen ein Hack, aber zum Testen wird es wohl gehen.

Jetzt hab ich das endlich kapiert, warum Du dauernd auf dem lsusb herumreitest (Makefiles durchgesehen).
Das Raspbian ist offensichtlich eine ziemlich madige Abwandlung von Debian. Nach der Installation des dev-Pakets haben die Dateien z.T andere Namen als in der Debian Dateiliste angegeben. Für den Raspi gilt natürlich der Link https://packages.debian.org/wheezy/armhf/libusb-dev/filelist , weil arm - Prozessor. Nomen est omen? Manche Dateien fehlen ganz, z.B. usb.h - häh? Bei einem dev-Paket???

Hatte anfangs Softlinks mit passenden Namen gesetzt. Das hat so natürlich keinen Sinn, da wird man nicht fertig. Habe mir das originale Paket geholt und installiert.

Code

wget http://ftp.de.debian.org/debian/pool/main/libu/libusb/libusb-dev_0.1.12-20+nmu1_armhf.deb
dpkg -i libusb-dev_0.1.12-20+nmu1_armhf.deb

Dann lief der Compiler ohne Fehler durch. Allerdings habe ich jetzt Probleme mit der DVB-S Karte (ne alte TT 2400). Wenn ich die anschließe, kommt beim booten

Code

Jan 14 16:43:36 raspberrypi kernel: [  518.167622] dvb-usb: found a 'Technotrend TT-connect S-2400' in warm state.
Jan 14 16:43:36 raspberrypi kernel: [  518.168328] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
Jan 14 16:43:36 raspberrypi kernel: [  518.168546] DVB: registering new adapter (Technotrend TT-connect S-2400)
Jan 14 16:43:37 raspberrypi kernel: [  518.199089] Unable to handle kernel NULL pointer dereference at virtual address 00000004
Jan 14 16:43:38 raspberrypi kernel: [  518.212438] pgd = da3e8000
Jan 14 16:43:38 raspberrypi kernel: [  518.220131] [00000004] *pgd=00000000
Jan 14 16:43:38 raspberrypi kernel: [  518.228806] Internal error: Oops: 5 [#1] PREEMPT ARM

usw, zwischendurch auch mal ein oder mehrere

Code

Jan 14 16:32:28 raspberrypi udevd[304]: timeout: killing '/sbin/modprobe -b usb:v2013p0258d0100dc00dsc00dp00icFFisc00ip00in00' [2207]

Scheinbar stimmt was mit der USB-Hardware nicht, oder es ist eine miese USB-Implementation. Gehört aber nicht mehr hierher. Dir in jedem Fall vielen Dank, denn das ursprüngliche Poblem ist gelöst.

xheinrich · 14. Januar 2015

Zitat von glotzipapa

BTW: Kernel 3.12 hat bei mir nicht gut funktioniert. Es gab immer wieder Hänger, wo es wohl Probleme mit dem USB gab. Erst seit ich auf 3.18 bin ist das weg. Außerdem ist der Betrieb des Display ziemlich teuer in Sachen Performance. ich lasse meine Raspis daher mit 1GHz laufen.

Sieht so aus, als hätte ich auch USB-Probleme....
Der 3.12er ist halt der aktuelle auf dem Raspi. Hast du den 3.18er Kernel selber gebaut? Gibt's da irgendwo ne Anleitung im Netz?

glotzipapa · 15. Januar 2015

Zitat von xheinrich

Sieht so aus, als hätte ich auch USB-Probleme....

Also USB-DVB und das DPF kannst wahrscheinlich vergessen. Der Raspi ist ja nicht mal in der Lage eine USB-Soundkarte vernünftig zu verwenden. Ein aktiver USB-Hub ist in jedem Fall Pflicht.

Zitat von xheinrich

Der 3.12er ist halt der aktuelle auf dem Raspi. Hast du den 3.18er Kernel selber gebaut? Gibt's da irgendwo ne Anleitung im Netz?

3.12. ist der Standard-Kernel bei Raspbian. Es gibt aber noch eine Welt außerhalb und wie ich geschrieben habe (s. auch meine Signatur) benutze ich Openembedded/Yocto und da wird *alles* selbst gebaut.

xheinrich · 15. Januar 2015

Zitat

Also USB-DVB und das DPF kannst wahrscheinlich vergessen. Der Raspi ist
ja nicht mal in der Lage eine USB-Soundkarte vernünftig zu verwenden.
Ein aktiver USB-Hub ist in jedem Fall Pflicht.

Der ist bei mir standardmäßig dran, da mir das Leistungsproblem schon bekannt war. Selbst wenn ich dort nen stinkenormalen DVB-T Stick einstecke, wird erstmal der Bildschirm schwarz und dann bekomme ich einen Seg Fault. Ich denke da stimmt generell was nicht im USB-System vom Raspi.

Zitat

3.12. ist der Standard-Kernel bei Raspbian. Es gibt aber noch eine Welt
außerhalb und wie ich geschrieben habe (s. auch meine Signatur) benutze
ich Openembedded/Yocto und da wird *alles* selbst gebaut

Hab Deine Signatur nicht beachtet, sorry! Ich werde mir das mal anschauen. Die Stabilität von dem Raspbian ist jedenfalls bis jetzt ziemlich mies, das kann man für Systeme, die durchlaufen sollen, eigentlich nicht gebrauchen. Eher so ein Bastel-Computer...

xheinrich · 17. Januar 2015

Noch ein Nachtrag falls andere geplagte Raspberry-Nutzer hier mitlesen:

Yocto habe ich mir angesehen, ist Geschmackssache. Ich komme von Debian und da ist manches anders. Support ist sicher auch nicht so gut, weil weniger Nutzer.
Eine vergleichsweise noch schmerzfreie Lösung ist die Installation eines neuen, kompilierten Kernels, wie er von einem Herrn Mace Moneta bereitgestellt wird. Den zum Zeitpunkt, wo ich das schreibe, aktuellen Kernel findet man hier:

Code

https://plus.google.com/s/mace moneta raspberrypi 3.18

(Irgendwie kann ich den Link nicht als Link einbinden?) in der dropbox des netten Herrn.
Vor dem Auspacken sollte man den laufenden Kernel sichern

Code

cp /boot/kernel.img /boot/kernel.img.old

falls etwas schief geht. Die Libraries werden nach /usr/lib/modules entpackt. Unter Raspbian müssen sie noch an den richtigen Ort /lib/modules umkopiert bzw. verschoben werden.
Mein Raspi hat ordentlich gebootet und nach einem Hotplug auch schön die neue PCTV 461e erkannt und initialisiert. Da gab es keinen Seg-Fault wie früher. Kann jedem nur zuraten, den Raspi so zu updaten.

Aber jetzt wird's arg off topic und ich höre hier auf.

graphlcd-base, touchcol branch: Problem beim Übersetzen für das Pearl Display

Jetzt mitmachen!

Teilen

Tags