Geschichte eines Scheiterns - Teil 3
Hallo zusammen, es ist vollbracht. Suspend funktioniert (meistens ...) und der Touchpad wird reaktiviert, wenn der Notebook aus dem Suspend kommt. Bei dem Notebook handelt es sich um einen preiswerten Acer Aspire E 15 E5-573-P83X. Um aufzuzeigen, was es bedeutet, mit systemd das Thema Wiedereinschalten eines Touchpad bei Resume sowie nahezu problemlose Suspend / Resumefunktionalität hinzubekommen (Ausdrücklich ohne in den allgegenwärtigen systemd-Hasser Kanon einsteigen zu wollen), möchte ich die nötigen Schritte im folgenden gerne aufzeigen. Jeder, der eine bessere Idee hat, her damit :-) Das einfache (gut gelöst, wie ich finde): lege ein Skript ausführbar nach /usr/lib/systemd/system-sleep, welches eine case - Anweisung enthält, das die zu entladenden / neu zu ladenden Module lädt und entlädt. Das ist einfach, das klappt prima. Um nicht zu sagen: besser als früher mit pm-utils. Entladen werden i2c-hid, xhci-pci und xhci-hcd. Diese Angabe beruht auf "Heuristik", also einfachem Ausprobieren. Nun der schwierigere Teil. Um den Touchpad zu reaktivieren, muss mit Hilfe von xinput dessen ID bestimmt werden (die wechselt nämlich). Anschließend kann ebenfalls mit Hilfe von xinput eben dieser Touchpad reaktiviert werden. Eine Voraussetzung für den Betrieb von xinput (Danke an Christian Bolz!) ist das Setzen der DISPLAY - Variablen. Darüber hinaus muss aber auch noch die XAUTHORITY - Variable richtig gesetzt werden. Ab hier fängt dann der K(r)ampf mit Systemd an. In einem ersten Schritt generiere ich ein systemd-Servicefile, welches eine Environment - Datei generiert, in der die DISPLAY- und die XAUTHORITY - Variable korrekt gesetzt sind. Man muss nämlich herausfinden, welcher User den X-Server gerade betreibt. Das geht mit "Bordmitteln", sprich: sed und ps. Die DISPLAY-Variable für sich wäre nicht das Problem. Diese Environment - Datei wiederum liest ein zweites systemd-Servicefile ein, welches dann mit eine /bin/sh -c "XXXX" - Anweisung schließlich die gewünschten Aktionen ausführt. Man kann sich an so etwas gewöhnen - aber warum das so umständlich gelöst ist, also warum systemd nicht erlaubt, Rückgabewerte von Programmaufrufen (beispielsweise ...) als Environmentvariablen in einem Skript zu nutzen, ist schlichtweg nicht nachvollziehbar. Man muss ja den Leuten nicht zwanghaft mehr Steine als nötig in den Weg legen. Wären wir in einer idealen Welt und würde der Laptop "out of the box" unter Linux funktionieren, wäre das Gefrickel ja gar nicht nötig - die normative Kraft des Faktischen sagt halt aber etwas anderes (eigentlich hat sich an dem Umstand nichts geändert ...). Wie dem auch sei, es hat jetzt geklappt - weiß mir hier jemand einen guten Platz, an dem man die entsprechenden Informationen für andere zugänglich machen kann? Was ich nach wie vor nicht verstehe: warum bleibt ein Image im Netz, von dem bekannt ist, dass es Probleme mit Secure Boot bzw. mit UEFI hat - dazu hat noch keiner etwas gesagt, das ist IMHO doch schlicht Unfug! Bis bald, danke nochmal für die Unterstützung Dieter Jurzitza - ----------------------------------------------------------- | \ /\_/\ | | ~x~ |/-----\ / \ /- \_/ ^^__ _ / _ ____ / <°°__ \- \_/ | |/ | | || || _| _| _| _| if you really want to see the pictures above - use some font with constant spacing like courier! :-) ----------------------------------------------------------- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (1)
-
Dr.-Ing. Dieter Jurzitza