In der graphlcd.conf eher so:
---
Options=PARANOIA=off
---
aber "l4m132c_tool" wertet die graphlcd.conf nicht aus. Das graphlcd Plugin tuts.
cu
In der graphlcd.conf eher so:
---
Options=PARANOIA=off
---
aber "l4m132c_tool" wertet die graphlcd.conf nicht aus. Das graphlcd Plugin tuts.
cu
Ah jetzt geht's, danke!!!
Fehlt nur noch die Anpassung für das l4m132c Tool bei mir, oder übersehe ich da wieder was?
nope. nix uebersehen. hatte ich tatsaechlich vergessen.
ist inzw. nachgereicht.
zusaetzliche option bei l4m132c_tool:
-y disable libusb paranoia check on linux-based systems
EDIT: s/l4m132c/l4m132c_tool/
Herzlichen Dank wastl.
Ich habe übrigens bei Verwendung von libusb ähnlich wie bei HID ab und an immer noch das Problem
dass das Display einfriert. Aber lange nicht so häufig wie bei HID, es kommt ab und an mal
vor. Wenn ich es mal wieder habe, werde ich mal Logs zur Verfügung stellen. Ich hoffe du findest dann
mal Zeit dem Problem auf die Schliche zu kommen. Aber wie gesagt bei HID viel häufiger, mit libusb
bin ich viel glücklicher, da das Display auch viel schneller aufbaut.
Danke und LG Urknall
wie laeuft bei den diversen xbmc+vdr-konglomeraten eigentlich das zusammenspiel (kenne zwar beide, aber jew. nur unabhaengig vom anderen).
zb bei yavdr: laeuft da hauptsaechlich xbmc und vdr wird aus xbmc heraus gestartet oder vdr startet xbmc?
laufen dann beide gleichzeitig? (dh kann vdr aufnehmen waehrend man mit xbmc zb. fotos / filme schaut?) oder pausiert jew. eines davon?
zb bei yavdr: laeuft da hauptsaechlich xbmc und vdr wird aus xbmc heraus gestartet oder vdr startet xbmc?
laufen dann beide gleichzeitig? (dh kann vdr aufnehmen waehrend man mit xbmc zb. fotos / filme schaut?) oder pausiert jew. eines davon?
Also bei yaVDR starten wir prinzipiell den VDR und dann je nach Frontendeinstellung zusätzlich das gewünschte VDR-Frontend (xine, vdr-sxfe) oder XBMC. Beim nachträglichen Start von XBMC läuft der VDR ebenfalls weiter (ist auch deshalb sinnvoll, da wir über das xvdr-plugin des VDRs Live-TV und Aufnahmen des VDR für XBMC bereitstellen. Für den VDR wird die Reaktion auf die Fernbedienung deaktiviert, sobald XBMC gestartet wird. Für das softhddevice müssen die entsprechenden Skripte zum suspenden der Ausgabe noch entwickelt werden.
Graphlcd wird davon aktuell nicht beeinflusst, man sieht also was der VDR da im Hintergrund tut (wobei es sicher auch ganz interessant wäre das Display auf Wunsch auch für XBMC nutzen zu können).
Graphlcd wird davon aktuell nicht beeinflusst, man sieht also was der VDR da im Hintergrund tut (wobei es sicher auch ganz interessant wäre das Display auf Wunsch auch für XBMC nutzen zu können).
Geht ja, einfach graphlcd deaktivieren und per lcdproc aufs Display ausgeben lassen (per glcdlib oder serdisplib Ausgabetreiber als Textdisplayemulation). So mache ich das aktuell mit freevo.
Alternativ könnte man auch nen xbmc/freevo Plugin schreiben was seine "Displayausgaben" per dbus an graphlcd schickt (anstatt zu lcdproc) und so xbmc/freevo ihre Ausgabe auf dem schönen Graphlcd Grafik-Display ausgeben können. Braucht dann nur ne Unterstützung vom Skin.
cu
Es ist gerade eben wieder passiert, Display eingefroren:
Apr 8 21:10:24 yavdr vdr: glcdgraphics: open /var/lib/vdr/plugins/graphlcd/logos/channels/KABEL_1_CLASSIC_m.glcd failed (cGLCDFile::Load).
Apr 8 21:10:24 yavdr vdr: glcdgraphics: image /var/lib/vdr/plugins/graphlcd/skins/l4m132c/symbols/scrambled_small.pbm loaded.
Apr 8 21:10:24 yavdr vdr: INFO: graphlcd: successfully loaded image 'symbols/scrambled_small.pbm'
Apr 8 21:10:24 yavdr vdr: [4202] TS buffer on device 2 thread started (pid=3613, tid=4202)
Apr 8 21:10:24 yavdr vdr: [4203] logger stats thread started (pid=3613, tid=4203)
Apr 8 21:10:24 yavdr vdr: [4204] logger 1/0 filter thread started (pid=3613, tid=4204)
Apr 8 21:10:25 yavdr vdr: [4201] [xine..put] Detected video size 480x576
Apr 8 21:10:30 yavdr vdr: [3613] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Apr 8 21:10:34 yavdr vdr: [3613] [xine..put] OSD bandwidth: 290601 bytes/s (2270 kbit/s)
Apr 8 21:10:35 yavdr vdr: [3613] [xine..put] OSD bandwidth: 193706 bytes/s (1513 kbit/s)
Apr 8 21:10:37 yavdr vdr: [3613] [xine..put] OSD bandwidth: 198281 bytes/s (1549 kbit/s)
Apr 8 21:10:39 yavdr vdr: [3613] [xine..put] OSD bandwidth: 208474 bytes/s (1628 kbit/s)
Apr 8 21:10:55 vdr: last message repeated 2 times
Apr 8 21:10:55 yavdr vdr: [3613] [xine..put] OSD bandwidth: 196639 bytes/s (1536 kbit/s)
Apr 8 21:11:00 yavdr vdr: [3613] [xine..put] OSD bandwidth: 187207 bytes/s (1462 kbit/s)
Apr 8 21:11:02 yavdr vdr: [3613] [xine..put] OSD bandwidth: 182488 bytes/s (1425 kbit/s)
Apr 8 21:11:05 yavdr vdr: [3613] [xine..put] OSD bandwidth: 192921 bytes/s (1507 kbit/s)
Apr 8 21:11:06 yavdr vdr: [3613] [xine..put] OSD bandwidth: 184853 bytes/s (1444 kbit/s)
Apr 8 21:11:07 yavdr vdr: [3613] [xine..put] OSD bandwidth: 181671 bytes/s (1419 kbit/s)
Apr 8 21:11:09 yavdr vdr: [3613] [xine..put] OSD bandwidth: 188635 bytes/s (1473 kbit/s)
Apr 8 21:11:12 yavdr vdr: [3613] [xine..put] OSD bandwidth: 187284 bytes/s (1463 kbit/s)
Apr 8 21:11:13 yavdr vdr: [3613] [xine..put] OSD bandwidth: 164470 bytes/s (1284 kbit/s)
Apr 8 21:11:15 yavdr vdr: [3613] [xine..put] OSD bandwidth: 148616 bytes/s (1161 kbit/s)
Apr 8 21:11:31 yavdr vdr: [3613] [xine..put] OSD bandwidth: 205100 bytes/s (1602 kbit/s)
Apr 8 21:11:34 yavdr vdr: SDCONNusb_commit(): L4M_E-5i/LCD commiting buffer failed, error: Die Ressource ist zur Zeit nicht verfügbar
Apr 8 21:12:39 vdr: last message repeated 13 times
Apr 8 21:12:44 yavdr vdr: SDCONNusb_commit(): L4M_E-5i/LCD commiting buffer failed, error: Die Ressource ist zur Zeit nicht verfügbar
Apr 8 21:12:45 yavdr vdr: [3613] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Apr 8 21:12:49 yavdr vdr: SDCONNusb_commit(): L4M_E-5i/LCD commiting buffer failed, error: Die Ressource ist zur Zeit nicht verfügbar
Apr 8 21:12:50 yavdr vdr: [3613] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Apr 8 21:12:54 yavdr vdr: SDCONNusb_commit(): L4M_E-5i/LCD commiting buffer failed, error: Die Ressource ist zur Zeit nicht verfügbar
Apr 8 21:12:59 yavdr vdr: SDCONNusb_commit(): L4M_E-5i/LCD commiting buffer failed, error: Die Ressource ist zur Zeit nicht verfügbar
Alles anzeigen
Vielleicht kannst du damit ja schon was anfangen und hast eine Idee, ansonsten würde ich mich
über Instruktionen freuen, wie wir dem Problem genauer auf die Spur kommen können.
LG Urknall
nicht wirklich eine ahnung.
aendere mal in serdisp_connect_usb.c folgendes: ca zeile 1070:
von
#if 0
int ii;
fprintf(stderr, "ep: 0xx length: %d: ", usbitems->out_ep, usbitems->streampos);
for (ii = 0; ii < usbitems->streampos; ii++)
fprintf(stderr, "x ", usbitems->stream[ii]);
fprintf(stderr, "\n");
#endif
sd_error(SERDISP_ERUNTIME, "%s(): L4M_E-5i/LCD commiting buffer failed, error: %s", __func__, strerror(errno));
auf
/*#if 0*/
int ii;
fprintf(stderr, "ep: 0xx length: %d: ", usbitems->out_ep, usbitems->streampos);
for (ii = 0; ii < usbitems->streampos; ii++)
fprintf(stderr, "x ", usbitems->stream[ii]);
fprintf(stderr, "\n");
/*#endif*/
sd_error(SERDISP_ERUNTIME, "%s(): L4M_E-5i/LCD commiting buffer failed, error: %s", __func__, strerror(errno));
sd_runtimeerror = 1;
ACHTUNG: der bloede editor macht hier '% 0 2 x' (leerzeichen hinzugefuegt, damit es hier nicht auch verwurschtet wird) zu einem nicht darstellbaren sonderzeichen oder so.
es ist aber ohnedies nur das #if/#endif auszukommentieren und die zeile mit sd_runtimeerror = 1; hinzuzufuegen.
das sollte den zuletzt geschriebenen datenstrom - bevor das display sich verabschiedet - hinausschreiben.
das sd_runtimeerror bewirkt, dass nix weiter mehr versucht wird (und somit das log nicht zugemuellt wird).
das ganze schreibt auf stderr hinaus! => daher vdr entsprechend starten (von command line aus oder so)
oder ansonsten folgendes (dann wird das sauber ins /var/log/messages geloggt) und du kannst vdr wie gewohnt starten:
/*#if 0*/
int ii;
char buf[usbitems->streampos * 3 + 1];
sd_error(SERDISP_ERUNTIME, "***** ep: 0x%02x length: %d: ", usbitems->out_ep, usbitems->streampos);
for (ii = 0; ii < usbitems->streampos; ii++)
sprintf(&buf[ii*3], "%02x ", usbitems->stream[ii]);
buf[usbitems->streampos * 3] = '\0';
sd_error(SERDISP_ERUNTIME, "***** debug: %s", buf);
/*#endif*/
sd_error(SERDISP_ERUNTIME, "%s(): L4M_E-5i/LCD commiting buffer failed, error: %s", __func__, strerror(errno));
sd_runtimeerror = 1;
Alles anzeigen
achtung: ungetestet!
EDIT: portal-editor hatte code-text massakriert
Servus,
hatte in letzter Zeit viel um die Ohren und erst jetzt wieder Zeit das Thema weiter zu verfolgen:
Apr 15 20:38:57 yavdr vdr: ***** ep: 0x04 length: 60:.
Apr 15 20:38:57 yavdr vdr: ***** debug: 17 39 27 38 00 00 ffffffffffffffffff00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Apr 15 20:38:57 yavdr vdr: SDCONNusb_commit(): L4M_E-5i/LCD commiting buffer failed, error: Die Ressource ist zur Zeit nicht verfügbar
Apr 15 20:39:08 yavdr vdr: ***** ep: 0x04 length: 1:.
Apr 15 20:39:08 yavdr vdr: ***** debug: 54.
Apr 15 20:39:08 yavdr vdr: SDCONNusb_commit(): L4M_E-5i/LCD commiting buffer failed, error: Die Ressource ist zur Zeit nicht verfügbar
Apr 15 20:39:18 yavdr vdr: ***** ep: 0x04 length: 1:.
Apr 15 20:39:18 yavdr vdr: ***** debug: 54.
Apr 15 20:39:18 yavdr vdr: SDCONNusb_commit(): L4M_E-5i/LCD commiting buffer failed, error: Die Ressource ist zur Zeit nicht verfügbar
Apr 15 20:39:28 yavdr vdr: ***** ep: 0x04 length: 1:.
Apr 15 20:39:28 yavdr vdr: ***** debug: 54.
...
Alles anzeigen
Hier mal der erste Freeze von heute, ich werde das weiter beobachten und weitere Debugs liefern, falls sie unterschiedlich sein sollten...
LG Urknall
Apr 17 20:12:57 yavdr vdr: ***** ep: 0x04 length: 60:
Apr 17 20:12:57 yavdr vdr: ***** debug: 17 38 2a 38 00 00 fff1f 00 00 fff1f 00 00 00 00 00 00 fff1f 00 00 fff1f 00 00 fff1f 00 00 00 00 fff1f 00 00 00 00 00 00 fff1f 00 00 fff1f 00 00 00 00 00 00 fff1f 00 00 fff1f 00 00
Apr 17 20:12:57 yavdr vdr: SDCONNusb_commit(): L4M_E-5i/LCD commiting buffer failed, error: Die Ressource ist zur Zeit nicht verfügbar
Apr 17 20:13:07 yavdr vdr: ***** ep: 0x04 length: 1:
Apr 17 20:13:07 yavdr vdr: ***** debug: 54
Apr 17 20:13:07 yavdr vdr: SDCONNusb_commit(): L4M_E-5i/LCD commiting buffer failed, error: Die Ressource ist zur Zeit nicht verfügbar
Apr 17 20:13:17 yavdr vdr: ***** ep: 0x04 length: 1:
Apr 17 20:13:17 yavdr vdr: ***** debug: 54
Apr 17 20:13:17 yavdr vdr: SDCONNusb_commit(): L4M_E-5i/LCD commiting buffer failed, error: Die Ressource ist zur Zeit nicht verfügbar
Apr 17 20:13:27 yavdr vdr: ***** ep: 0x04 length: 1:
Apr 17 20:13:27 yavdr vdr: ***** debug: 54
Apr 17 20:13:27 yavdr vdr: SDCONNusb_commit(): L4M_E-5i/LCD commiting buffer failed, error: Die Ressource ist zur Zeit nicht verfügbar
Alles anzeigen
Mal ne kurze Zwischenfrage zur serdisplib 2.x...
gibt es die Möglichkeit sie so zu bauen das die benötigten Libs dynamisch gelinkt werden? Ich meine nicht das explizite Laden zur Laufzeit mit dlopen sondern das andere. Übersehe ich da was?
BTW: Mir ist aufgefallen das einige Dateien/Verzeichnisse beim Distclean nicht gelöscht werden
---
serdisplib.pc
serdisplib.spec
stamp-h
buildfiles/serdisplib_2.00.bb
DOCS/Doxyfile
DOCS/html
include/serdisplib/serdisp_control.h
---
Wobei ich hier gerade noch die svn 2012-01-30 habe und mit auch nicht sicher bin obs so gehört oder nicht. Wollts nur erwähnen weils mir auffiel.
BTW2: Das Debianpaketbauwerkzeug meldet für die automatische Rechtschreibprüfung einige Fehler:
----
I: serdisplib-tools: spelling-error-in-binary usr/bin/multidisplay Informations Information
I: serdisplib-tools: spelling-error-in-binary usr/bin/serdisplearn programm program
I: serdisplib-tools: spelling-error-in-binary usr/bin/testserdisp Informations Information
I: libserdisp2: spelling-error-in-binary usr/lib/libserdisp.so.2.00 commiting committing
---
cu
Mal ne kurze Zwischenfrage zur serdisplib 2.x...
gibt es die Möglichkeit sie so zu bauen das die benötigten Libs dynamisch gelinkt werden? Ich meine nicht das explizite Laden zur Laufzeit mit dlopen sondern das andere. Übersehe ich da was?
ja. gibt es schon ziemlich lange: --disable-dynloading
ist eh gut, wenn mal wer anderer damit herum spielt, habe es zwar schon in allen moeglichen konstellationen getestet, aber ich wuerde nicht die hand ins feuer legen fuer 100%ige fehlerfreiheit
Alles anzeigenBTW: Mir ist aufgefallen das einige Dateien/Verzeichnisse beim Distclean nicht gelöscht werden
---
serdisplib.pc
serdisplib.spec
stamp-h
buildfiles/serdisplib_2.00.bb
DOCS/Doxyfile
DOCS/html
include/serdisplib/serdisp_control.h
korrigiert, werden jetzt geloescht.
Alles anzeigenBTW2: Das Debianpaketbauwerkzeug meldet für die automatische Rechtschreibprüfung einige Fehler:
----
I: serdisplib-tools: spelling-error-in-binary usr/bin/multidisplay Informations Information
I: serdisplib-tools: spelling-error-in-binary usr/bin/serdisplearn programm program
I: serdisplib-tools: spelling-error-in-binary usr/bin/testserdisp Informations Information
I: libserdisp2: spelling-error-in-binary usr/lib/libserdisp.so.2.00 commiting committing
---
nun ebenfalls korrigiert.
ja. gibt es schon ziemlich lange: --disable-dynloading
ist eh gut, wenn mal wer anderer damit herum spielt, habe es zwar schon in allen moeglichen konstellationen getestet, aber ich wuerde nicht die hand ins feuer legen fuer 100%ige fehlerfreiheit
Ich habe irgendwie gerade den Anspruch nen Debian Paket zu bauen wo alles funktioniert
Wobei --disable-dynloading es noch nicht wirklich ist. So wie ich das sehe werden dann die drei (?) libs (libpthread , libSDL und libusb) direkt in die libserdisp.so eingelinkt (also mit eingefügt). Aber die ganzen Abhängigkeiten dieser Libs bleiben weiterhin bestehen (?).
root@dirk-vdr:/usr/local/src/serdisplib-2.x+svn339/debian# ldd libserdisp2/usr/lib/libserdisp.so.2
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb759d000)
/lib/ld-linux.so.2 (0xb773a000)
Was IMHO für nen Linux mit Paketverwaltung wäre, wäre das selbe was jetzt bei den tools auch passiert (--disable-statictools).
root@dirk-vdr:/usr/local/src/serdisplib-2.x+svn339/debian# ldd serdisplib-tools/usr/bin/testserdisp
linux-gate.so.1 => (0xffffe000)
libserdisp.so.2 => /usr/lib/libserdisp.so.2 (0xb7835000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb781c000)
libusb-0.1.so.4 => /lib/libusb-0.1.so.4 (0xb7814000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7759000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7612000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb760d000)
/lib/ld-linux.so.2 (0xb7887000)
libasound.so.2 => /usr/lib/libasound.so.2 (0xb7545000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb753c000)
libartsc.so.0 => /usr/lib/libartsc.so.0 (0xb7536000)
libesd.so.0 => /usr/lib/libesd.so.0 (0xb752c000)
libpulse-simple.so.0 => /usr/lib/libpulse-simple.so.0 (0xb7528000)
libpulse.so.0 => /usr/lib/libpulse.so.0 (0xb74e6000)
libdirectfb-1.2.so.9 => /usr/lib/libdirectfb-1.2.so.9 (0xb7471000)
libfusion-1.2.so.9 => /usr/lib/libfusion-1.2.so.9 (0xb745d000)
libdirect-1.2.so.9 => /usr/lib/libdirect-1.2.so.9 (0xb7449000)
libvga.so.1 => /usr/lib/libvga.so.1 (0xb73e8000)
libaa.so.1 => /usr/lib/libaa.so.1 (0xb73cc000)
libncurses.so.5 => /lib/libncurses.so.5 (0xb7392000)
libslang.so.2 => /lib/libslang.so.2 (0xb7297000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7271000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7154000)
libcaca.so.0 => /usr/lib/libcaca.so.0 (0xb708c000)
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0xb7068000)
libpulsecommon-0.9.21.so => /usr/lib/libpulsecommon-0.9.21.so (0xb701d000)
libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0xb7017000)
libcap.so.2 => /lib/libcap.so.2 (0xb7013000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb6ffc000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb6ff3000)
libXtst.so.6 => /usr/lib/libXtst.so.6 (0xb6fee000)
libx86.so.1 => /lib/libx86.so.1 (0xb6feb000)
libgpm.so.2 => /usr/lib/libgpm.so.2 (0xb6fe5000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6fcc000)
libncursesw.so.5 => /lib/libncursesw.so.5 (0xb6f85000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6f71000)
libwrap.so.0 => /lib/libwrap.so.0 (0xb6f69000)
libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0xb6f02000)
libasyncns.so.0 => /usr/lib/libasyncns.so.0 (0xb6efd000)
libdbus-1.so.3 => /lib/libdbus-1.so.3 (0xb6ec2000)
libattr.so.1 => /lib/libattr.so.1 (0xb6ebd000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb6eb9000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb6eaa000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xb6e9d000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb6e99000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6e94000)
libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb6e7d000)
libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0xb6e2d000)
libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb6cb7000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb6c8e000)
libogg.so.0 => /usr/lib/libogg.so.0 (0xb6c88000)
libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb6c74000)
Alles anzeigen
BTW: Wenn testserdisp den Treiber "REMOTE" nicht anbietet dann stimmt was mit den Laden der Netzwerklibs (libsocket.so, libnsl.so, libnet.so) nicht? Weil diese finde ich nirgends (aus welchen Projekt/Paket stammen die denn?). serdispd startet Problemlos und wartet, aber keines der Tools mag den REMOTE Treiber akzeptieren um was zum serdispd zu senden.
BTW2: In serdisp_connect_usb.c hast du noch 3x "commiting" anstelle von "committing".
cu
<sarcasm>
'debian' und 'alles funktioniert': ist das nicht ein widerspruch?
</sarcasm>
ok. der dzt. stand v. serdisplib/svn traegt jetzt auch nicht gerade dazu bei
aber darum ist es ja auch noch keine stable-version ...
committing: yep. in der tat. habs lokal bereits korrigiert, aber dann nicht committed, weil noch einiges debug-zeug drin ist wegen des sch*** aeh schoenen libusb0-compatibility-layers, mit dem ich noch kaempfe.
das mit den abhaengigkeiten muss ich mir ansehen, das passt tatsaechlich nicht. aber die dependency-list von deinem testserdisp-beispiel laeuft schon sehr aus dem rahmen. die bekomme ich bei mir nicht einmal annaehernd hin, egal welche kombinationen ich versuche ... sogar asound, pulse und der ganze schmarrn (wird das bei debian ueber die libSDL hineingezogen?). sogar libcaca!!
ad remote: wenn er beim configure-output hier drin ist:
enabled(+) / disabled(-) drivers
================================
+ sed153x, pcd8544, sed156x, i2c, t6963, sed133x, nokcol, ks0108, lh155, ssdoled, l4m, goldelox, stv8105, acoolsdcm, directgfx, rs232, lc7981, ddusbt, framebuffer, remote
- displaylink
sollte er auch funktionieren ... du musst natuerlich --enable-experimental dafuer aktivieren (das ganze netzwerkzeug ist immer noch hochexperimentell und auch noch nicht fertig)
<sarcasm>
'debian' und 'alles funktioniert': ist das nicht ein widerspruch?
</sarcasm>
Das lasse ich jetzt mal unkommentiert
ok. der dzt. stand v. serdisplib/svn traegt jetzt auch nicht gerade dazu bei
aber darum ist es ja auch noch keine stable-version ...
Jup, ich finde da gerne Fehler.
das mit den abhaengigkeiten muss ich mir ansehen, das passt tatsaechlich nicht. aber die dependency-list von deinem testserdisp-beispiel laeuft schon sehr aus dem rahmen. die bekomme ich bei mir nicht einmal annaehernd hin, egal welche kombinationen ich versuche ... sogar asound, pulse und der ganze schmarrn (wird das bei debian ueber die libSDL hineingezogen?). sogar libcaca!!
Ja, das kommt von SDL, passt aber schon. Wobei aber SDL eigentlich gar nicht gegen jedes Tool gelinkt werden sollte. Weil direkt wird es ja von den Tools nicht genutzt wenn ich das richtig sehe.
Wobei ich bei --disable-dynloading auch nicht sehe das da der serdisplib überhaupt irgendwas hinzugelinkt wird. Bei --disable-dynloading wird die Lib auch kleiner.
Ich reiche dann hier im Postings mal zwei komplette Build Log nach, einmal mit --enable-dynloading und einmal mit --disable-dynloading
Edit: https://www.dropbox.com/sh/mnaw649geme1j46/O3bSkZAwoF
ad remote: wenn er beim configure-output hier drin ist:
enabled(+) / disabled(-) drivers
================================
+ sed153x, pcd8544, sed156x, i2c, t6963, sed133x, nokcol, ks0108, lh155, ssdoled, l4m, goldelox, stv8105, acoolsdcm, directgfx, rs232, lc7981, ddusbt, framebuffer, remote
- displaylink
sollte er auch funktionieren ... du musst natuerlich --enable-experimental dafuer aktivieren (das ganze netzwerkzeug ist immer noch hochexperimentell und auch noch nicht fertig)
Genauso ist es bei mit, aber bei "testserdisp -h" wird "REMOTE" nicht als Treiber angezeigt.
Edit: OK, das war meine Blödheit Es geht natürlich, ich hatte beim Test noch die alte Lib aktiv.
Mir ist nur nicht ganz klar wie ich das nun aufrufe
--
./testserdisp -n REMOTE -p net:15243
Error: Unable to open net:15243, additional info: connection type 'net' is not supported
--
habe schon alles durchprobiert.
Edit: Aha
----
./testserdisp -n REMOTE -p SRV:lcdname@localhost
----
Läuft, schöne Sache. Also die Net Sache geht mit --enable-dynloading.
cu
Ich habe gerade mein l4m132c wiedergefunden und wollte jetzt einfach mal nachfragen, ob damit mit touchcol nun inzwischen auch Farbe geht?
Ja geht...
Ja geht...
Schön, hast Du evtl. auch eine passende Config?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!