Linux Kein Standby nach Zuklappen des Displaydeckels

Linux Betriebssystem

Ambrosius

Well-known member
Registriert
23 Juni 2022
Beiträge
1.002
Moin Linuxer,
hab eine kurze Frage, ich komm einfach nicht drauf.

Hab auf meinem T450 MX Linux/KDE frisch installiert und aus irgendeinem Grund bekomme ich die Einstellung nicht hin, dass er in den Standby (oder Ruhezustand/Hybridmodus) wechselt wenn ich den Deckel zuklappe. Es tut sich iwie nichts, weder auf AC noch auf Akku...Was übersehe ich hier?

Hier ein Screenshot aus meinem Energieeinstellungen...
 

Anhänge

  • Screenshot_20221205_161935.png
    Screenshot_20221205_161935.png
    184,4 KB · Aufrufe: 18
Funktioniert es aus dem Terminal?:
Code:
$ systemctl suspend

Und wird der Lid-Switch erkannt?:
Code:
# journalctl | grep Lid
 
Ich hatte vor einiger Zeit ein ähnliches Problem unter Kubuntu. Hier hatte sich der geöffnete Firefox als Standby-Blockierer herausgestellt. Ich bin mir nicht mehr ganz sicher, was es letzten Endes war, ich meine es lag irgendwie an einem vermurksten safebrowsing-Ordner im FF-Profilordner. Der war (warum auch immer) auf mehrere GB angewachsen und hatte haufenweise Dateien (mehrere hundert glaube ich) inkl. komischer "Schattenkopien" bzw. Hilfsdateien (mit . am Dateinamen-Anfang). Nachdem ich dessen Inhalt gelöscht hatte, lief anschließend wieder alles rund, der Ordnerinhalt übersteigt selten 15MB mit überschaubarer Dateianzahl und der Rechner geht ordentlich in den Standby, auch bei geöffnetem Firefox.

Der FF hat aber nicht nur beim Deckel zu den Standby verhindert (hier habe ich es aber signifikant bemerkt), sondern schien ihn generell verhindert zu haben (v.a. im Akkumodus). Aber da es bei Dir bei einem frisch installierten System vorkommt und es sich so liest, dass es nie funktioniert, liegt Dein Problem wohl woanders?
 
Funktioniert es aus dem Terminal?:
Code:
$ systemctl suspend

Und wird der Lid-Switch erkannt?:
Code:
# journalctl | grep Lid

Danke für den Hinweis mit dem Lid-Switch, das hatte ich nicht bedacht, allerdings nutze ich kein systemd unter MX Linux insofern verlaufen bei mir die Befehle, gibts eine andere Methode herauszufinden, wie der Deckel vom System wahrgenommen wird?

@harpo Ja bei mir funktioniert der Standby schon, wenn ich ihn manuell ansteuere, nur halt nicht durchs Deckel zuschlagen. Sehr ärgerlich, denn ich nutze das gefühlt zehn mal am Tag...

Deswegen auch der Screenshot von der Energie..-GUI, kann es sein, dass obwohl das Häkchen unter Knopf-Ereignisbehandlung gesetzt ist der entsprechende Befehl im Backend einfach nicht ausgeführt wird? Eine Ẃeg es übers Terminal anzusteuern?
 
Bei meinem T14, das ein paar "Tage" jünger als Dein Rechner ist, gibt es im BIOS unter Cofig - Power eine Option, die bei "Resume on Open Lid" (oder so ähnlich) den Resume NICHT starten soll. Diese Einstellung betrifft aber genauso das einnehmen des Standby/Ruhezustands, wenn man sie auf "disabled" stellt.

Sollte Dein Rechner mal rapariert worden sein, könnte auch der Magnet fehlen, der den Kontakt auslöst.
 
BIOS unter Cofig - Power eine Option, die bei "Resume on Open Lid"
Die Funktion gibt es im T450 noch nicht, gerade geschaut.

Das mit dem Magneten ist so ne Sache. Das ist ne Spur die man weiter verfolgen kann, Mein Deckel schließt ziemlich bündig, ich überlege gerade ob ich das unter Windows mal ausprobieren könnte, aber das extra nur dafür installieren, scheint mir sehr ambitioniert zu sein
 
Da du kein systemd nutzt ist halt einfach die notwendige Verbindung des Hardware-Events mit der Aktivierung vom Standby nicht richtig hergestellt. Standby funktioniert ja händisch. Also alles vorhanden nur eben (wie so oft) ohne systemd nicht komfortabel voreingestellt.
 
Zuletzt bearbeitet:
Danke für den Hinweis mit dem Lid-Switch, das hatte ich nicht bedacht, allerdings nutze ich kein systemd unter MX Linux insofern verlaufen bei mir die Befehle, gibts eine andere Methode herauszufinden, wie der Deckel vom System wahrgenommen wird?
Auf meinem T430 mit Debian (und Systemd) tauchen Lid-Switch-Events auch in /var/log/kern.log, /var/log/messages und /var/log/syslog auf.


Da du kein systemd nutzt ist halt einfach die notwendige Verbindung des Hardware-Events mit der Aktivierung vom Standby nicht richtig hergestellt.
Der Lid-Switch sollte von udev wahrgenommen werden, was zwar inzwischen in Systemd integriert ist, aber es ging ja auch früher ohne Systemd. Den aktuellen Stand von udev ohne Systemd kenne ich nicht, aber wenn da gar nichts udev-Artiges läuft, dann dürfte es auch andere Probleme geben.
Ich nehme mal an, dass die MX-Macher ihre Distribution absichtlich ohne Systemd ausliefern und sich dementsprechend um udev oder eine Alternative gekümmert haben.
 
Hallo, ich wollte nach ein paar langwierigen und wie ich finde sehr zähneknirschenden Experimenten meine Eindrücke der letzten Tage hier im Thread nochmal verewigen. Jeder weiss Standby unter Linux ist immer so ein bisschen auch Lotterie und die Sache ist die:

Ich habe bisher den Standby NUR über den Menüeintrag vom Start richtig zum Laufen gekriegt und natürlich auch mit dem Befehl pm-suspend, beide Wege führen zum gewünschten Ergebnis, nämlich das ordnungsgemäße Versetzen des Systems in den RAM i.e. STR (Suspend to RAM), die Powerleuchte blinkt langsam, auch der i-Punkt vom Deckel leuchtet. Daraus leite ich ab dass es kein Hardware Problem an und für sich ist und dass die Suspend Funktion noch eigentlich funzt nur nicht immer richtig getriggert wird.

Was nicht funktioniert ist
1- die Fn+4 Tastenkombination
2- der Lid Close (also das Herunterklappen des Deckels)
3- der automatische Wechsel in den Standby Mode nach einer gewissen Idle Zeit wie im Power Devil vorkonfiguriert.

Daraus leite ich ab, dass es an einer fehlerhaften Software Implementierung liegen muss (ausser bei Nr. 2, dazu gleich mehr). Allesamt Funktionen die ich regelmäßig und gerne in Anspruch nehme. Was bei 1 & 3 passiert, ist dass das System versucht in einen Low Power State zu wechseln, es hängt sich aber immer dabei auf und es erscheint lediglich ein blinkender Buchstaben Cursor in weiss auf schwarzem Hintergrund, also quasi wie im Terminal. Jeder Versuch ins TTY zu wechseln oder den Display Manager neu zu starten misslingt, nur ein Neustart bricht den Cursorloop.

Zu 1: den bestehenden Kurzbefehl auf eine andere Tastenkombo umzulegen führt auch zum gleichen unerwünschten Ergebnis.

Zu 2: Der Deckel ist wohl mit ein Problem warum der Standby nicht ausgelöst wird. Tatsächlich liegt hier ein HW Problem vor, denn durch einen kleinen Spalt am Rand habe ich bemerkt, dass der Display gar nicht ausgeht, wenn ich ihn herunterklappe. Also ich weiss auch nicht wieso das so ist, aber ich vermute dass der bereits zuvor erwähnte Lid Switch hier eine wichtige Rolle spielt. Es könnte mitunter auch ein Fehler von meiner Seite aus gewesen sein, da ich vor einigen Tagen eine Displaytranplantation vorgenommen und ein neues Panel eingebaut hatte. Eigentlich bin ich sehr vorsichtig dabei gewesen und hab alles geflissentlich wieder zusammengeflickt, aber vielleicht habe ich ja wirklich was übersehen. Das mit den Magneten habe ich vielleicht vergeigt, wo genau sind die denn verortet im Display? WLAN zum Beispiel funzt ganz wunderbar. Die Antennen habe ich ja auch transplantiert...

