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
Wenn Du meine Patch von hier nimmst, geht das im laufenden Betrieb über
svdrpsend plug graphlcd CONNECT ax206dpf
Damit wird das Display - wenn es schon angeschlossen war - dis- und gleich wieder connected. Das ist wie ein Restart, Skin wird neu eingelesen.
Gruß
superelchi
CKone: die bildgroessen koennen zur laufzeit ausgewertet werden (bin mir aber nicht 100% sicher, kann das aber erst am abend verifizieren). dann koennte man einen skin so anpassen, dass beliebige logos angezeigt werden (sinnvollerweise nur logos, die in der breite variieren (nicht in der hoehe)), da auch berechnungen fuer x/y/width/height mittlerweile zur laufzeit durchgefuehrt werden, sollte auch die breite des text-elements fuer den sendernamen abhaengig vom logo bemessen werden koennen. dh. ein sauber erstellter skin (mit entsprechend relativen angaben) sollte sich auf unterschiedliche logos anpassen koennen.
naja, der logosatz den wir vom anthra haben der ist schon insofern homogen 260x146, dass alle Logos dieselben Abmaße haben. ich fänd zwar schmalere logos besser, hab aber auch keine Lust einen zweiten Satz zu pflegen. Im graphtt benutze ich die auch.
Die Frage die sich da stellt, ist ab man die Dinger auf den genau pasenden Wert kleiner skalieren muss oder ob man dem Skin sagen kann stell mir das logo in zum Beispiel in 96x48 dar. Das würde die Pflege des Logosatzes natürlich noch einfacher machen. weil eins ist klar: wenn da erstmal nur jedes dritte Logo angezeigt wird ist der Effekt weg...
Wenn Du meine Patch von hier nimmst, geht das im laufenden Betrieb über
Codesvdrpsend plug graphlcd CONNECT ax206dpf
Damit wird das Display - wenn es schon angeschlossen war - dis- und gleich wieder connected. Das ist wie ein Restart, Skin wird neu eingelesen.
Gruß
superelchi
danke dir, das werd ich wenn ich mir den skin anschaue gerne verwenden.
Könntest du mir noch kurz sagen wie du die Empfangswerte da reingezaubert hast Superelchi, weil in dem Beispieltheme was dabei ist kann ich das nicht sehen?
Christian
Könntest du mir noch kurz sagen wie du die Empfangswerte da reingezaubert hast Superelchi, weil in dem Beispieltheme was dabei ist kann ich das nicht sehen?
Steht in der README vom Plugin: Du musst femon patchen, dann gehts ganz von selbst...
Gruß
superelchi
Der nächste Versuch mit den Logausgaben.
BTW: Was hälst du von der Idee graphlcd-base einen Logprefix mitzugeben? Weil diese Ausgaben tauchen so ganz ungetagt im VDR Log auf. Das erschwert einwenig das Filtern (ich lasse z.B. aktuell alle graphlcd Logausgaben in nen extra Log leiten damit ich nicht lange suchen muss).
BTW2: Das hast du gesehen? [ANNOUNCE] graphlcd (base, vdr-plugin) touchcol branch
BTW3: superelchi, der connect/disconnect Patch ist cool (hatte ich total übersehen), funktioniert hier super mit meinen beiden Displays, in Verbindung mit zwei gleichzeitig laufenden Plugin Instanzen kann man hier lustig hin und herschalten und die Skins neu laden.
cu
PS: Ja, ich habs einwenig extrem mit dem Logging 
Steht in der README vom Plugin: Du musst femon patchen, dann gehts ganz von selbst...
Gruß
superelchi
OK, ab femon 1.7.7 solls ja auch so gehen, ich denke ich mach parallel bei yavdr ein ticket auf damit das Paket aktualisiert wird, dann haben alle was davon.
OK, ab femon 1.7.7 solls ja auch so gehen, ich denke ich mach parallel bei yavdr ein ticket auf damit das Paket aktualisiert wird, dann haben alle was davon.
Wofür? Wir haben 1.7.10.
Gerald
Wofür? Wir haben 1.7.10.
Gerald
ups, war bei bei 1.7.1 .... sorry, verlesen
Ich bin mal wieder einwenig am Skin basteln. Und wenn ich da nix übersehen habe ist da noch nen Bug.
<list x1="0" x2="239" y1="0" y2="100">
<item height="FontLineHeight('FontMenuItem')"/>
<rectangle x="0" width="239" y="0" height="FontTotalHeight('FontMenuItem')" color="magenta" filled="yes" condition="{IsMenuCurrent}"/>
<text x="0" y="0" width="239" height="FontTotalHeight('FontMenuItem')" color="green" font="FontMenuItem">
{MenuCurrent}
</text>
<text x="0" y="0" width="239" height="FontTotalHeight('FontMenuItem')" color="yellow" font="FontMenuItem">
{MenuItem}
</text>
</list>Der mangenta Balken wird über den kompletten Screen gemalt (also bis an den unteren Rand). Sinn der Sache ist hier natürlich das der gewählte Menüpunkt farbig hinterlegt ist (Test Background geht nur soweit wie Text vorhanden ist).
cu
ich habs mir noch nicht angesehen, aber probier bei solchen faellen bitte folgendes:
height="add(0,<ausdruck, der problem macht>)", zb. height="add(0,FontTotalHeight('FontMenuItem'))"
Nein, leider hilft das auch nicht. Die Farbe stimmt dann auch nicht, aber das angehängte Minimalskin zeigt das ja deutlich.
cu
du solltest dich mal entscheiden, was du willst:
zuerst faehrst du mir, wie man so schoen sagt, 'mit dem arsch ins gesicht', wirfst mir vor, dass ich ganz grauslich gegen alles verstosse, die guten sitten missachte und fast den 3. weltkrieg heraufbeschwoere und forderst, dass ich mich gefaelligst an die LSB halten soll.
Sorry, falls das so rübergekommen ist. Ich dachte, dass das Verhalten von udev zur FHS passt.
Mir ist es nur aufgefallen, dass du in dem Bereich, der eigentlich für "benutzerdefinierte" Rules gedacht ist, statische Rules installierst. Ich habe selber schon mit udev gearbeitet und so einige Rules erstellt. Auch welche, die deutlich mehr tun, als ein paar Rechte zu biegen. Da ich mich vorher intensiv mit der Doku befasst habe, ist mir halt sofort aufgefallen, dass da was nicht stimmt und wollte dich darüber in Kenntnis setzen, in der Hoffnung, dass man hier auf die allgemein akzeptierte Lösung umstellen kann. IMHO ist es wenig sinnvoll sich gegen solche Vorgaben zu stellen. Solange niemand die Leute, die udev entwickeln, dazu bekehrt, ihre Pfade zu ändern (IMHO wenig erfolgversprechend) sollte man sich an die Doku halten, dass nicht jeder woanders installiert. Mir gefallen auch die tollen Ideen von freedesktop.org zu Pfaden von Config-Dateien im $HOME *überhaupt* nicht. Damit abfinden muss ich mich aber trotzdem.
Da ich aber so langsam die Hoffnung verliere, dass wir uns einigen, werde ich mich in Zukunft aus diesem Thread raushalten.
Hat nix mit "Beleidigt" zu tun. Konkrete Beispiele hättest du früher bringen sollen Ich befasse mich viel mit Linux und irgendwann nimmt man gewisse Zusammenhänge als "gegeben" an, aber man kann eben nicht alle Distributionen kennen. Wie genau welches Paket tickt erschließt sich auch nicht immer direkt, wenn der Distributor in seinen Build-Scripten Anpassungen macht.
Was hast du für eine Distri. Würde mich an der Stelle doch mal interessieren. Bei mir unter Slackware ist unter /etc/udev/rules.d nicht allzuviel:
/etc/udev/rules.d$ ls
70-persistent-cd.rules 70-persistent-net.rulesAlso habe ich mal gebohrt und geschaut wie das bei Slackware bei hplip gemacht wird:
make install DESTDIR=$PKG rulesdir=/lib/udev/rules.d || exit 1Wenn ich dein Makefile nicht falsch verstehe, dann ist ähnliches bei graphlcd machbar? Lediglich die Variable heißt anders. Wenn man "UDEVRULESDIR" überschreibt, sollte das von mir gewünschte machbar sein? Damit könnte ich dann gut leben, denn letztlich werde ich ohnehin ein Paket erstellen, um das später auch einfach aktualisieren und/oder löschen zu können.
Hat jemand das hier diskutierte graphlcd(base|plugin) schonmal mit einem ks0108-LCD getestet? In meinem aktuellen VDR habe ich so eines. Wird aber bald ersetzt. Nicht nur das LCD sondern der ganze VDR. Der neue hat ein SDC USB LCD. Wenn ein Tester für das ks0108 gebraucht wird, dann müsste ich das also alsbald möglich angehen, bevor der alte VDR in Rente geht.
Hm, kommt jetzt einwenig spät (habs vorher irgenwie nicht so bewust wahrgenommen)... aber bei base hat ein älterer Commit was kaputgemacht (bin gerade schrittweise zurückgegangen bis es wieder ging). Siehe Screenshot.
a1e556cd 19.06.2011 20:26 mrwastl more efficient text drawing
7b7cc886 19.06.2011 13:21 mrwastl alpha channel: now texts with font effects are fully supported too
Edit Das Problem aus Post 489 ist mit dem Commit reingekommen
--
21d15ba6 09.07.2011 13:48 mrwastl position (x/y/x1/y1/x2/y2) and dimension (width/height) parameters are now evaluated at run time
--
cu
Hi,
die Abstürze des VDR beim Connect auf ein nicht vorhandenes Display hatte ich auch schon gemeldet! Passiert beim t6963c auch immer!
@MReimer: http://www.linuxtv.org/vdrwiki…_colour_representation.29
ks0108 Tester ist wohl noch nötig
Würde ja mit dem t6963c auch testen, aber derzeit ist easyvdr 0.9 noch nicht so weit
Wobei. Ich könnte die base vom yavdr-Repo nutzen, sollte ja tun und dann nur das Plugin bauen... Mal sehen Montag...
mfG,
Stefan
OK. Dann werde ich bei Gelegenheit mal meine Build-Scripte so umstricken, dass die den neuen Branch bauen. Wie gesagt: Testen kann ich nur noch wenige Tage. Allerdings habe ich noch ein ks0108 mit Aufsteller, das ich extern am neuen VDR anstecken kann. Wenn hilfreich kann ich also auch mit dem neuen VDR noch testen.
Vorteil vom ks0108 ist halt der kleine Preis. Bei Pollin gibt es die Dinger für 20 EUR. Wundert mich eigentlich, dass hier nicht mehr mit so einem Display unterwegs sind, denn für 20 EUR bekommt man ein wirklich brauchbares Teil, das mit relativ wenig Lötaufwand im VDR läuft.
Falls es nicht tut, melde ich mich wieder hier. Notfalls kann ich auch ein bisschen C++, aber irgendwo stoße ich mit meinen eher grundlegenden Kenntnissen dann sicher auf Grenzen.
Wundert mich eigentlich, dass hier nicht mehr mit so einem Display unterwegs sind, denn für 20 EUR bekommt man ein wirklich brauchbares Teil, das mit relativ wenig Lötaufwand im VDR läuft.
Naja 128x64px ist auch etwas mickrig.
Wenn noch mehr Tester für das t6963c nötig sind, könnte ich mich da auch noch anbieten.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!