ubuntuusers.de

Ich hatte bislang erfolgreich in Ubuntu 14.04 ein Skript verwendet, das die Bildschirmhelligkeit automatisch je nach Netzstrom- oder Akkuversorgung regelt.

Unter 16.04 funktioniert es jetzt so nicht mehr.

Habe es nach dieser Anleitung erstellt: https://ubuntuforums.org/showthread.php?t=2165826&p=12780831#post12780831

Was habe ich gemacht:

$ gksudo gedit /etc/pm/power.d/zzzbattery

Dahinein folgenden Inhalt:

#!/bin/bash
case $1 in
    true) #on battery 
        echo 1200 > /sys/class/backlight/intel_backlight/brightness
        ;;
    false) #on ac 
        echo 3500 > /sys/class/backlight/intel_backlight/brightness
        ;;
esac

Dann:

$ sudo chmod +x /etc/pm/power.d/zzzbattery

In 14.04 hat das Skript danach sofort funktioniert (Netzstecker rausziehen: Bildschirm dunkler, Netzstecker rein: Bildschirm heller). In 16.04 passiert gar nix.

Im Gegensatz zur 14.04-Installation (selber Rechner, unveränderte Hardware) fiel mir übrigens auf, dass als Backlight-Interface in /sys/class/backlight/ in 16.04 nur noch "intel_backlight" auftaucht. Bei 14.04 gab es da auch noch "acpi_video0", welches ich dann auch im Skript angesteuert hatte und noch eines, dessen Name mir entfallen ist. Ich habe allerdings auch diesmal noch keinen NVidia-Treiber installiert, sondern die NVidia-Optimuskarte läuft noch mit Nouveau. Der Rechner hat also zwei Grafikkarten, einmal Intel HD4000 und zum anderen eine NVidia-Optimus. Ob das fehlende acpi_Viedo0 daran liegt?

Liegt das Nichtfunktionieren des Skripts vielleicht an der Umstellung auf systemd? Ich bin in der Hinsicht aber vollkommen unbewandert.

Wenn jemand helfen kann: Bitte! ☺

Installier erstmal den Treiber, den du nutzen willst. Und dann stelle das richtige Backlight (Datei) ein. systemd ist als drittes zu prüfen.

Ich habe inzwischen ein bisschen weiter recherchiert.

Den Treiber lasse ich erst mal so. Daran liegt es wohl nicht. Sondern wohl doch an der Umstellung von Upstart auf jetzt systemd.

Mit der Steuerung aus dem Skript bekomme ich ja Ergebnisse. Mittels

$ echo "IRGENDEINEZAHL" | sudo tee /sys/class/backlight/intel_backlight/brightness

kann ich die Bildschirmhelligkeit steuern. D.h. intel_backlight ist aktiv und zuständig. Daran liegt es also nicht.

Wegen systemd habe ich aber folgendes gefunden:

Scripts in /etc/pm/config.d|power.d|sleep.d are ignored under systemd. Instead a systemd "unit" (service) must be created and enabled.

Quelle: http://askubuntu.com/questions/609695/does-systemd-read-etc-pm

Und: http://askubuntu.com/questions/613741/ubuntu-15-04-pm-utils-do-not-look-into-etc-pm-power-d-anymore-what-instead

Das geht aber wesentlich über meine Fähigkeiten hinaus. Ich bin ein kleines Ubuntu-Nutzer-Licht, das schon froh ist, mittlerweile ein paar Terminalbefehle sinnvoll nutzen zu können. Ohne mich jetzt stundenlang in systemd-Umstellungs-Folgen einlesen zu müssen: Wie bekomme ich die Funktionalität des bisherigen Skripst unter den neuen Bedingungen von 16.04 mit systemd wieder ans Laufen?

Ich hab systemd noch nicht, aber den Link hast du bekommen - da sind einige Artikel, Herleitungen und teils Beispiele. Damit kann man es hinbekommen.

Ja, danke, der Link ist allerdings nicht neu für mich. Das hatte ich schon gelesen, bevor ich diesen Thread gestartet habe. Ich steig da nicht durch. Verstehst du, Skripting ist für mich fast gänzlich unerfahrenes Terrain. Copy & Paste und froh sein, dass ich halbwegs nachvollziehen kann, was ich damit gerade gemacht habe. Auf dem Niveau bin ich da bislang unterwegs und lerne ganz langsam stetig dazu. Diese systemd Units und wie diese funktionieren verstehe ich aber überhaupt nicht.

Wenn jemand, der die Auswirkungen der Umstellung von Upstart auf systemd auf PM-utils durchschaut, mir konkret helfen würde, wäre ich dankbar. Bitte kein RTFM.

