Beiträge von wastl

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

Zitat von Keine_Ahnung

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

Zitat von Keine_Ahnung

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

Alles anzeigen

korrigiert, werden jetzt geloescht.

Zitat von Keine_Ahnung

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

Alles anzeigen

nun ebenfalls korrigiert.

wenn du es testet, dann nimm den svn-trunk von serdisplib (upcoming version 2.x).
da habe ich bereits einiges ausgebessert bzgl. architekturabhaengiger datentypen (macht in alten versionen (1.98.x) probleme mit IR+64bit).

ausserdem zu beachten: IR geht NICHT mit dem libusb0-compatibility-layer von libusb1 (nur mit der 'echten' libusb0). wenn die IR-funktionalitaet eingeschaltet wird bei libusb1+libusb0-compatibility-layer, bleibt das ganze ziemlich sicher irgendwann mal haengen (bekannte schwaeche v. compatibility-layer, ist denen aber anscheinend egal).
da bin ich gerade beim herumexperimentieren wie ich das am besten loese.

daher bitte ueber das iowarrior-modul ansteuern und nicht ueber libusb:

zb: src/testserdisp -n ctinclud -p "IOW24:/dev/usb/iowarrior1"

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;

achtung: ungetestet!

EDIT: portal-editor hatte code-text massakriert

Keine_Ahnung:

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?

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/

urknall

habe in der serdisplib jetzt das mit dem define weggeworfen und dafuer die zusaetzliche option eingebaut:
PARANOIA=off .. libusb kann auch auf linux-basierenden systemen verwendet werden,

wenn die option nicht gesetzt wird, kommt eine aehnliche fehlermeldung wie zuvor.

achtung: das ganze ist nur im trunk der library eingebaut:

svn co https://serdisplib.svn.sourceforge.net/svnroot/serdisplib/serdisplib/trunk serdisplib-2.x_svn

wenn lust / moeglichkeit dazu: bitte testen.

beim visualdata koennte es sich ev. um einen nachbau vom maeusekino handeln (ziemlich aehnliche platine, sogar ein weisser aufkleber am iow24 wie beim original :), gleiche anzahl v. leds, gleicher ir-empfaenger, ausgelegt auf denselben displaycontroller). aber wie du ja auch bereits festgestellt hast: keine weiteren angaben vorhanden, daher mutmasssung. angaben daher ohne gewaehr.
am besten du fraegst dort nach.

das zweite sieht ja nicht mal schlecht aus. ist mir aber noch nicht untergekommen bis jetzt. interessante art der ansteuerung: jeden schmarrn in ein bild umrechnen und komplett uebertragen

news (vdr-plugin-graphlcd):

• plugin kompiliert jetzt auch unter vdr 1.7.27 (das eine include war in display.c ohnedies ueberfluessig)

spacy
fehlerhafte verwendung der token? diese gibt es eigentlich schon laenger ... und freezen sollte vdr auch bei einer falschen verwendung nicht?!
wie lautet in der skin-def der/die eintrag/eintraege mit scrolltime/scrollmode?

testanzeige nicht, aber du kannst dich via telnet zum vdr verbinden und dort ein
'plug graphlcd connect' absetzen.

das initialisert das/die display(s) neu und ladet dabei auch den/die skin(s) neu ...

genauere details dazu sind irgendwo in diesem mega-thread versteckt

aber das oben sollte fuer deine zwecke ausreichend sein.

ergaenzung:
ein schickes

echo "plug graphlcd connect"|nc localhost 6419

macht das fast noch eleganter

(port 6419 entsprechend ersetzen wenn abweichend in deiner installation)

naja, ich kann's ja mittlerweile auch nicht mehr nachstellen.

fakt ist aber, dass es das problem gibt / mal gegeben hat und ich da niemanden ohne warnung hineinlaufen lassen moechte.

vielleicht habe ich mich missverstaendlich in meinem vorigen posting ausgedrueckt, aber ich plane ja, dass es das mit define libusb ja/nein nicht mehr gibt, dafuer aber fuer die infrage kommenden displaymodelle eine zusaetzliche option, die gesetzt werden muss (dh. libusb immer verfuegbar, auch fuer die genannten modelle, aber fuer diese nur mit dieser option)

das problem ist/war nur fuer jene _eventuell_ relevant, die l4m132c oder das l4me5i via libusb betrieben haben. ich konnte es auch nur auf einem brett (welches mittlerweile im muell ist) reproduzieren. aber da kam es zu einem schoenen total freeze (kein bild, kein ton - ein hornyphon. nicht einmal pingbar war die maschine danach). da aber ein total freeze doch eher unangenehm ist, habe ich mich damals entschlossen, bei intel-basierenden cpus (intel + amd) libusb zu unterbinden fuer die genannten displaymodelle.
da es aber womoeglich ohnedies obsolet ist, werde ich das ganze durch einen schoenere form ersetzen (ev. option a la FORCE=yes). ganz moechte ich die einschraenkung nicht weglassen ...

bitte nicht 'korrekt' hier schreiben. nur weil es vielleicht unter debian & co. so gemacht wird.

das ist einer der gruende, weshalb ich debian & co aus ganzem herzen ablehne.
weil nicht nur einmal es vorgekommen ist, dass die debian-community sich etwas irgendwie einbildet und dann das fuer ganz 'linux', wenn nicht sogar fuer ganz unix das so postuliert und als einzig richtig und wahr annimmt ...

news (vdr-plugin-graphlcd):

• unterstuetzung fuer VDR >= 1.7.26 hinzugefuegt

achtung:
nicht getestet (habe noch aeltere VDR-version)

@ test -d:
war tatsaechlich ein bug und eigentlich waere && von mir gemeint gewesen -> gefixt

@ = => ?=
spricht nix dagegen -> geaendert

@ vdr 1.7.26
abwaertsinkompatible API-aenderungen ... wie ich das liebe ...
werde ich mir alsbald ansehen

news (vdr-plugin-graphlcd):

• {MenuTextScroll} sollte jetzt etwas zuverlaessiger funktionieren (noch nicht perfekt, aber zumindest brauchbar(er))

Zitat von Keine_Ahnung

Da hatte ich das auch drin

Code

{MenuText}

Ich habs auch mal gerade wieder eingebaut. Wenn du mal testen magst? In ./inc/displayerror.inc den block rauslöschen dann sollte der Skin auch auf Displays >320x240 links oben angezeigt werden.

Im default Skin gehts auch nicht.

Mir fehlt auch der Ansatz wo ich mal schauen könnte, diese ganze VDR OSD Sache ist mir etwas unheimlich

cu

Alles anzeigen

ja. da hat's was. es funktionert zwar, aber nur wann es will (wenn man zb. etwas laenger page down gedrueckt haelt - aber auch dann nur ab und zu).
das hat schon einmal besser funktioniert ...
das wird wieder was zu debuggen ...

EDIT: gut, dass das select message beim quote so super funktionert. aber ich denke Keine_Ahnung weiss, worauf sich meine antwort bezieht ...

UPDATE: fehler gefunden.
es wird einfach zu selten 'upgedatet', da sich bei der menutext-ansicht ja im normalfall nix aendert ... (habe im menutitle testhalber die sekunden der aktuellen uhrzeit mitlaufen - da geht's dann relativ fluessig ...)
da muss ich mir etwas ueberlegen ... (entweder das war in einer aelteren vdr-version anders (osd-events haben update ausgeloest) oder ich habe es tatsaechlich nur mit touchscreen getestet .. weiss ich ehrlich gesagt nicht mehr).

UPDATE 2: mit dem touchpad gehts auch nicht mehr brauchbar. das wird was fuer das wochenende ...

base 0.1.9 + plugin 0.3.0 sollte eigentlich gar nicht zusammen funktionieren?

was verstehst du unter 'plugin.graphlcd.conf'?

falls es etwas distro-spezifisches ist: ich kann antworten zu distro-unabhaengigen dingen geben, aber nicht zu irgendwelchen distro-spezifischen basteleien (ich verwende _KEINE_ vdr-distro).

das skin-zeug hat btw. nichts mit der graphlcd.conf zu tun.

Zitat von SurfaceCleanerZ

Hi,
mal ne ganz blöde Frage:
Wie wechsle ich den Skin in graphlcd touchcol?
In einer plugin.graphlcd.conf
-c /etc/graphlcd.conf -s touchcol
bringt leider nix...
graphlcd.conf liegt dort und geht ja auch...
Btw: in der graphlcd.conf ist immer noch ganz oben ein Schreibfehler:
Waikt Method
Nur der Schönheit halber...

Alles anzeigen

auf welche version beziehst du dich? im touchcol branch ist der tippfehler nicht mehr (dafuer habe ich einen anderen gefunden
auch das -s geht freilich nur im touchcol branch (und da auch nur in einer moeglichst aktuellen version).

Zitat von SurfaceCleanerZ

Könnte man nicht beim t6963c den default auf Windows-Wiring setzen? Nutzen doch fast alle dank der Anleitung hier fürs priatna...

wie ich schon einmal gesagt habe: nein.
ich stelle keine etablierten standardwerte um, ausser es gibt unabdingbare gruende dafuer (bug, universum wuerde ansonsten implodieren, ...).
und dass das 'fast alle' verwenden, bezweifle ich sehr.

wenn der standardwert jetzt geaendert wuerde, wuerde dann bei all jenen, die sich bis jetzt darauf verlassen haben, auf einmal das t6963c nicht mehr funktionieren ...

Zitat von SurfaceCleanerZ

Das graphlcd tut hier problemfrei auf t6963c ohne serdisplib.

yep. funktioniert btw. auch im touchcol-branch (von mir portiert und getestet

ayeee. was weiss ich wieso ich bei 'dropbox' immer an so eine copy'n'paste web-zwischenablage denke ...