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

Danke. wäre das schon mal geklärt. - die 7 Pakete sind drin!

Irgendwo drückt aber noch der Hase im Pfeffer, leider hab ich mich nie mit graphlcd befasst und nur um graphtft gekümmert:

root@CKtwo:/var/cache/vdr/epgimages# showpic -d ax206dpf 1001.jpg
ERROR: Failed creating display object ax206dpf

Ne ähnliche Meldung gibts auch vom Plugin, nur solang das hier nicht spielt macht das es wenig Sinn denk ich.

Die Konfig hab ich wie in Post 434 , die udev Rule aus dem Paket sollte passen. Worauf weist so eine Fehlermeldung typischerweise hin?

Danke!

...fast am Ziel...

ich hatte wohl vor Wochen als ich das Pearl gehackt hatte das graphlcd-base aus dem git eingespielt, das hab ich gerade wieder rausgenommen, seitem geht das mit mit dem showpic, konnte eins von den Symbolen anzeigen lassen: Uff!

Anbindung an vdr geht jetzt auch, da stimmen noch zwei Dinge im Paket nicht um ootb zu funktionieren:

Zum Einen muss für die mitgelieferte udev rule der vdr in die Gruppe uucp, zum anderen fehlt wie weiter vorn beschrieben eine Schrift - im src Paket ist sie drin, nur im richtigen Paket nicht.

apt-get source vdr-plugin-graphlcd
cd vdr-plugin-graphlcd-0.1.9+git20110811/graphlcd/fonts
cp DejaVuSans* /usr/share/vdr-plugin-graphlcd/fonts/

Ansonsten gehen gerade Logos noch nicht, aktualisierungsgeschwindigkeit und Anzeigequalität ist sogar besser als ich dachte, also vielen Dank für eine nette Erweiterung!

PS:
Wenn ich jetzt beim runterfahren mit showpic irgendwas nettes auf's Pearl zaubern will muss ich das dann als clcd haben oder geht da auch jpg, und muss ich das besser direkt an dieses 320er Format anpassen? Auch hier danke für ein paar Tipps.

Christian

Zitat von CKone

Ansonsten gehen gerade Logos noch nicht

Die Logos werden auch nicht mitgeliefert. Musst dir welche besorgen und im touchcol Skinfile den Pfad anpassen.

Ich hatte mit auch schonmal die text2skin Logos ergoogled, aber das ist nen furchbares Chaos und die muss man erstmal alle richtig umgbenennen.

Zitat von CKone

geht da auch jpg, und muss ich das besser direkt an dieses 320er Format anpassen? Auch hier danke für ein paar Tipps.

Geht auch JPEG, und das Logo muss in der passenden Auflösung vorliegen.

cu

Zitat von Keine_Ahnung

Ich hatte mit auch schonmal die text2skin Logos ergoogled, aber das ist nen furchbares Chaos und die muss man erstmal alle richtig umgbenennen.

also mit einem kompletten Satz (auch die neuen! ) anthra Logos könnt ich dienen, wir könnten ja gegen die glcd's tauschen

Danke für die Info's.

Christian

Zitat von CKone

...fast am Ziel...

ich hatte wohl vor Wochen als ich das Pearl gehackt hatte das graphlcd-base aus dem git eingespielt, das hab ich gerade wieder rausgenommen, seitem geht das mit mit dem showpic, konnte eins von den Symbolen anzeigen lassen: Uff!

Anbindung an vdr geht jetzt auch, da stimmen noch zwei Dinge im Paket nicht um ootb zu funktionieren:

Zum Einen muss für die mitgelieferte udev rule der vdr in die Gruppe uucp, zum anderen fehlt wie weiter vorn beschrieben eine Schrift - im src Paket ist sie drin, nur im richtigen Paket nicht.

Code

apt-get source vdr-plugin-graphlcd
cd vdr-plugin-graphlcd-0.1.9+git20110811/graphlcd/fonts
cp DejaVuSans* /usr/share/vdr-plugin-graphlcd/fonts/

Ansonsten gehen gerade Logos noch nicht, aktualisierungsgeschwindigkeit und Anzeigequalität ist sogar besser als ich dachte, also vielen Dank für eine nette Erweiterung!

PS:
Wenn ich jetzt beim runterfahren mit showpic irgendwas nettes auf's Pearl zaubern will muss ich das dann als clcd haben oder geht da auch jpg, und muss ich das besser direkt an dieses 320er Format anpassen? Auch hier danke für ein paar Tipps.

Christian

Alles anzeigen

Hallo,

da habe ich den ganzen Tag damit verbracht das display zum laufen zu bringen und abends lese ich erst hier die Lösung meiner Probleme. Vielen Dank für die Hinweise (das mit der gruppe hätte ich ja mal überprüfen können.. .) ckone. Du hast meinen Tag doch noch gerettet!

Die Darstellung ist nur etwas zu klein, gibt es da eine möglichkeit, anderer skin, etc.?

Gruss,
raoul

Zitat von raoul