sprock schrieb:

Wegen systemd habe ich aber folgendes gefunden:

Scripts in /etc/pm/config.d|power.d|sleep.d are ignored under systemd. Instead a systemd "unit" (service) must be created and enabled.

Quelle: http://askubuntu.com/questions/609695/does-systemd-read-etc-pm

Ja, die Files in /etc/pm sind mit größter Wahrscheinlichkeit mittlerweile obsolet (genau weiß ich es nicht, weil ich die schon seit Ewigkeiten nicht mehr benutzt habe), der Link da bezieht sich aber auf Suspend-Events und Co. Sprich, was soll passieren, wenn du den Laptop in den Standby schickst. Der Wechsel auf Akku-Betrieb ist aber eine etwas andere Geschichte.

Hier ein Ansatz direkt mit udev:

https://wiki.archlinux.org/index.php/Power_management#Using_a_script_and_an_udev_rule

Da steht, dass systemd-204 diese Funktionalität noch nicht „beherrscht“. 204 ist aber schon ziemlich alt, möglicherweise hat sich das mittlerweile geändert. (Was bei Ubuntu 16.04 dabei ist, weiß ich gerade nicht aus dem Kopf.)

Ich versuche nachher mal, das bei mir auf der Kiste zum Laufen zu kriegen.

Der Weg von hier funktioniert prächtig:

/etc/udev/rules.d/ac-battery-switch.rules:

SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1", RUN+="/usr/local/bin/backlight-switch true"
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/usr/local/bin/backlight-switch false"

Und das Skript /usr/local/bin/backlight-switch (ausführbar machen nicht vergessen):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

#!/bin/bash

max=$(< /sys/class/backlight/intel_backlight/max_brightness)
min=$((max / 50))

case "$1" in
    true)
        echo $max >/sys/class/backlight/intel_backlight/brightness
        ;;
    false)
        echo $min >/sys/class/backlight/intel_backlight/brightness
        ;;
esac

Wow, danke vielmals!

Da ich, wie oben erwähnt, noch ganz am Anfang stehe, habe ich ein paar Verständnisfragen dazu:

Grundsätzlich: Was bedeuten grüne und violette Einträge? Gibt es einen allgemeinen Farbcode, oder sind das deine individuellen Einfärbungen?

Ich bin nicht sicher, ob ich korrekt verstehe, was in den Zeilen 2 und 3 des Skripts genau passiert: In Zeile 2 wird definiert, dass im Falle von max die hinterlegte max_brightness aus /sys/class/backlight/intel_backlight genommen wird,richtig? Aber was bedeutet das in Zeile 3? Ist min 50% von max?

Da ich die jeweilige Helligkeit gerne selbst definieren will – mir ist max_brightness (Wert bei meinem Rechner 4882) zu hell, ich hatte im alten Skript nur 3500, weil mir der Bildschirm sonst zu grell war –, könnte ich nicht die Zeilen 2 und 3 einfach rausnehmen und analog zu meinem alten Skript mit konkreten Zahlenwerten in Zeile 8 und 11 statt $max und $min arbeiten?

Es funktioniert! Ich habe deinen Vorschlag umgesetzt, aber einfach wieder die absoluten Zahlenwerte eingesetzt, wie oben erwähnt.

Vielen Dank nochmal!

(Das mit den Farben interessiert mich noch.)

sprock schrieb:

Grundsätzlich: Was bedeuten grüne und violette Einträge? Gibt es einen allgemeinen Farbcode, oder sind das deine individuellen Einfärbungen?

Das ist einfach nur das allgemeine Syntax-Highlighting für Bash-Skripte hier im Forum. ☺

Ich bin nicht sicher, ob ich korrekt verstehe, was in den Zeilen 2 und 3 des Skripts genau passiert: In Zeile 2 wird definiert, dass im Falle von max die hinterlegte max_brightness aus /sys/class/backlight/intel_backlight genommen wird,richtig? Aber was bedeutet das in Zeile 3? Ist min 50% von max?

Ein 50tel von „$max“, aber, ja, genau das passiert da. Ich habe das einfach nur aus einem anderen Skript von mir übernommen. Bei unterschiedlicher Hardware kann in „$max“ ein anderer Wert drinstehen und dann viel zu hell sein, daher bot es sich an, mit Relativwerten zu arbeiten. Aber natürlich kannst du da auch für dich passende Fixwerte reinschreiben – wie du es ja auch gemacht hast. ☺

So ein Mist!

Nachdem das Skript zunächst gut seine Dienste tat, gibt es seit gestern (ungefähr, da ist es mir jedenfalls aufgefallen; es gab auch einige Updates in den letzten Tagen, könnte vielleicht damit zu tun haben?) ein Problem:

Wenn ich den Rechner boote, ist die Bildschirmhelligkeit auf Akkuwert, obwohl der Rechner vom Netzteil versorgt wird. Wenn ich dann die Stromzufuhr aus- und einstöpsele reagiert das Skript sofort. Nur: Warum erkennt es beim Starten den Netzstrom nicht, sondern stellt den Akkubetriebwert ein?

Nachtrag: Habe gerade mehrmals testweise runtergefahren und gebootet: Das Verhalten ist nicht konsistent, meistens funktioniert es korrekt, manchmal nicht, also fälschlicherweise Akkubetriebshelligkeit.

sprock schrieb:

Nur: Warum erkennt es beim Starten den Netzstrom nicht, sondern stellt den Akkubetriebwert ein?

Mutmaßung: Vielleicht wird es beim Start gar nicht ausgeführt.

Ich würde:

• Ein „date >>/tmp/brightness.log“ an den Anfang des Skripts einfügen, um zu schauen, wann es tatsächlich ausgeführt wird.

• Alternativ recherchieren, wann genau deine Udev-Regel greift/ausgeführt wird.

• Im Zweifelsfall ein zweites Skript verwenden, das explizit beim Boot gestartet wird, sich den aktuellen Status (Akku / kein Akku) anschaut und dann daraufhin die Brightness setzt.

Vielleicht auch ein Timingproblem, mal ein sleep 5 einfügen?

Danke für eure Antworten und sorry, dass ich erst so spät reagiere, habe z.Z. leider viel um die Ohren, das dringender geregelt werden muss als dieses Helligkeitsskript. Ulkigerweise funktionierte das Skript bei den letzten paar Boots auch wieder tadellos, merkwürdig.

Benno-007 schrieb:

Vielleicht auch ein Timingproblem, mal ein sleep 5 einfügen?

Wie ich in der Einleitung dieses Stranges schrob, bin ich ja sehr unerfahren, was Scripting angeht. Wie genau geht das mit dem sleep 5, sprich: in welcher Form genau muss ich das ins Skript einfügen und was bewirkt dies?

So, wie es da steht - an die Stelle, wo du es haben willst. Z.B. vor dem Scriptaufruf oder in eine Zeile am Scriptanfang nach der ersten Zeile. Siehe sleep.

Ich habe gerade einmal mit der vorgeschlagenen sleep-Einfügung rumexperimentiert.

Zunächst hatte ich erstmal rauszufinden versucht, wie sich das System denn jetzt eigentlich verhält: Beim Booten ist die Helligkeit zuerst grundsätzlich maximal, dann geht sie runter auf den Wert, der zuletzt in der letzten Session eingestellt war (nicht, wie in meinem Post oben fälschlich angenommen, die Akkuhelligkeit, sondern einfach ein dunklerer Wert aus der letzten Anmeldung). Also anscheinend ist da ein Skript, das sich die letzte Helligkeit merkt und wiederherstellt (oder die woanders gespeicherte Helligkeit abruft). Und zwar kurz nach meinem, wodurch es dieses aushebelt. Das alles spielt sich noch vor dem Anmeldefenster ab, also während des Bootens.

Daraufhin wie gesagt mit sleep experimentiert:

Erstmal ganz konservativ sleep 10 gesetzt.

Dann habe ich die Displayhelligkeit stark abgedunkelt (nicht mit dem Skript, einfach manuell eingestellt), um gut sehen zu können, an welcher Stelle des nächsten Bootvorgangs das Skript greift, also sich die Helligkeit ändert.

Während des Bootens dann das oben beschriebene Bild, aber ein paar Sekunden später griff mein Skript. Also scheint sich meine oben beschrieben Vermutung zu bestätigen.

Da 10 Sekunden zwar nicht beim Hochfahren, aber beim Ein-/Ausstöpseln des Netzstroms eine ätzend lange Zeit sind, habe ich angefangen die Sekundenzahl für Sleep runterzufahren.

Bei 0.1 ist die Verzögerung immer noch ausreichend, um nach dem vermuteten "LetzteHelligkeitSkript" ausgeführt zu werden, gleichzeitig ist die Verzögerung nicht störend im laufenden Betrieb, wenn der Bildschirm kurz nach Stöpseln des Netzkabels reagieren soll.

Somit ist das Problem eigentlich gelöst. Ich markiere aber noch nicht als gelöst, weil mich das jetzt interessiert: Wie kann ich rausfinden, ob es dieses vermutete Skript gibt und in welcher Reihenfolge die ganzen Skripte beim Booten ausgeführt werden? Und mal eine grundsätzliche Verständninsfrage: Wo wird diese Reihenfolge festgelegt?