[ANNOUNCE] graphlcd 0.1.6

Die Antwort von randy habe ich auf die Schnelle falsch verstanden und hatte auf die Schnelle auch nicht die Möglichkeit den Quellcode zu prüfen.

Auch der "V1"-Patch von hier:
http://www.vdrportal.de/board/…?postid=780666#post780666
ist *nicht* integriert. Ich habe die Aussage von randy so verstanden, dass er den V1-Patch übernommen hat und die einige Zeit später gefolgte V2 nicht bemerkt hat. Aus diesem Zusammenhang hatte ich mich unberechtigterweise etwas geärgert, dass ein fehlerhafter Patch (scheinbar) unkontrolliert übernommen wurde. Wie gesagt: Mein Fehler.

Der Patch aus obigem Link lässt sich ohne Probleme auch auf die 1.6 patchen. Kann also noch verwendet werden. Da der Patch eine gewisse Komplexität hat, wäre es nicht verkehrt den Patch vor dem Übernehmen genauer zu betrachten. Wo der Memory-Leak lag und wie er gefixt wurde, das habe ich verstanden. Nicht ganz klar komme ich mit dem doch etwas komplexen Algorithmus zum Zerlegen der UTF-8 Strings.

randy: Warum verwendet ihr eigentlich kein GIT oder ähnliches? Hätte mir beim schnellen Prüfen des Codes doch sehr geholfen und ist auch für die Community nett, wenn man verfolgen kann, was wann gemacht wird.

Schau doch mal auf vdr-developer nach......

Schön... Aber was ist denn oben rechts los?

Werd ich mir wohl doch mal ein L4M holen müssen...

woohaa
<edit>
in den git-repos habe ich es noch nicht gefunden, darum wohl auch das 'teaser' in deinem post.

oops. man sollte das testbild genauer anschauen. dann wuerde man sehen, dass das noch 'mitten in der entwicklung' ist
</edit>
kannst du mir das mal schicken? haette ein paar farbdisplays (u.a. ein OLED, wo farbausgabe ja s**geil ausschauen sollte).
und ideal zum testen sollte freilich die SDL-ausgabe sein.

werde jetzt auch wieder etwas mehr tun (nach urlaub + neuem rechner).

/wastl

ergaenzung:
habe mir btw einen displaylink-adapter zugelegt. den will ich als naechstes einbauen in meine lib (falls brauchbar in sachen performance).

laesst du eigentlich die XML-skins wie sie waren? (ausser natuerlich mit zusaetzlichem erweitertem 'color'-parameter)

wie ist dann die farbe zu konfigurieren? color="rgb(rrggbb)" ? interessant waeren hier auch farbvariable.
(a la:
variable id="Colour1" value="rgb(471100)">

<rectangle ... color="#Colour1">
)

oder so (grad gesehen, dass bei verwendung v. #471100 fuer einen farbwert die bedeutung des '#' zweideutig werden wuerde ...)

/wastl

Wird das auch Framebuffer unterstützen? Fände ich ja eine super Alternative zum graphTFT. Das bringt meinen VDR nämlich bei einigen Aktionen zum Absturz. Wenn ich z.B. die Programminfo der aktuellen Sendung anschaue kackt der VDR ab. Rufe ich danach die EPG Info nochmal auf ist dann alles OK. Mach ich das am nächsten Tag stürzt VDR wieder ab usw. Ist also irgendwie en langzeit-Problem. Und der Grafikaufbau bei langen Menüs (Setup Menü von Skinelchi z.B.) ist auch grottig lahm. Früher hatte ich ein 128x64 SW LCD mit graphLCD. Das lief wesentlich geschmeidiger. Freue mich schon auf die erste Testversion!
Mach es bitte bitte nicht so komlex wie graphTFT. Halt es einfach und schnell wie es jetzt ist.

Zitat

Original von xnalpf
Mach es bitte bitte nicht so komlex wie graphTFT. Halt es einfach und schnell wie es jetzt ist.

Volle Zustimmung! Den Satz kann ich nur dreifach unterstreichen! Manchmal ist weniger einfach mehr!

komplex ist relativ. ich faende wie gesagt die xml-basierten skins, die powarman fuer 0.2.0 eingefuehrt hat (bzw. angefangen haette), genial. wenn einer xml nicht leiden kann dem moege das ganze vielleicht zu komplex erscheinen. ich finde es sehr flexibel und dennoch relativ einfach beherrschbar. ausserdem ist schon sehr viel vorarbeit geleistet. ein paar erweiterungen vielleicht noch, aber man kann bereits jetzt sehr viel damit machen.
und framebuffer-support hat ja nix mit der erweiterung zu tun, die randy gerade vornimmt ...

/wastl

Zitat

Original von wastl
komplex ist relativ. ich faende wie gesagt die xml-basierten skins, die powarman fuer 0.2.0 eingefuehrt hat (bzw. angefangen haette), genial. wenn einer xml nicht leiden kann dem moege das ganze vielleicht zu komplex erscheinen. ich finde es sehr flexibel und dennoch relativ einfach beherrschbar. ausserdem ist schon sehr viel vorarbeit geleistet. ein paar erweiterungen vielleicht noch, aber man kann bereits jetzt sehr viel damit machen.
und framebuffer-support hat ja nix mit der erweiterung zu tun, die randy gerade vornimmt ...

/wastl

Fullack. Ich hab auch mit xml kein Problem. Nur wenn ich mir z.B. anschaue, dass graphTFT für das Music Plugin eine Sonderlocke dreht nur, damit das Skining erhalten bleibt denke ich halt, dass da zu viel des Guten getan wird. Es entstehen Abhängigkeiten insbesondere von anderen Plugins und deren Versionen, die einen erheblichen Mehraufwand bei der Pflege des Systems bedeuten.
Manch einer wird jetzt vielleicht sagen - hey, ist doch nix dabei. Du holst dir halt nicht den aktuellen Source von einem Plugin sondern von dreien und machst dann einmal make plugins und fertig.
Das ist so einfach aber nur bei Leuten, die ihren VDR aus Sourcen zusammenbauen (was für mich zutrifft aber trotzdem...)
Gerade die Einsteiger mit ihren binär bezogenen VDRs stehen dann plötzlich aussen vor, nur weil eben ein bestimmtes Plugin für ihre VDR-Distro nicht in der richtigen Version vorliegt.
Und wenn dann noch bestimmte Patches dazu kommen wird es dann irgendwann auch für die Sourcenstricker komplex.

Hallo,

ich hatte vor etwa einer Woche die Sourcen von graphlcd-base und vom vdr-graphlcd-Plugin aus dem Git geholt, um Gentoo Ebuilds dafür zu bauen, die ich dann auch an hd_brummy weiter leiten werde, geholt. Nun, ich stellte auch fest, was andere in diesem Thread gemeldet hatten, dass irgendwelche wichtige bis "nice-to-have" Patches noch fehlen, und seit ich diese Sourcen aus dem Git geholt habe, bis heute, wenn hat sich daran nichts geändert. Ich möchte keineswegs die Arbeit derer Ihr Euch angenommen habt schlecht reden, denn ich weiß sehr wohl wie das mit der Freizeit ist (geht mir auch so).
Ich möchte nur mithelfen, da ich eh' in letzter Zeit einiges an Bestandsaufnahme existierender, noch benötigter Patches für 0.1.6 sowie auch Valgrind-Analyse und Verbesserungen am Treiber meines eigenen Displays gemacht habe. Bis zum Probieren von 0.2 seitens Waghalsiger zu denen auch ich gehöre dürfte noch ein bisschen Zeit vergehen, auf der neuen Projektseite finde ich noch keinen Hinweis auf die neuen 0.2-er Branches, von daher würde ich Euch dankbar sein, wenn Ihr die fehlenden Patches in einer baldigen 0.1.7-er Version übernehmen würdet, ich denke damit müssen wir noch einen Weile auskommen, und ein neues Release der "alten" Variante würde vielen Normalusern wie auch Packagern das Leben einfacher machen, und Euch auch Feedback auf eine konsistentere Basis liefern...
Nun zu den Patches. Ich habe mal auf meinem Webspace nochmal alle hinterlegt und liste sie nochmal hier auf, auch wenn einige schon in diesem Thread oder verlinkt auf andere schon mal vorkommen:

1. für graphlcd-base-0.1.6.20100408:

• unbedingt der UTF-8 Patch V2 (anscheinend von DarkMike), weil er wirklich Bugs beseitigst, die ansonsten z.B. den LCDproc-Metadriver "glcdlib" welcher von graphlcd-base unterstützte displays auch LCDproc zur verfügung stellt, zum Absturz bringen;
• weitere, von mir mit Valgrind aufgespürte und beseitigte Memory-Schlampereien
• Verbesserungen am Treiber meines Noritake 800(A) Displays;
• gu256x64-355.wiring.diff ([geloest] graphlcd und gu256x64-355 neues wiring .. wer kann das machen?);
• Eine Bitte für Gentoo das Stripping abschaltbar zu machen (leichte Änderung an hd_brummy's Patch welches seit langem im Gentoo-Repo verwendet wird).

2. für vdr-graphlcd-0.1.6.20100408:

• unbedingt der UTF-8 Patch aus dem Gentoo-Repository (ohne den schmiert immer noch VDR ab);
• eine um das LCR-Service erweiterte Variante des Radiotext-Plugins
• Der Frames-Patch von TomJoad auf der ersten Seite dieses Threads;
• Ein Patch aus dem Gentoo Repository zur Unterstützung des Span-Plugins (welcher ursprünglich anscheinend von Christian Leuschen, dem Autor des Span-Pugins stammt, danke mreimer für den Hinweis).

Auch wenn mit all diesen Patches nun alles nahezu perfekt läuft (im Vergleich zu den Abstürzen generell, und speziell den Timing-Problemen bei meinem Display), habe ich immer noch folgendes Problem: Immer wenn ein Sender mit EPG-Infos auf dem Display angezeigt wird, ist der Sendername schlecht gerendert, egal ob ein Logo dabei ist oder nicht, sobald ich auf einem ohne EPG-Daten schalte, erscheint der Name korrekt gerendert. Genauso wird Text aus "Popup"-Meldungen oder generell das Menue korrekt gerendert, ich habe da mal ein animiertes GIF angehängt, welches ich mittels des "image"-Displays von graphlcd, eingestellt auf 128x64 wie mein Noritake 800A erstellt habe. Weiß da jemand Rat oder Patch ?

Gruß,
Lucian

Wenn ich mich nicht irre, dann kommt der SPAN-Patch direkt aus dem SPAN-Plugin. Dort findet sich sicher auch ein Hinweis auf den Original-Autor um ihn entsprechend im Changelog zu erwähnen.

Die Bitte diesen Patch aufzunehmen kann ich nur unterstreichen. Ist wirklich nett, die kleine Visualiserung auf dem LCD

Hi,
wie wäre es Zoolook als Entwickler aufzunehmen?

Die neue gepatchte Base fänd ich auch interessant, sollte ja auch mit 0.2 tun...

mfG,
Stefan

Zitat

Originally posted by SurfaceCleanerZ:
wie wäre es Zoolook als Entwickler aufzunehmen?

Vorweg, wenn Ihr damit einverstanden seid ;)...
Gruß,
Lucian

ich glaube, du hast den leichten, in zynismus versteckten, unmut v. randy nicht mitbekommen.

vor 0.1.6 wurden patches gesammelt. all die, die beim durchstoebern gefunden und an randy herangetragen worden sind, wurden von ihm integriert (bis auf den unrund-patch, weil der einer erweiterung (=konfiguration) bedarf und darum ist er wohl auch als issue mit status 'feedback' gefuehrt).

zzt. nimmt er sich den colormode fuer die basis (interessant fuer plugin version 0.1.6 und 0.2.0) und plugin v 0.1.x vor, dann koennen die weiteren patches hineingezaubert werden. wenn jetzt da parallel entwickelt und herumgepatcht werden wuerde, wuerde es dann wohl irgendwann mal sehr spannend werden (hint: merging ...).

darum: gemach gemach.

/wastl

ergaenzung:

in deiner patch-liste sind btw. sehr interessante dinge zu finden. das mit radiotext und spectrumanalyzer muss ich ja glatt mal ausprobieren. von denen hoere/lese ich hier zum ersten mal ...