LCD Display ausschalten

Beitrag von **PauleFoul** » Montag 14. März 2005, 20:00

petgun hat geschrieben:
hannebamb(el) hat geschrieben: für mich ist es so optimal, wie es jetzt ist.
..klar, aber eine _optionale_ Abschaltung gekoppelt mit dem OSD wuerde Dich doch nicht stoeren, oder?

@Gorcon
Habs noch nicht gemessen. Mag mit 1-2W hinkommen
hmm...ich finde es jetzt nicht, aber ich bin mir sicher das ich von Dir dazu Zahlen gelesen habe...

Ok, ich hab's gefunden.... http://forum.tuxbox-cvs.sourceforge.net ... hp?t=35547 und bin entaeuscht ;-) vergesst einfach das Argument 'Strom sparen' wenn das stimmt (was ich immer noch nicht glauben kann...das sind doch 30 LED's die hell strahlen..) waren es nur 0,2W....sorry, hatte ich vergessen/verdraengt ;-)

Warum?? Im Betrieb ist es doch fast 1 Watt!!

Allerdings geht es ja nur sekundär darum Energie zu sparen.

In einem anderen Forum (Name darf hier nicht genannt werden) wird
versucht das über ein PlugIn zu lösen...
Aber Neutrino ist das ziemlich bockig und pingt immer dazwischen...

Gruß
____Paule

Beitrag von **Barf** » Mittwoch 16. März 2005, 21:40

Hallo,

Ich habe PauleFouls Vorschlag implementiert. Hier ist ein Patch für .../apps/tuxbox/neutrino/src/driver/lcdd.cpp und hier ein Patch für .../apps/tuxbox/neutrino/src/driver/lcdd.h. In diese Version gibt es noch keine Einstellmöglichkeiten, sonder das Timeout is fest in Code (15 sekunden) eingelötet. Es währe relativ leicht, in neutrino.cpp ein GUI-Zugang zu der Delayzeit zu implementieren. (Aber jemand der patchen und Kompilieren kann braucht kaum GUI

, sondern kann default_timeout in lcdd.h ändern). Bei timeout == 0 bleibt alles beim Alten.

Greetz,

Barf

Beitrag von **PauleFoul** » Mittwoch 16. März 2005, 22:09

@ Barf

Momentan wird versucht über entsprechende Änderungen im CVS
das flackern des Display in den Griff zu bekommen. Mit dem von mir
oben angesprochenen PlugIn funktioniert die Sache eingentlich schon
ganz gut, wenn eben das Flackern ab un an nicht wäre...

@All

Die Frage ist jetzt welche Lösung weiter verfolgt werden soll.

A. Das Plugin nutzen und die Probleme mit dem Flackern beseitigen.
Vor allem auch wenn das Display nicht ganz aus ist sondern nur gedimmt
wurde... Diese Problem wird ja durch die aktuelle Änderung im CVS
noch nicht behoben... Ich denke man muss durch den Schalter nur
das Schalten der Beleuchtung (EIN und AUS) unterdrücken.

oder

B. Das ganze direkt in Neutrino integrieren. Entweder ein einfaches
aus wenn OSD weg. Oder wie im PlugIn ein runter dimmen auf einen
einstellbaren Wert und die Bedienungen für Ein- und Ausschalten
konfugurierbar machen...

Gruß
____Paule

Beitrag von **ChakaZulu** » Mittwoch 16. März 2005, 22:20

Hi,

da ich endlich mal wieder ein bisschen Zeit hatte, habe ich auch angefangen, daran zu arbeiten. Allerdings war Barf da schneller...

@barf
kannst Du nochmal ein Diff gegen das aktuelle CVS machen?
In lcdd.cpp hat sich vor kurzem was geändert

Ich denke nicht, dass man durch ein Plugin die Entwicklung im CVS "behindern" sollte. Wenn es damit auch geht (oder besser), dann kann man ja das Plugin verwenden. Aber IMHO gehört das schon in Neutrino rein. Also würde ich da niemanden mit "entweder oder" konfrontieren (hält sich eh niemand dran

)

ciao,

ChakaZulu

Beitrag von **PauleFoul** » Mittwoch 16. März 2005, 22:32

@ ChakaZulu

Bitte nicht falsch verstehen... Natürlich ist eine direkt inplementierte
Funktion besser als eine aufgesetzte... Zumindestens in den meisten
Fällen...

Von mir aus können wir auch beide Lösungen verfolgen... Nur sind
ja für beide Lösungen Änderungen im CVS nötig. Hier stellt sich die
Frage ob das nötig ist...
Wenn Neutrino nicht ab und an das Display einschalten würde, wäre
die volle Funktionalität durch das PlugIn bereits gegeben.
Vielleicht kann man ja hier noch was im CVS optimieren...

"Die Made" hat ja schon erste Schritte im CVS unternehmen.
(Herzlichen Dank an dieser Stelle). Allerdings greift diese
Änderung nur bei ganz ausgeschaltetem Display und nicht
bei gedimmten, da sonst die Anzeige nicht mehr aktualisiert wird.

Gruß
____Paule

Beitrag von **ChakaZulu** » Mittwoch 16. März 2005, 22:40

Hi,

behindern war ja auch in "" gesetzt

Ich weiss nicht, was Du mit flackern meinst und welche Änderungen Du deswegen machen willst. DieMades Änderungen gehen ja glaube ich auf den TuxMail-Thread zurück...
Falls da irgendwelche Schnittstellen nach aussen über lock-Dateien gemacht werden sollen, wenn Neutrino ein OSD einblendet oder das LCD updated, dann fände ich das etwas unverständlich (oder auch krank

). Solche Dinge sind intern schöner, leichter und besser zu integrieren

Wenn ich hier rumphantasiere, dann ignoriere das am besten

ciao,

ChakaZulu

Beitrag von **PauleFoul** » Mittwoch 16. März 2005, 23:01

@ ChakaZulu

Am besten Du installierst Dir mal das Dimmer-PlugIn und probierst es
aus...

Wenn Du diese Funktionalität ins CVS integrierst applaudiere ich Dir zu...

Natürlich wäre dies die wahrscheinlich bessere Lösung.

Gruß
____Paule

@ChakaZulu

Ich finde, daß diese Funktion nicht durch ein Plugin gelöst werden sollte,
da, wie schon gesagt, Zugriffskonflikte zwischen Plugin und Neutrino
nur durch aufwändige Klimmzüge mit Lock-Dateien in den Griff zu be-
kommen wären. Es ist besser, wenn die Steuerung der Hintergrund-
beleuchtung allein in der Hand von Neutrino bleibt.
Das mit dem Plugin hatte ich nur mal so fix zusammengeschossen, um
generell erst mal das Handling zu testen.

Beitrag von **Barf** » Donnerstag 17. März 2005, 21:58

Merkwerdig, was für eine Pluginverliebtheit mann gelegentlich in diesem Forum findet -- nicht nur in diesem Thread

"If all you have got is a hammer, everything looks like a nail"

@barf
kannst Du nochmal ein Diff gegen das aktuelle CVS machen?
In lcdd.cpp hat sich vor kurzem was geändert

Es ging cirka 24 Stunden vom Auschecken, zu dem Veröffentlichung des Patches, und in der Zwischenzeit hat jemand rumgefummelt

Anyhow, der Patch (für die cpp-File) habe ich gerade aktualisiert. Gleiche Name.

Beitrag von **petgun** » Freitag 18. März 2005, 00:05

Barf hat geschrieben:Merkwerdig, was für eine Pluginverliebtheit mann gelegentlich in diesem Forum findet -- nicht nur in diesem Thread "If all you have got is a hammer, everything looks like a nail"

'Plugin-Autor' hoert sich aber doch gut an und dient vielleicht zur Bewaeltigung von Profilneurosen...ich glaube ich schreibe auch mal eins ;-)

--
...gestern war ich noch ein Script...heute bin ich ein Plugin

Beitrag von **ChakaZulu** » Freitag 25. März 2005, 19:48

Hi,

ok, ich habs mal committed und in den LCD-Einstellungen
"Dimm-Timeout" und "Helligkeit nach Timeout" eingefügt.

Dimm-Timeout == 0 -> LCD bleibt immer an, ansonsten Sekunden, nach denen das LCD gedimmt wird
Helligkeit nach Timeout == 0 -> LCD wird abgeschaltet, ansonsten die Helligkeit von 1-255 (was bei höheren Werten passiert, weiss ich nicht

).

Ich weiss jetzt wieder, warum ich das drumrumbauen von Settingdialogen hasse

ciao,

ChakaZulu

Beitrag von **petgun** » Freitag 25. März 2005, 19:58

danke! Wovon ist Dimm Timeout denn abhaengig? OSD, FB-Tastendruecke, ????

Beitrag von **PauleFoul** » Freitag 25. März 2005, 20:02

petgun hat geschrieben:danke! Wovon ist Dimm Timeout denn abhaengig? OSD, FB-Tastendruecke, ????

Das würde mich auch interessieren...

@ChakaZulu

Vielen Dank für Deine Arbeit... Freu mich schon auf den nächsten Snap...

Gruß
____Paule

Beitrag von **ChakaZulu** » Freitag 25. März 2005, 20:14

hi,

barf hat doch oben den patch gepostet

Der timeout-Zähler wird zurückgesetzt, wenn auf das LCD zugegriffen wird. Also etwa beim Aufrufen des OSD, allerdings wird z.B. die Aktualisierung des Fortschrittsbalken nicht beachtet.
Schau am besten in den Quellcode, überall wo wake_up() steht, wird das Display wieder angeworfen

ciao,

ChakaZulu

Beitrag von **petgun** » Freitag 25. März 2005, 20:23

ChakaZulu hat geschrieben:..barf hat doch oben den patch gepostet
Der timeout-Zähler...

;-) Danke fuer die Erklaerung...hoert sich gut durchdacht an...ich freu mich drauf!

Beitrag von **mb405** » Sonntag 27. März 2005, 18:04

toll, das mit den dimmen
nur eine "blöde" frage dazu. ist das für die beleuchtung des lcd so gut ? sind zwar led es, aber so rapide sprünge sind bestimmt nicht gut. kann man das noch etwas weicher hoch und runter dimmen ???

Beitrag von **petgun** » Sonntag 27. März 2005, 18:11

mb405 hat geschrieben:..sind zwar led es, aber so rapide sprünge sind bestimmt nicht gut...

das macht 100% nix aus und wirkt sich wenn ueberhaupt nur lebensverlaengernd auf die Led's aus...das sind Halbleiter die Du millionenmal/sec ein und ausschalten kannst.

Beitrag von **zexma** » Sonntag 27. März 2005, 19:25

petgun hat geschrieben:
mb405 hat geschrieben:..sind zwar led es, aber so rapide sprünge sind bestimmt nicht gut...
das macht 100% nix aus und wirkt sich wenn ueberhaupt nur lebensverlaengernd auf die Led's aus...das sind Halbleiter die Du millionenmal/sec ein und ausschalten kannst.

naja, aber obs sinnvoll ist leds im > MHz-Bereich zu takten darf ich bezweifeln (okay evtl. im kHz-bereich zur energieeinsparung)

Beitrag von **petgun** » Sonntag 27. März 2005, 19:39

zexma hat geschrieben:..naja, aber obs sinnvoll ist leds im > MHz-Bereich zu takten darf ich bezweifeln (okay evtl. im kHz-bereich zur energieeinsparung)

..uebertreiben macht deutlich ;-) Ich weiss das man zum _dimmen_ von Leds (wie sie im Display zur Hintergrundbeleuchtung eingebaut sind) sinnvollerweise einen Impulsbreitenmodulator mit einer Frequenz im khz-bereich nimmt....aber es gibt auch Leds die ein paar MHz vertragen.

Beitrag von **PauleFoul** » Montag 28. März 2005, 18:23

@ ChakaZulu

Funktioniert schon mal echt ganz gut für den ersten Schuß...

Allerdings ist der Timeout nicht an den OSD gekoppelt, sondern nur
an Tastendrücke der FB...
Ich das so gewollt??

Gruß
____Paule

Beitrag von **ChakaZulu** » Montag 28. März 2005, 18:46

hi,

wie meinst Du das? Es wird bei jedem update des LCD neu heruntergezählt. Wenn ein GUI-Element das LCD nicht updated, dann wird das ignoriert, ja. Und da man den Timeoutwert selber einstellen kann ist er auch nicht z.B. mit dem infoviewer-verschwinden gekoppelt

ciao,

ChakaZulu

Beitrag von **PauleFoul** » Montag 28. März 2005, 18:49

@ ChakaZulu

Ich dachte das es an das OSD gekoppelt wird... Wenn Du das
so gemacht hast "No prob"...
Erst einmal Erfahrungen mit der neuen Funktion sammeln...

Gruß
____Paule

Beitrag von **ChakaZulu** » Montag 28. März 2005, 19:03

PauleFoul hat geschrieben:@ ChakaZulu
Ich dachte das es an das OSD gekoppelt wird... Wenn Du das
so gemacht hast "No prob"...

das war Barf

nicht das er hier noch in Vergessenheit gerät

ciao,

ChakaZulu

Beitrag von **PauleFoul** » Montag 28. März 2005, 19:08

@ ChakaZulu

Hättest ja gleich noch einen Optionparameter einbauen können...

Gruß
____Paule

Beitrag von **Barf** » Dienstag 29. März 2005, 15:52

@PauleFoul:

Ich dachte das es an das OSD gekoppelt wird... Wenn Du das
so gemacht hast "No prob"...

Die OSD-Menus plaudern nicht mit dem lcdd. Ausserdem funktionieren die etwas albern, hier habe ich versucht es zu reparieren, aber der feedback davon ist ja ziemlich mager... Ich glaube es wäre nicht allerzu logisch, und ich weiss nicht richtig wie/falls mann es sauber machen kann. Die gewählte Implemenierung ist nur eine lokale Änderung in lcdd.*.

Ich weiss jetzt wieder, warum ich das drumrumbauen von Settingdialogen hasse

<mitleid/>. neutrino.cpp ist nicht für depressionsgefährdete. Deswegen habe ich nur die Änderungen in lcdd.* gemacht

Übrigens überlege ich mich, falls es nicht sinnvoll wäre, das "Home" den LCD-Display ranschmeißt. Was meint ihr?