Die Darstellung ist nur etwas zu klein, gibt es da eine möglichkeit, anderer skin, etc.?

Du kannst dir selber den Skin anpassen. Ich überlege noch ob ich das als Zweitdisplay nur fürs Bildschirmfüllenndelogo (im 30 Sek. Wechsel mit ner grossen Uhr) dranlasse.

Zitat von CKone

also mit einem kompletten Satz (auch die neuen! ) anthra Logos könnt ich dienen, wir könnten ja gegen die glcd's tauschen

Die glcd (sind ja Schwarzweiss only) sind recht komplett im GIT.

Sind die anthra in 64x48?

cu

Zitat von Keine_Ahnung

Die glcd (sind ja Schwarzweiss only) sind recht komplett im GIT.

ja ich hatte auch ne Menge Logos dabei, deshalb war ich verwundert das kein einziges angezeigt wurde. Schau ich mir heute Abend an, vllt hängt da was an dieser Mappingdatei

Zitat von Keine_Ahnung

Sind die anthra in 64x48?

ne, nicht 4:3, man müsste die extrem im der Breite stauchen. Aber es gibt da einen -zugegeben nicht vollständigen- Satz den izeman mit dem anthraize ausliefert, der sieht geeigneter vom Seitenverhältnis aus, schau mal die Screenshots hier . Den könnten wir nehmen, kleiner skalieren und vervollständigen?

Wenn sich noch zwei drei Mitstreiter finden könnten wir den fürs graphlcd fertig machen...

Christian

BTW: Wenn ich den VDR ohne SDC Display beende schmiert er ab, da man in ohne Fehler ohne Display starten kann denke ich das ist nen Bug.

Program terminated with signal 11, Segmentation fault.
#0  serdisp_close (dd=0x0) at serdisp_control.c:1366
1366	  if (dd->gpevset && SDEVLP_getstatus(dd) == SDEVLP_RUNNING)
#0  serdisp_close (dd=0x0) at serdisp_control.c:1366
#1  0xb4e50873 in GLCD::cDriverSerDisp::DeInit() ()
   from /usr/lib/libglcddrivers.so.2
#2  0xb4e71820 in ~cPluginGraphLCD (this=0x82af028, 
    __in_chrg=<value optimized out>) at plugin.c:85
#3  0x080fcedf in ~cDll (this=0x81a78d0, __in_chrg=<value optimized out>)
    at plugin.c:164
#4  0x0812dc6f in cListBase::Del (this=0xbf86ab80, Object=0xa9b49a6c, 
    DeleteObject=true) at tools.c:1794
#5  0x080fc9d5 in cPluginManager::Shutdown (this=0xbf86ab70, Log=true)
    at plugin.c:500
#6  0x08134152 in main (argc=62, argv=0xbf86acf4) at vdr.c:1709

Letzte 1.98 SVN Version der serdisplib.

cu

Zitat von wastl

diese udev-rules sollten eigentlich final sein. das ist das, was graphlcd-base unterstuetzt. da sollte man dann eigentlich die finger davon lassen. wenn aenderungen notwendig sind (fehler, weitere displays): dann kommts rein in das graphlcd-base paket und soll in letzter instanz das bisher gueltige ueberschreiben.

Wenn jemand ganz bewusst ein Überschreiben vorhat, dann kannst du das ohnehin nicht verbieten.

Ich sehe an der Stelle auf jedem Fall keinen Grund von etablierten Standards abzuweichen. Unter /etc gehören lediglich Config-Dateien. Also Kram, das der Benutzer editieren darf und soll. Viele erstellen von dem Bereich auch bewusst ein Backup um Einstellungen zu sichern.

Dein Rule-Set dagegen ist in dem Sinne keine Konfigurationsdatei sondern Bestandteil deines Pakets. Folglich gehört das unter /lib.

Bitte sei so gut und halte dich an solche Standards. Es reicht schon, wenn jede VDR-Distri ihre eigenen Standards baut, weil sich der VDR selbst out of the box nicht ansatzweise LFS-Konform verhält.

Zitat

branches: tja. gute frage. ich habe eigenwillig den touchcol-branch erstellt, weil alles andere sowieso tot zu sein scheint (auch randy scheint keine zeit mehr zu haben) und ich auch nicht wirklich antwort auf rueckfragen bekommen habe.

Wenn du das sagst, dann wird wohl was wahres dran sein.

Zitat

wenn dieser branch dann mal halbwegs prod-level hat, kann man ihn ja zum offiziellen 'graphlcd-base' ernennen. (selbiges gilt freilich auch fuer vdr-plugin-graphlcd).
wer auch immer das dann schlussendlich entscheidet ...

Gute Idee. Unter der Bedingung, dass man sich mit den Skins nicht auseinandersetzen *muss*. Ich will weiterhin ein Standarddisplay betreiben können, ohne dafür viel zu konfigurieren. Ich brauche also ein Default-Skin, welches das "alte Verhalten" nachbildet.

Nuja, am Ende hat ja jede Distribution ihre Packete. Der Enduser nimmt eh nicht make install weils dann am Ende nicht mehr wartbar ist.
Ich habe mir die yaVDR Packete geklaut um darauf aufbauend meine eigenen zu basteln, und da landet die udev Regel bei mir ganz automatisch unter /lib/udev/rules.d/60-libglcddrivers1.rules (halt Default 60 mit dem Packetnamen). Die Debianpacketwerkzeuge liefern tolle Möglichkeiten ein Paket zu definieren und dabei Dinge anzupassen ohne den Upstreamcode zu ändern. Jeder wie ers für richtig hält e-Tobi patcht auch imQuellcode aller Pluigns rum um seine Pathvorstellunge umzusetzen, ich nutze nen UnionFS um das alles ganz anderst zu machen.

Wichtig ist dabei hauptsächlich das das Packet den Inhalt der Regel mitliefert.

cu

Definitionssache.

Viele moderne Linux-Systeme booten ohne udev nicht mehr oder nur noch mit Einschränkungen. Demnach sind die entsprechenden Daten unter /lib zumindest nicht ganz falsch.

"man udev" sagt:

Zitat

The udev rules are read from the files located in the default rules directory /lib/udev/rules.d/, the custom rules directory /etc/udev/rules.d/ and the temporary rules directory /dev/.udev/rules.d/.

Die meisten anderen Projekte halten sich daran und lassen das Verzeichnis für Benutzerdefinierte Rules in Ruhe.

Klar ist es letztlich Sache des Programmierers, wie er was tut, aber IMHO ist es, wenn man ein bestimmtes Werkzeug einsetzt, nicht ganz falsch, sich an Empfehlungen zu halten. Und sei es nur, weil es andere Projekte auch tun und so in einem Pfad zusammenfindet, was zusammengehört.

Würde euch sowas nach einer Photomontage gefallen, weil die Logos hätten wir komplett, müssten nur resized werden:

oder so damit der Sendername etwas länger werden kann... Wobei mir das Logo einen hausch zu groß für das Display ist - die erste Größe ist besser!

Das ist doch Skinbar. Mach doch einfach mal nen Skin (sind simple Textfiles), ich bin mir sicher der wird dann gerne ins GIT aufgenommen, mehr Auswahl schadet ja nicht.

BTW: Die erste Variante finde ich eleganter. Wobei mir das Display für sowas (alle infos) generell zu klein ist.

cu

ja, habs gesehen, muss das aber bevor ich anfange immer erst sehen wie es ideal ist, sonst wird das zu fummelig. Die erste Variante find ich persönlich auch besser, aber "Das Erste HD" ist kein repräsentativer Sendernahme, ich wette "Servus TV Deutschland HD" läuft schon ohne Logo hinten raus.

btw. kann ich im laufenden Betrieb das skinfile nach Änderungen neu einlesen? - ist blöd wenn du jedesmal den vdr neu starten musst... Beim graphtft kann ich das über ein svdrpsend Kommando

Zitat von CKone

aber "Das Erste HD" ist kein repräsentativer Sendernahme, ich wette "Servus TV Deutschland HD" läuft schon ohne Logo hinten raus.

Viele Sender bekommen es hin auch alternativ nen kurzen Namen mitzusenden, ferner kann der Name auch scrollen. Damit kommt man auch hin.

Zitat von CKone

btw. kann ich im laufenden Betrieb das skinfile nach Änderungen neu einlesen?

Leider nicht, und das proxy Plugin (Plugins im laufenden Betrieb neu starten) geht mit graphlcd leider auch nicht.

Aber zum Entwickeln kann man sich mal schnell ne order.conf erstellen (wenn das verwendetet VDR Startscript das nutzt) erstellen wo alle überflüssigen Plugins deaktiviert sind, dann ist der VDR ja schnell geststartet.

cu

Zitat von wastl

die nicht fuer den start notwendigen libraries gehoeren nach /usr/lib (system, distro) bzw. /usr/local/lib (selbst kompiliert). dort wohin auch das graphlcd-zeug hininstalliert wird.

Stimmt. Udev kennt aber nur drei Verzeichnisse für Rules.

Zitat

EDIT: woher hast du eigentlich das mit /etc == benutzerdefiniert? ich kenne /etc eigentlich nur als == konfigurationen allgemein, das _auch_ benutzerdefiniertes zeug enthaelt / enthalten kann (das meiste ist aber in der regel vom system bzw. von systemprogrammen erstellt / angepasst).

Kommt von "man udev". Den relevanten Teil habe ich dir bereits gepostet. Der Bereich /etc/udev/rules.d ist laut manpage von udev für *benutzerdefinierte* Rules. So haben die udev-Entwickler das nunmal geplant und dokumentiert.

Standards hin oder her. Mir geht es vor allem darum, dass es die udev-Entwickler nunmal so dokumentiert haben und alle mir bekannten Projekte ihre Rules auch nach dieser Vorgabe platzieren. Ich persönlich habe das, was zusammengehört, gerne auch an ein und demselben Ort.