Zu 3: auch hier habe ich bei vorherigen Instanzen mit dem KDE Tool das als Applet im Systray von Grund auf mitgeshippt wird nie wirklich Probleme gehabt, die Settings seht ihr ja in meinem allerersten Post. Ein Zurücksetzen auf Werkseinstellungen hat auch keine Besserung gebracht, nach der vorprogrammierten Zeit fängt der Cursor Loop wieder an. Was hingegen klappt ist die Einstellung die Sitzung in den Hybrid Modus zu versetzen, also Suspend to RAM und Suspend to Disk ... Wenn ich dann wieder auf Standby zurück stelle, nimmt er es wieder an und schafft es auch ins Standby zu wechseln, die Frage ist nur ist die Einstellung wirklich persistent? Es dünkt mir als sei die GUI ein bisschen buggy, was zu inkonsistentem Verhalten des Power Plans führt...



Fazit:

Welche Erkenntnis habe ich gewonnen?
-> Nun ja, es wird iwo auf eine korrupte Methode verwiesen in den S3 Modus zu wechseln. Und sowohl der Lenovo eigene Shortcut Fn+4 als auch der Powerdevil verweisen darauf, was es unwiderruflich ins Leere laufen lässt. Der Startmenüeintrag hingegen verweist noch auf die korrekte Methode ins Standby zu wechseln. Wie könnte man das nutzen?

Was kann ich jetzt machen?
Ich glaub es bleibt mir nichts anderes übrig als die richtige Konfig-File zu editieren, nur welche wäre das denn genau? Und was wäre damit zu bezwecken?

Ich hab beschlossen den Lid Switch/Close erstmal zu ignorieren, da ich es vermutlich bei der Montage des neuen Deckels verbockt habe. Im Moment bleibt mir effektiv nur der Hack pm-suspend auf eine komplett neue Tastenkombination zu legen (was auch bislang gut funtioniert) und zu hoffen, dass ein Update Power Devil wieder gerade richtet. Da es nicht meine Main Machine ist, wollte ich jetzt nicht mehr Zeit und Energie vepulvern als nötig. Vielleicht bügel ich auch eine andere Distro drüber, aber im Moment belasse ich es dabei.

Wenn jmd doch noch ein Hinweis zur Config File oder ein eleganterer Hack einfällt, immer her damit...
 
acpi-support installieren (das liefert unter Anderem ein /etc/acpi/lid.sh), dann in der GUI alle aktionen die mit Suspend, Lid-Close etc. zu tun haben auf "Disable" setzen. Dann /etc/acpi/lid.sh befüllen, so dass dein Rechner in Suspend geht; z.B.:

#!/bin/sh
pm-suspend
sleep 1m

Du kannst auch mal mit acpi_listen lauschen, ob dein lid-close-event überhaupt erzeugt wird.
 
Du kannst auch mal mit acpi_listen lauschen, ob dein lid-close-event überhaupt erzeugt wird.

Ja das habe ich gerade gemacht, tatsächlich regt sich gar nix in der Konsole..keinerlei Output, was den anfänglichen Verdacht nur weiter erhärtet, dass überhaupt kein Event getriggert wird und sich das System so verhält als wäre der Deckel noch aufgeklappt..wie gesagt wenn ich reinlucke von der Seite, sehe ich den Bildschirm noch hell aufleuchten, ich meine auch dass die BL Tastatur auch noch an ist. Ich bin vorhin spaßeshalber auch mal mit nem Live Debian reingebootet (mit Systemd) und da hat sich auch nix getan, der Lid Close wird nicht registriert...Ergo grenze ich den Hardware Defekt beim Panelumtausch weiter ein...nur bloß keine Ahnung wie das passieren konnte.

Am Rande auch mal der output von FN+4:
Code:
button/sleep SBTN 00000080 000000000 K

Dass er dann aber trotzdem in den Cursor-Loop besteht nach wie vor..
 
Nimm mal eine Magneten uns such den Magnetschalter. Ich hab' mal in einem Fall echter Faulheit ein kleines Neodynmagnet am Displaybezel von einem X61 montiert gehabt :)

Was ist eine Cursor-Loop?
 
Hey @zwieblum ...so langsam aber sicher wurmt mich das sehr... Ich hab nämlich nochmal nachgeschaut im alten Displaydeckel und ich hab tatsächlich keinen Magneten gefunden. Im T450 HMM habe ich auch keinerlei Erwähnung davon gefunden, und die sind normalerweise sehr ausführlich.. Also bin ich deinem Rat gefolgt und hab mit nem Magneten alles abgetastet, keinerlei Haftung, nirgendwo, habe auch den alten Displaydeckel abgefühlt, nichts. Und dann ist mir der x220 Deckel eingefallen, wo so ein kleiner Magnet an jeder Seite war. Das war unübersehbar, da es schon ein kleiner miniziegel ist.

Hier aber beim T450 gibt es da keinen Magneten. Ich hab alles abgesucht, und hier nochmal die Bilder aus dem Manual und dem alten Displaydeckel, ich hab alles 1:1 übernommen, und wie gesagt, alles funktioniert einwandfrei, WWAN konnte ich zwar nicht testen, aber allein die Antennen sind soweit links und rechts dass da kein weiterer Platz für ein Magnet ist.

Iwie steh ich jetzt noch mehr auf dem Schlauch als vorher, ich weiss bei bestem Willen nicht wo mein Denkfehler ist...

Was ist eine Cursor-Loop?
5EC983FC-3F50-4B3F-B8D3-77D596EC93CA.jpeg
Edit: Man sieht es natürlich nicht in einem Stilleben, aber der Cursor blinkt halt ganz schnell. Ich habe soeben zufällig herausgefunden, dass man durch kurzes Gedrückthalten der Powertaste ein Abmelden erzwingen kann, so dass der Log In Prompt wieder erscheint ohne Neustart..Die Sitzung ist aber leider dahin, es ist praktisch ein Neustart ohne zu booten...



Beitrag automatisch zusammengeführt:

Edit:

Ich hab gerade mal im Bios nachgeschaut ob da was unsauber eingestellt ist...Mir ist aufgefallen, dass ich die Kamera und den Fingerprint Reader disabled habe...Könnte Ersteres doch einen Einfluss auf den Lid Close Event haben? Ich meine nicht, aber vielleicht doch?
 

Anhänge

  • Screenshot_20221209_004603.png
    Screenshot_20221209_004603.png
    168,1 KB · Aufrufe: 3
  • Screenshot_20221209_004643.png
    Screenshot_20221209_004643.png
    122 KB · Aufrufe: 4
  • Screenshot_20221209_004921.png
    Screenshot_20221209_004921.png
    39,9 KB · Aufrufe: 4
  • DB2B0E58-7C3B-40FA-B04C-C9F0D25E8812.jpeg
    DB2B0E58-7C3B-40FA-B04C-C9F0D25E8812.jpeg
    205,1 KB · Aufrufe: 4
  • B81E9620-B09A-4F2F-A73E-E710F3B024A6.jpeg
    B81E9620-B09A-4F2F-A73E-E710F3B024A6.jpeg
    154,1 KB · Aufrufe: 4
Zuletzt bearbeitet:
Duer Magnetschalter ist auch nicht magnetisch, du nimmst das Magnet, um die Position vom Schalter zu finden. Wenn er aktiviert wird, bekommst du einen ACPI Event. Manche Schalter gehen rein auf's Magnetfeld, andere auf Süd oder Nord selektiv, musst also beide Pole probieren.

Nimm mal einen Kompass und fahr' den Displayrahmen von einem anderen Thinkpad damit ab, da wirst du das Magnetchen recht schnell finden.

Kamea + FPR sind egal. Im HMM sind die Magneten nicht aufgeführt.

@Cursor: log' dich auf dem Ding per SSH ein und schau was der Kernel sagt, "dmesg -w" und dann was-auch-immer-du-machst um zu dem Blinkecursor zu kommen.
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben