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

Zitat von wastl

dazu faellt mir eigentlich nur das ein:

Zitat von wastl

http://german-bash.org/25341

Zitat von wastl

Na gut, bleibt es bei mir hängen :D. Oder meintest du Keine_Ahnung?

Gerald

Zitat von gda

Wir bemühen uns eigentlich keine yaVDR-Dinge in die Pakete einzubauen, die nicht mit yavdr anfangen.

Aber die Packetsachen (d.h. das debian Unterverzeichnis mit den Steuerdateien zum Packetbau) sind doch ganz allgm. zum bauen der Debian Packete (hat halt erstmal nix mit yaVDR zu tun). Die Frage war halt ob es nicht schöner wäre das gleich ins GIT zu packen so das nicht jede Packetquelle (e-Tobi, yaVDR oder ganz einfach ich (oder viele andere die die Quellen nutzen) auf meinem System) das selber einpflegen muss?

Nur halt die yaVDR spezifischen Sachen (irgendwelche yaVDR Hooks im Install aufrufen oder sowas) da rauslassen falls sowas für dieses Packet notwendig wäre (aber vermutlich brauchts hier ja überhaupt keine yaVDR spezifische anpassung).

cu

Zitat von Keine_Ahnung

Aber die Packetsachen (d.h. das debian Unterverzeichnis mit den Steuerdateien zum Packetbau) sind doch ganz allgm. zum bauen der Debian Packete (hat halt erstmal nix mit yaVDR zu tun).

Die wenigen Quell-Archive bei denen dass der Fall ist, gefallen mir meistens gar nicht. Die debian-Verzeichnisse sind oft schlecht gepflegt und ein begnadeter Entwickler muss noch lange kein guter Paketbauer sein.

Gerald

Sorry, dafür habe ich im Moment keine Zeit. Ich dachte eigentlich ein diff zwischen einem frischen Verzeichnis und einem nach make all make clean sollten reichen. Es waren auf jeden Fall mehr als nur .o und .so Dateien. Da waren auch ein paar .pc Dateien, ein Header, doxygen-files.

Wenn ich das nächste mal ein Paket baue, dann schicke ich dir die Dateien, okay?

Gerald

So, das Pearl Packet mit dem Display ist gerade gekommen...

Graphlcd lief mit der aktuellen GIT Version OOTB ohne irgendwelche Probleme (das erstmal als Feedback). Wer auf der Suche nach nem Display ist (einfach um eines zu haben, oder ums einfach ins kleine Gehäuser einzubauen) sollte sich das auf alle Fälle mal anschauen, es ist erstmal extrem billig (gab sogar nen hübschen Funkwecker umsonst dazu ), per USB sofort anschlussfertig, hat nen halbweg hübsches Gehäuse und ist von der Displayquallität top (keine Probleme mit seitlichen Ablesen). Ich bin erstmal spontan begeistert, da macht grapphlcd mit seinen tollen Farbfeatures doch gleich sehr viel mehr Spaß als mit dem ollen S/W Display

Einzig die winzigen Abmessungen stören. Und es ist sehr langsam, wobei man das auch als gewollten Slideshoweffekt betrachen könnte

BTW: Wer bei hacken Probleme mit USB Resets hat, einfach mal nen Hub dazwischenstecken bevor man mit dem Googeln nach "Linux+USB Problemen" anfängt

cu

Was die Geschwindigkeit angeht: bin gerade dabei das zu optimieren. Momentan werden bei Teil-Refreshs noch unnötig viele Daten an das Display übertragen. Hilft natürlich nicht wenn der komplette Displayinhalt sich ändert. Aber immerhin...
Kommt auch noch ein bisschen mehr an Features (Stichwort: mehrere Displays zu einem Großen zusammenschalten).

Gruß
superelchi

Zitat von superelchi

Was die Geschwindigkeit angeht: bin gerade dabei das zu optimieren. Momentan werden bei Teil-Refreshs noch unnötig viele Daten an das Display übertragen. Hilft natürlich nicht wenn der komplette Displayinhalt sich ändert. Aber immerhin...

Würde vermutlich dann das Textscrollen optimieren.
Bei der kompletten Änderung (Normalansich->Menü) ist das mit dem seitlichen reinschieben garnicht so schlimm. Sieht wirklich so aus wie nen gewollter Effekt.

Zitat von superelchi

Kommt auch noch ein bisschen mehr an Features (Stichwort: mehrere Displays zu einem Großen zusammenschalten).

