Ubuntu 10.04 LTS Helligkeit im Akkubetrieb

felicia

New member
Registriert
3 Nov. 2007
Beiträge
603
[gelöst] Ubuntu 10.04 LTS Helligkeit im Akkubetrieb

Hallo,

ich habe auf meinem R60 aus der Sig. Ubuntu 10.04 LTS installiert und es läuft jetzt alles, selbst Fingerprint. Nur eine Sache funktioniert noch nicht so ganz wie ich das möchte.

Die Helligkeit ist natürlich mit FN+Pos1/Ende regelbar, Das Display wird auch beim Einstecken eines Netzteils heller bzw. beim Herausziehen dunkler.
Allerdings habe ich noch keine Einstellung gefunden, wie hell/dunkel es jeweils werden soll. Beim Herausziehen wird die Helligkeit z.B. auf Stufe 2 gesetzt, beim Einstecken anscheinend auf 5. Also, wenn man auf Netzbetrieb 0 oder 1 eingestellt hatte, wird der Bildschirm beim Herausziehen des Steckers sogar heller. Ich würde hier gern 0 und 7 haben und mir natürlich die jederzeit manuelle Einstellmöglichkeit erhalten wollen, unter Energieverwaltung gibt es aber nur die generelle Einstellmöglichkeit eines herunterdimmens auf Akku.

Hat jemand das schonmal gemacht/einen Lösungsvorschlag?
(Wie kann man skript-tauglich überwachen, ob der Netzstecker eingesteckt ist?)

danke, mfg felicia
 
Zuletzt bearbeitet:
Du musst im Bios unter Display "Brightness" auf "High" stellen - ansonsten dunkelt das Display unabhängig vom Betriebssystem im Akkubetrieb ab. Ansonsten findest du alle Ubuntu-eigenen Optionen in den Energieeinstellungen bzw. über die Bildschirmschonereinstellungen und dort Energie.
 
Hi,

die Einstellungmöglichkeiten des GNOME-Powermanager sind, sagen wir mal, unvollständig und wenig benutzerorientiert ...

Ich hatte hier eine skriptbasierte Lösung gepostet. Dabei bitte beachten, daß die Definitionen für LEVEL_AC und LEVEL_BAT angepaßt werden müssen; beim R60 dürften die Stufen nur von 0..7 gehen. Außerdem nicht vergessen wie weiter unten in Post #39 beschrieben den GNOME-Powermanager stillzulegen.
 
Viele Howto's nutzen "on_ac_power" um heraus zu finden, in welchem Powerstate der Rechner sich befindet, allerdings funktioniert das überhaupt nicht zuverlässig. Im laufenden Betrieb mag das noch funktionieren, doch wer seinen Rechner öfters mal neustartet oder gänzlich aus macht (wie ich, ein Suspend lohnt nicht, da das System in 10sek gebootet ist :) ), der wird beim Startup feststellen, dass on_ac_power nur Murx ausgibt.

Sinnvoller ist es m.E. nach, sich auf `cat /sys/class/power_supply/BAT1/power_now` zu verlassen.

Dazu habe ich mir folgendes Init-script geschrieben, was beim Bootvorgang im jeweiligen Runlevel angestartet wird und so von Beginn an den richtigen Powermodus setzt.

/etc/init.d/powerstate.sh
Code:
#!/sbin/runscript
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

depend() {
        after *
}

start() {
        ebegin "Setting powerstate"
        if [ `cat /sys/class/power_supply/BAT1/power_now` == 0 ]; then
                pm-powersave false
        else
                pm-powersave true
        fi
        eend $?
}

Eine stop-Funktion ist nicht notwendig, wichtige fand ich noch "after <all>" sprich "after *".

Brightness wie oben von linrunner beschrieben einstellen. Es sei Dir selbst überlassen, ob Du diese Einstellungen selbst durchführst und eigene komplexe Scripte schreibst oder Dich auf diese "powermanagement-scripts" verlässt.
 
@seves85: dein Gentoo-Skript ist unter Ubuntu nicht nötig (es würde auch nicht unmodifiziert laufen), da der upowerd schon alles erledigt und pm-powersave (aus dem Paket pm-utils) passend aufruft. Die "Überwachung" die felicia ansprach, erledigt bereits pm-utils indem jedesmal beim Wechsel der Stromquelle die Skripte unter /etc/pm/power.d/ mit dem Parameter false (AC) bzw. true (BAT) aufgerufen werden.

Ich habe bei on_ac_power in Ubuntu übrigens noch keine Probleme feststellen können. Dein Skript funktioniert IMHO nur auf einem ThinkPad mit fehlerhaften ACPI-BIOS (kommt z.B. bei einigen Edge-Modellen vor), denn normalerweise ist der Hauptakku BAT0. Außerdem liefert das Skript falsche Ergebnisse, wenn man gerade den Akku per /sys/devices/platform/smapi/BAT0/force_discharge bei angeschlossenem Netzteil entlädt. Ich verlasse mich da lieber auf on_ac_power ... :whistling:

ps. Sorry für's OT und Klugsch... Ich habe mich für TLP sehr eingehend mit den Zusammenhängen beschäftigt :).
 
Zuletzt bearbeitet:
Hi,

die Einstellungmöglichkeiten des GNOME-Powermanager sind, sagen wir mal, unvollständig und wenig benutzerorientiert ...

+1

so weit war ich im Übrigen auch schon ;) Das Umstellen der BIOS-Option hat am generellen Verhalten übrigens nichts geändert.

Ich hatte hier eine skriptbasierte Lösung gepostet. Dabei bitte beachten, daß die Definitionen für LEVEL_AC und LEVEL_BAT angepaßt werden müssen; beim R60 dürften die Stufen nur von 0..7 gehen. Außerdem nicht vergessen wie weiter unten in Post #39 beschrieben den GNOME-Powermanager stillzulegen.

Klasse, der Thread ist echt hilfreich, die Sufu hat ihn übrigens nicht ausgespuckt.

Weil das Skript tut was ich will, ist auch das mit der Statusüberwachung erstmal hinfällig. Falls ichs doch mal brauch, weiß ich jetzt wie. Vielen Dank an alle! mfg felicia
 
@linrunner: Mag sein das Du Dich da sehr umfassend mit befasst hast, allerdings halt nicht spezifisch auf ein Modell. Mich interessiert halt nur alles zu meinem Laptop, da ist dies der Fall, dass on_ac_power nur Müll produziert. upowerd verrichtet unter Gentoo genauso seinen Dienst und wechselt mittels pm-utils den Powerstate. Darum ging es hierbei ja auch gar nicht, sondern um den Bootvorgang. Und genau da meldet mir on_ac_power immer, dass ich AC angeschloßen habe, auch wenn kein AC dran hängt. Da fehlt halt ein ACPI-Event bzw. korrektes Auslesen/Übergeben der jeweiligen Werte. Das /sys-Interface bietet mir mehr Spielraum und ist meiner Meinung nach sicherer als irgendein Script. BAT0 ist unter tp_smapi die eigentliche BAT und BAT1 der Ultrabay. Wieso der natürlich ein Ultrabay anzeigt beim Edge ist ebenso fragwürdig... Im /sys gibt es nur BAT1, nichts anderes... Wird schon seinen Grund haben.

Warum das unter Ubuntu nicht laufen soll, müsste man die Ubuntuler fragen. Fertig kompilierte Massenpakete und verzweigte Scripts, die nicht nötig sind, da eh alles nur echo's in die jeweiligen /sys-Folders/Files sind ist mir auch ein Rätsel.

Für mich persönlich wäre es hilfreicher, wenn es Postings im Bereich Energiesparren gäbe, in denen direkt stehen würde, welcher Befehl was bewirkt, also wieder irgend ein Script. pm-utils macht ja nichts anderes wie Dein tlp-Script. Jedenfalls soweit ich gesehen habe... Aber gut, auch unwichtig - schön Arbeit :)

Dein force_discharge bezieht sich auf den laufenden Betrieb, ich sprach wie gesagt vom Bootvorgang - da wird kein force_discharge gesetzt und falls ja, welch Schwachsinn ;)
Auf meinen Maschinen klappt das runscript hervoragend.

Aber genug, bevor man sich wegen nichts und wieder nichts an die Gurgel geht und das ewige Leid/Battle zw. Gentoo/.../.../... liefert. Jedem das seine, solang alles so funktioniert, wie man möchte :)
 
Mir ging es um den Erfahrungsaustausch über die Eigenheiten unterschiedlicher Distris und um den Hinweis, daß dein Skript einen Spezialfall behandelt, nämlich das fehlerhafte BIOS des Edge. Das hattest Du nicht erwähnt.

Natürlich kann man die Skripte bedeutend kürzer halten und man muß auch nicht so stark modularisieren wie es pm-utils oder (noch extremer) laptop-mode-tools tun. Da aber ein großer Teil der Ubuntu/Linux-Nutzer nicht skripten kann oder möchte, ist etwas mehr Aufwand vonnöten. Für diese User hab ich TLP geschrieben. Oder hättest Du Lust, jeden individuell beim Skripten seiner Stromsparanforderungen hier im Forum zu supporten? :facepalm:

Ich habe viele Funktionen die pm-utils (mittlerweile!) kennt nachprogrammiert, weil die pm-utils-Skripte für den unkundigen User keinerlei vernünftige Konfigurationsmöglichkeiten bieten (von Dokumentation ganz zu schweigen).

ps. wie wäre es übrigens mit einem Gentoo-Port von TLP?
 
Zuletzt bearbeitet:
Ich unterstütze gerne Leute beim programmieren, allerdings glaube ich, dass thinkpad-forum.de für sowas die falsche Anlaufstelle ist. In Punkte Programmierung/Scripten ist hier zu wenig, bis nichts los. Die meisten nutzen halt leider (!) Windows auf Ihrem ThinkPad - auch wenn es gut läuft.

Gentoo-Port für tlp? Wie meinst Du das? Ein Ebuild und dann per layman? Wäre denkbar, auch wenn ich denke das in Gentoo die Leute das sowieso alles selber machen. Wer selber kompiliert und den Rechner so sehr anpasst, der verwendet da ungern irgendwelche Scripte, die nicht von Nöten sind. Glaub ich jedenfalls... Oder?

laptop-mode-tools ist auch so ein abartiges Script wo Du mehr mit verstehen beschäftigt bist, wie am Ende rauskommt *g War gleich als erstes weg vom Fenster. Kurz danach gnome-power-manager... Furchtbar...

Das das BIOS des Edge nicht sorgenfrei ist, stelle ich bereits im Bios selbst fest. Dort hab ich als ersten Booteintrag immer ein "A" :) Auch wenn ich es lösche, beim nächsten mal ist es wieder drin. Ausserdem geht kein Bios-Update per GRUB. Er läd zwar das ISO-File, startet angeblich auch den Vorang, aber passieren tut nichts - gar nichts. Nervt... Ansonsten wahrscheinlich die ACPI-Events. Mir ist aufgefallen, als ich ein Script mit on_ac_power und eine ACPI-EVENT-ACTION hatte, dass er immer 2x den Akku bzw. Netzteil erkennt. Auch kurios gewesen -> auch ein Grund warum ich davon weg ging. Stück für Stück wird das System halt kleiner. Momentan häng ich an phc-intel. ;)

Ich bin dabei sys-power/powertop-1.97-r1 auszulesen, da er mir noch diverse Stromsparmodien vorschlägt. Ausserdem halt das halbe Web nach Tips absuchen und diese zu testen. Momentan komm ich auf knapp 9,9W im Edge13 ;)
 
Du lieferst mir in deinem letzten Absatz ein weiteres Argument, warum TLP Sinn macht - sogar für Leute die gerne alles selbst machen. Ich zitiere mich mal selbst:
[...] Möglichkeiten des Stromsparens sind recht leicht im WWW mittels einer Suchmaschine aufzufinden. Das Auswählen und Anwenden der jeweils zur eigenen Hardware [...] passenden Einstellungen aus der gebotenen Vielfalt von Wiki-, Blog- und Foren-Beiträgen, fordert dem Anwender hingegen oft fortgeschrittene Linux- bzw. Ubuntu-Kenntnisse ab. Hier soll TLP Abhilfe schaffen, ...
Warum sollen sich alle diese (Auswahl-)Arbeit machen, wenn Sie der Autor eines Tools schon getan hat?

Natürlich kann man in einem Tool das allgemein einsetzbar sein soll, nicht alle möglichen Feinheiten abbilden. Kernel und Userland sind eben so wie sie sind.

ps. ich hab keine Idee, was ein "ebuild" und ein "layman" sind ...
 
Zuletzt bearbeitet:
Warum? Weil für mich eigentlich der Grundgedanke ist, dass Leute die Linux nutzen, Ihr System auch individuell anpassen. Ich finde es schöner, wenn man sich mit der Materie beschäftigt und weiß worauf man sich einlässt, anstatt genau wie bei Windows einfach nur zu nehmen was da ist. Verstehst wie ich meine? Ich kann Leute nicht verstehen, die eine fertige Distri. nehmen und dann überall erzählen "Ich nutze Linux weil ... weil eben so!" und eigentlich gar keine Ahnung haben. Das ist für mich fehl am Platze aber okay, dann lieber Windows... :rolleyes: Toleranz siegt gegenüber Arroganz. :D

Ich sag ja auch gar nicht das TLP schlecht ist, es ist sicherlich gut und überlegt und für viele User einsetzbar und leicht zu handlen, ...

Was meinst Du jetzt speziell mit Gentoo-Port? Ein Ebuild enthält Informationen zu jedem Paket aus Portage. Portage ist der Paketmanager unter Gentoo. Man kann beispielsweise ein Project auf Google-Code erstellen und dort ein ebuild erstellen. Dieses Project implementiert man dann in layman - einem zusätzlichen Paketmanager, der Pakete aus div. Overlays (Entwicklern) zur Verfügung stellt. Am Ende fügt der User dieses Overlay zum layman hinzu, aktualisiert ihn und layman holt alle Paketinformationen aus dem Project. Schwer zu erklären merk ich grad.

Wenn Du jetzt ein tool schreibt, welches sich in verschiedene Ordner einpflanzt ist es danach schwer, alles restlos zu löschen. Über einen Paketmanager geht das halt einfacher/geordneter/gepflegter... Ähnlich ist das ja bei apt-get. Ließ Dich mal in apt-get + layman + linux overlay ein, das wäre sicherlich ein nächster Schritt für dein TLP.
 
Also ich nutze Linux, weil es frei ist und weniger Ressourcen verbraucht. Ich kann mich leider nicht in die gesamte Materie einarbeiten. Gerade daher bin ich linrunner dankbar für TLP. Es bietet mir wichtige Konfigurationsmöglichkeiten, die ich so nun nicht erst durch zeitaufwändige Internet-Recherchen zusammensuchen müsste. Ich muss in meinem Beruf schon genug Zeit in Recherche und Auswertung und Anwendung der Ergebnisse investieren, da bin ich über jedes Bisschen Hilfe/Vorarbeit dankbar!
 
ich hab selbst längere zeit gentoo benutzt und finde auch jetzt noch sehr interessant, da es einem sehr viele möglichkeiten bietet. leider sind einige dinge mit einigem aufwand verbunden. hab daher gerade nicht so große lust wieder zu gentoo zurück zu gehen. tlp wäre auch für gentoo nicht gerade uninteressant. man muss es ja nicht nutzen. das motto von gentoo ist schließlich "it's all about choices". ich wähle auch gerne mal den leichten weg und benutze etwas, was jemand anderes bereits fertiggestellt hat, anstatt das rad neu zu erfinden.

btw:
die overlays bei gentoo kann man mit den ppas bei ubuntu vergleichen. layman stellt eine bequeme möglichkeit zum einbinden und aktualisieren diverser overlays bereit. ohne layman müsste man jedes overlay einzeln aktualisieren. ebuilds sind wie die pkgbuilds bei arch kurze scripts, die steuern, wie ein paket installiert werden soll. darin stehen die abhängigkeiten, unterstützte architekturen, use-flags über die optionale features (de)aktiviert werden können, eventuell besondern compiler-flags, die vorgehensweise beim kompilieren, bei live-ebuilds die url fürs git-, svn-, cvs-repo, aus dem der code direkt bei der installation ausgecheckt wird usw.
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben