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

Gibt es eigentlich eine Condition mit der ich rausfinden kann, ob jemand anwesend ist? Soweit ich weiß hat der VDR dafür verschiedene Status.

Du meinst ob der VDR denkt, dass der User aktiv ist?
Keine_Ahnung hat dafür das uactivity-Plugin geschrieben, alternativ kann man auch mit dbus2vdr danach fragen.

Hi,
ist das evtl. noch was:
Graphlcd mit PicoLCD_256x64 ???

mfG,
Stefan

Dort wird erwähnt, dass in dem Patch noch was fehlt...

evtl. kannst du das noch einbauen?

Hatte es nur gerade gelesen...

mfG,
Stefan

Hi,
ok.

Btw: bezog sich deine Aussage, dass sich glcds im VDR connecten lassen (bei laufendem VDR) auch auf parallele?

Also könnte man ein glcd via OSD-Eintrag koppeln (sofern graphlcd-Plugin geladen mit "dummy", s.o.)?
Dann könnte man sogar im OSD n Menü bauen, wo man die Parameter einstellt, für das zu ladende glcd und dann dieses connecten.
Mir gehts immer noch um einen easy-Installer dafür. Im Setup haben wir ja bisher eine solche Möglichkeit zum Auswählen des glcd drin. Aber Parameter wie Auflösung etc. ist halt noch nicht drin.

Und noch eine Frage: Es hiess ja immer, das graphlcd-Plugin benötigt den wareeagleicon-Patch im VDR. Wäre es da nicht möglich, das mal zu ändern (Logos vom Skin holen/externen Font zusätzlich laden), um den echt obsolet zu machen?

mfG,
Stefan

Zitat von SurfaceCleanerZ

Und noch eine Frage: Es hiess ja immer, das graphlcd-Plugin benötigt den wareeagleicon-Patch im VDR.

Ne, benötigt es nicht.

Der wareeagleicon-Patch macht wirklich nix weiter als einige Zeichen (die aufgrund der Optik der Glyphen als Symbole missbraucht werden) im VDR Quellcode gegen anderer zu tauschen.
Also wenn in der Tierübersicht ein Timer gerade aufzeichnet wird anstelle von '#' das "\uE00B" verwendet, mehr ist das nicht.
Plugins haben mit dem wareeagleicon-Patch also auch generell nix zu tun.

Zitat von wastl

plugin mit --display=none starten und dann zur laufzeit das/die gewuenschte(n) displays via SVDRP-commands hinzufuegen.

Danke, das ist genau das was ich gesucht/gewünscht hatte. War mir bissher entgangen das das so geht.

cu

Hi,
naja, wenn dann auf dem glcd aber diese missbrauchten Symbole verwendet werden, dann braucht es ihn ja schon, damits gut aussieht!. Außer graphlcd wurde so geändert, dass es dafür, wie modernere skins, Icons nutzt.

mfG,
Stefan

Zitat von SurfaceCleanerZ

naja, wenn dann auf dem glcd aber diese missbrauchten Symbole verwendet werden, dann braucht es ihn ja schon, damits gut aussieht!. Außer graphlcd wurde so geändert, dass es dafür, wie modernere skins, Icons nutzt.

Ich glaube wir müssen erstmal definieren wovon wir reden

Ohne Wareagle siehst du im Timermenü "#" auf dem OSD, und das selbe siehst du auch auf dem Display.
Mit Wareagle siehst du das <rec> Icon auf dem OSD und das selbe siehst du auch auf dem Display.

Dise Wareagle Symbole sind ganz normale Textzeichen (VDR Menus sind ganz normale Textzeilen), und graphlcd zeigt auf dem Display die selben Texte die im OSD zu sehen sind.

cu

Hi,
genau das meinte ich. Neuere Skins können das (s. wohl nopacity) auch anders. Nur kommen an diese Infos wohl derzeit nur Skin-Plugins ran.

Und graphlcd ist ja kein Skin-Plugin.

Was spricht denn dagegen, dass die Symbole im graphlcd von extern geholt werden aus 2. Font, der nur dafür da ist? Dann bräuchte es den Patch in Zukunft nicht mehr, da kls den ja wohl nicht integrieren will, wie es aussieht, da er sonst wohl mittlerweile drin wäre.

Hier der Fred, wo das grad diskutiert wird.
[Gelöst] wareagle-icons: Funktioniert der Patch noch bzw. ist er noch notwendig? (ja ist er)

skinelchi ersetzt wohl auch ohne den Patch die Symbole richtig.

mfG,
Stefan

Skinelchi verwendet (soweit mir bekannt) noch einen eigenen Mechanismus, der auf Parsen der Strings, die vom VDR kommen, basiert. Skinnopacity verwendet neue, modernere, Schnittstellen vom VDR um die Daten zu erhalten noch bevor der VDR daraus einen String baut.

Zitat von SurfaceCleanerZ

genau das meinte ich. Neuere Skins können das (s. wohl nopacity) auch anders. Nur kommen an diese Infos wohl derzeit nur Skin-Plugins ran.

Und graphlcd ist ja kein Skin-Plugin.

Würde vermutlich auch in graphlcd gehen, aber das ist ne andere Sache und das funktioniert nur bei einigen wenigen speziellen VDR Menus.

Zitat von SurfaceCleanerZ

Was spricht denn dagegen, dass die Symbole im graphlcd von extern geholt werden aus 2. Font, der nur dafür da ist? Dann bräuchte es den Patch in Zukunft nicht mehr, da kls den ja wohl nicht integrieren will, wie es aussieht, da er sonst wohl mittlerweile drin wäre.

Der Patch hat wirklich nix damit zu tun ob graphlcd die Symbole aus Font A oder aus Font B holt.

Zitat von SurfaceCleanerZ

skinelchi ersetzt wohl auch ohne den Patch die Symbole richtig.

Ja, durch parsen der Strings und mutiges Raten. Da darf jeder gerne seine eigene Meinung zu haben

Ich kann wirklich nicht verstehen warum Klaus da soviel Wert drauf legt konstante Strings wild im Quellcode zu verteilen. Alle "diese Strings werden nur aufgrund der Optik genutzt" Strings per #define in ein symbols.h auslagern (und im Quellcode dann mit beschreibenden Konstanten arbeiten) und alles wäre gut.
Und der Code wäre auch lesbarer, weil man nicht raten müsste warum denn jetzt "#" ausgegeben wird. Dann wenn man sieht das SYMBOL_REC ausgegeben wird weis man sofort das dieses String als Symbol genutzt wird und man hier REC signalisiert.

cu

Hi,
hab btw noch n kl. Fehler in showpic.c:

fprintf(stdout, "\n");
	fprintf(stdout, "%s v%s\n", prgname, version);
	fprintf(stdout, "%s is a tool to show an image on a LCD.\n", prgname);
	fprintf(stdout, "The image must be in a special format (*.glcd).\n");
	fprintf(stdout, "You can create such images with the convpic tool.\n\n");
	fprintf(stdout, "  Usage: %s [-c CONFIGFILE] [-d DISPLAY] [-s SLEEP] [-uie] file [more files]\n\n", prgname);
	fprintf(stdout, "  -c  --config  	specifies the location of the config file\n");
	fprintf(stdout, "                	(default: /etc/graphlcd.conf)\n");
	fprintf(stdout, "  -d  --display 	specifies the output display (default is the first one)\n");
	fprintf(stdout, "  -u  --upsidedown  rotates the output by 180 degrees (default: no)\n");
	fprintf(stdout, "  -i  --invert  	inverts the output (default: no)\n");
	fprintf(stdout, "  -e  --endless 	show all images in endless loop (default: no)\n");
	fprintf(stdout, "  -s  --sleep   	set sleeptime between two images [ms] (default: %d ms)\n", kDefaultSleepMs);
	fprintf(stdout, "  -b  --brightness  set brightness for display if driver support it [%%]\n");
	fprintf(stdout, "                	(default: config file value)\n");
	fprintf(stdout, "\n" );
	fprintf(stdout, "  examples: %s -c /etc/graphlcd.conf vdr-logo.glcd\n", prgname);
	fprintf(stdout, "        	%s -c /etc/graphlcd.conf -d LCD_T6963 -u -i vdr-logo.glcd\n", prgname);
	fprintf(stdout, "\n" );

fprintf(stdout, " %s -c /etc/graphlcd.conf -d LCD_T6963 -u -i vdr-logo.glcd\n", prgname);
ist falsch, das muss so heissen (analog zur graphlcd.conf):
fprintf(stdout, " %s -c /etc/graphlcd.conf -d t6963c -u -i vdr-logo.glcd\n", prgname);

Und
fprintf(stdout, "The image must be in a special format (*.glcd).\n");
ist doch auch überholt, zumindest, wenn der imagemagick-Support an ist. Könnte man evtl. ergänzen.

War mir nur gerade ins Auge gestochen.

Hab aber noch Probleme, dass mein t6963c sich immer bei der Azeige einer .bmp aufhängt (zeigt sie fast an, fehlt nur von untersterTextzeile die unteren 2/3) und dann hängt es komplett bis zum Reboot.

root@easyVDR:/# showpic -c /etc/graphlcd.conf -d t6963c /usr/share/easyvdr/program-changer/pictures/warten_glcd_240x128.bmp
^C

Lässt sich nicht mit STRG+C beenden!
Bild hängt an, stammt aus Gimp. Convpic mag das btw auch nicht, sagt dass es kein Windows BMP ist, welche nur unterstützt werden.

Habe es dann mit XnView neu abgespeichert (mit Kompression: warten_glcd_240x128_1.bmp). Dann frisst es convpic. Aber die .glcd (s. angehängte .zip) will showpic nicht laden:

root@easyVDR:~# showpic -c /etc/graphlcd.conf -d t6963c /usr/share/easyvd
r/program-changer/pictures/warten_glcd_240x128_1.glcd
ERROR: Failed loading file /usr/share/easyvdr/program-changer/pictures/warten_glcd_240x128_1.glcd

Wenn ich die warten_glcd_240x128_1.bmp in XnView invertiere + speichere (ohne Kompression: warten_glcd_240x128_neg.bmp), dann lädt showpic sie ohne Absturz.

Jage ich sie wieder durch convpic, läuft sie durch, aber showpic verweigert die Anzeige.

Nutze v0.1.9 mit imagemagick-Support am t6963c mit 240x128 6" priatna glcd.

Kann das wer bestätigen? Oder mache ich was falsch?

mfG,
Stefan

Hi,
wenn ich helfen kann, sag es!

mfG,
Stefan

Hi wastl,

danke fürs schnelle Fehlerbestätigen. Bist ja echt fix!

War mir halt nur vor längerer Zeit schon aufgefallen...

Btw: showpic frisst anscheinend außer .glcd nur noch .bmp, andere konnte ich nicht dazu bewegen, gefressen zu werden, soll das so? Ändert sich dann ja auch, da das Plugin ja mehr Formate kann, oder?

mfG,
Stefan