Bekommt man die übergangslos zusammen (wenn man das Gehäuse abnimmt)?

Wobei man auch einfach mehere graphlcd Instanzen laufen lassen kann um auf meheren Displays unterschiedliche Infos anzeigen zu lassen. Ich überlege auch schon ob ich mein S/W dranlasse und das Pearl als zusätzliche Logo-/Infoanzeige dazuschalte.

cu

Zitat von Keine_Ahnung

Bei der kompletten Änderung (Normalansich->Menü) ist das mit dem seitlichen reinschieben garnicht so schlimm. Sieht wirklich so aus wie nen gewollter Effekt.

Du hast die Portrait-Firmware drauf? Dann schiebt er standardmäßig von rechts nach links rein. Wenn Du es gerne von links nach rechts hättest kannst Du den Config-Parameter "UpsideDown=yes" setzen (dann empfiehlt es sich allerdings das Display um 180° zu drehen ).
Wenn Du die Landscape-Firmware draufmachst, schiebt es standardmäßig von oben nach unten.

Zitat von Keine_Ahnung

Bekommt man die übergangslos zusammen (wenn man das Gehäuse abnimmt)?

Nein, geht wohl nicht. Soweit ich mich erinnere, ist die Platine ist etwas größer als das Display. Aber hey - wir sind im Skin-Thread! Vielleicht macht ja jemand ein Skin, dass die Infos sinnvoll auf die einzelnen Display verteilt?

Zitat von Keine_Ahnung

Wobei man auch einfach mehere graphlcd Instanzen laufen lassen kann um auf meheren Displays unterschiedliche Infos anzeigen zu lassen.

..oder so. Kann man die auch über das VDR-Menü steuern?

Gruß
superelchi

Zitat von superelchi

Du hast die Portrait-Firmware drauf?

Genau. Na dann hat man ja alle Möglichkeiten.

BTW: Das Plugin 2x starten (mit verschiedenen Pluginnamen) geht doch nicht *), vermutlich verkraften die Libs das irgendwie nicht (nicht Threadsicher?). Aber detaliertere Spekulationen überlasse ich denen die die intenen Abläufe da besser verstehen.
Aber das nur mal zur Info, nen Bug ist es ja nicht weil sowas ja wohl nie vorgesehen war.

Aber was mir im zuge dessen Auffiel, in plugin.c wird kPluginName mit nem konstanten String (halt dem Pluginnamen) belegt obwohl das Makefile schon PLUGIN_NAME_I18N liefert. IMHO wäre es gut es nur einmal konstant zu definieren (halt im Makefile).

cu

*)
--
Aug 12 22:53:39 localhost vdr: ERROR: graphlcd/skin: No child tag font expected within condblock
Aug 12 22:53:39 localhost vdr: ERROR: graphlcd/skin: Parse error in /dev/shm/.vdr/vdr/config/plugins/graphlcd1/skins/touchcol/touchcol.skin, line 7
--
Starte ich es alleine dann gehts.

So, habe gerade mal mit nem HEX Editor gespielt... wenn man die drei Base Libs kopiert (Namen ändern) und die Pluginkopie dazu überredet die Kopien zu laden, dann gehen zwei Displays gleichzeitig.

BTW, mal ne Idee die vermutlich Polarisiert Mit nem bisschen Makefile/Preprocessor Magic sollte es möglich sein das man in make.config|global "GRAPHLCDMULTI=pollin sdc" setzt und dann die enstprechende Anzahl von Pluigns und Base Lib Sätzen automatisch erzeugt wird.
Es dürfte zwar nur wenige geben die das dann nutzen, aber der Aufwand hält sich in Grenzen und man hat die Möglichkeit. Und sei es nur weil man mehere Displays vorrübergehend zum spielen dran hat.
Wenn sich da kein Widerstand regt würde ich nen Patch dafür fertigmachen.

cu

Und hallo nochmal

Ich habe mal einige Kleinigkeiten gemacht die ich als Codeaufhübscherei betrachte, das ist unabhängig von der vorheriegen Idee IMHO ne gute Sache, ferner ist es alles was im Quellcode notwendig ist um die obrige Idee umzusetzen (der Rest ist Makfile). Ist alles reiner Preprocessorkram und nix wildes.

1. Wird beim Logging generell "<PLUGIN_NAME_I18N> plugin: " vorangestellt (bei einigen fehlte auch das " plugin" im Text was das Logfiltern erschwerte), ferner fällt dardurch kPluginName weg (wurde eh nur in ConfigDirectory() verwendet).
2. Die svdrp Rückgabetexte sind Pluginnamen/Displaytechnik unabhängig
3. Der default Configfile String ist ins Makefile gewandet weil sowas im Quellcode IMHO sehr unschön ist.
4. Das default Configfile wird auch im Paramterhilfetext dementsprechend gesetzt (kann also im Makefile problemlos geändert werden)

cu

Bin gerade dabei den Treiber zu optimieren. Dabei sind mir ein paar Dinge aufgefallen:

Wie Keine_Ahnung ja schon sagte, ist der Display-Refresh nicht gerade der schnellste. Daran kann mann wohl nichts ändern. Ich versuche jetzt nur die Daten zu übertragen, die sich seit dem letzten Refresh() Aufruf geändert haben. Dazu baue ich mir in SetPixel() ein Dirty-Rectangle - also kleinste/größte Koordinate seit dem letzten Refresh() merken. Das klappt aber nicht, da auch bei der Änderung nur eines kleinen Bereichs immer der komplette Bildschirminhalt neu aufgebaut wird, d.h die SetPixel() Routine wird nach einer Änderung immer (width * height) Mal aufgerufen. Das sind bei dem Pearl-Display immerhin 320 x 240 = 76.800 Aufrufe. Okay, ich werde also das Ganze über einen doppelten Bildschirmbuffer lösen müssen, für den in in Refresh() einen Vergleich Alt <-> Neu gemacht und daraus das Dirty-Rectangle berechnet wird. Fände es allerdings im Sinne von verbratener Prozessorzeit und Resourcenverbrauch sinnvoller, nur geänderte Bereiche mit SetPixel() neu zu setzen. Nur so als Denkanstoß...

In der ersten Version des Treibers habe ich das Setzen der Displayhelligkeit über SetBrightness() nicht implementiert, da es dabei hin und wieder zu Abstürzen des Displays kam. Hab das mal etwas genauer untersucht und rausgefunden, dass hier anscheinend zwei Threads gleichzeitig was von dem Treiber wollen. Während ein Thread Refresh() aufruft, versucht ein anderer gleichzeitig SetBrightness() aufzurufen. Da beide Routinen dann gleichzeitig versuchen mit dem Display über USB zu kommunizieren (und die libpdf aus dem Hack nicht threadsicher ist ) machts PENG! Hab ich über Mutex gelöst. Wollte nur drauf hinweisen - vielleicht sollte man das irgendwo erwähnen, dass ein Graphlcd-Treiber threadsicher sein muss.

Gruß
superelchi

Hi,
guck dir doch mal den Treiber t6963c an, der kann nur geänderte Bereiche übertragen, evtl. ists dort schön gelöst?

mfG,
Stefan

Ja, der t6963c-Treiber macht es genau so. Alles was über SetPixel() kommt in einen Buffer schreiben und in Refresh() mit den Daten des letzten Refreshs vergleichen. So werde ich es wohl auch machen müssen. Ändert aber nichts daran, dass wenn sich z.B. beim Springen im Menü nur der Cursor von vielleicht 10 x 10 Pixel ändert trotzdem an den Treiber 320 x 240 Pixel gesendet werden (also die erwähnten 76.800 SetPixel() Aufrufe). Nötig wären nur 2 x 10 x 10 Aufrufe. Und in Refresh() darf man dann noch einen zweiten Buffer anlegen und in einer doppelten Schleife diese 76.800 Pixel mit den letzten 76.800 Pixeln vergleichen um den geänderten 200 Pixel auf die Schliche zu kommen . Ist wohl bei den heutigen Prozessorgeschwindigkeiten und Speichergrößen keine große Sache mehr, aber irgendwie find ich das nicht optimal. Wie gesagt: nur ein Denkanstoß...

Gruß
superelchi

Kann es ein das mein blinkender Doppelpunkt in der Uhrzeit oben links dann die Sache komplett verlangsamt wenn z.B. der Sendungsname scollt? Weil dann das dirty-Retangle unnötig aufgebläht wird.
Kam mir irgendwie gerade in den Sinn, irgendwie schräg

Kann man nicht in SetPixel das Pixel direkt zum Display schicken wenn es sich geändert hat? Oder können hier nur grössere Bereiche in einen Rutsch gesendet werden und der Protokolloverhead für das Pixelweise setzen wäre zu groß?

cu