Opensuse Leap 15.1, Nvidia, xorg.conf – and a problem with powerdevil

Today, I found the origin of a small problem, which drove me nuts the last months. Some time after an upgrade from Opensuse Leap 15.0 to Leap 15.1 I found that I could no longer bring up the power management functionality in "systemsettings5" of KDE. So, configuring time intervals for switching my monitors into an energy saving mode was no longer possible. In addition, bringing the whole system down into stand-by or hibernation did not work either.

KDE gave me error messages like:

Power management configuration module could not be loaded.
The Power Management Service appears not to be running.
This can be solved by starting or scheduling it inside "Startup and Shutdown"

Unfortunately, no "power management service" was available in the list of the KDE backgroud services .... So, the message did not help at all.

KDE plasma controls power management via a module called "powerdevil". Powerdevil requires a running daemon named "uppower". So, as a next step, I checked the list of running processes for the upower. Result: The daemon was running healthily, and systemd's journactl showed me a message about its the successful start, too. "journalctl", however, gave me some strange messages regarding powerdevil:

2019-12-25T10:43:20.598118+01:00 mytux org_kde_powerdevil[7147]: The X11 connection broke: Unsupported extension used (code 2)
2019-12-25T10:43:56.793629+01:00 mytux systemsettings5[7461]: powerdevil: ("LowBattery", "Battery", "AC") ()
2019-12-25T10:43:56.793813+01:00 mytux systemsettings5[7461]: powerdevil: "Bildschirm-Energieverwaltung"  has a runtime requirement
2019-12-25T10:43:56.794221+01:00 mytux systemsettings5[7461]: powerdevil: There was a problem in contacting DBus!! Assuming the action is ok.

These messages came user-independent and also for freshly created users. So, the problem had nothing to do with any of the settings in KDE's configuration files below "~/.config/". Searching on the Internet showed that others were having similar problems, but none of the offered suggestions helped. Time to dig a bit deeper at other places ...

The monitors on my workstation are handled by a Nvidia graphics card. I use the file "/etc/X11/xorg.conf" to inform the card (independently of "XrandR") about a certain TwinView or Xinerama screen configuration during early start-up phases. To avoid confusion with mouse movement I of course do this in a way consistent with KDE's later settings for a combined screen across different monitors - which you can configure via
"systemsettings5 => Hardware => "Display and Monitors".
As far as I know, KDE5 uses XrandR to perform the configuration of the Plasma display.

Now, sometimes I switch to the Nvidia installation mechanism for the latest driver or for testing a beta-driver from the NVidia web-site. Afterwards, I return to the native Opensuse driver installation via the Nvidia community repository. In my experience this seldom leads to changes in the file "/etc/X11/xorg.conf". But it may happen ...

Today, I therefore checked the contents of the "xorg.conf" file. There I found - to my surprise - a statement in the "monitor"-section for one of my monitors which disabled DPMS:

Option "DPMS" "false"

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "DELL U2515H"
    HorizSync       30.0 - 113.0
    VertRefresh     56.0 - 86.0
    Option         "DPMS" "false"

I cannot recall how and why the entry for DPMS deactivation appeared in one of the monitor sections. All my monitors support DPMS. ...??? ...

Anyway: Commenting the line out

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "DELL U2515H"
    HorizSync       30.0 - 113.0
    VertRefresh     56.0 - 86.0
#    Option         "DPMS" "true"

or setting the option to "true" enabled the interface to powerdevil again in "systemsettings5" of KDE5.

Obviously, in its present state powerdevil requires an active DPMS on all monitors used.

I hope this finding will help others. Note that in some installations there may exit a Nvidia configuration file in the directory "/etc/X11/xorg.conf.d" instead of a central "/etc/X11/xorg.conf". You should check all relevant files for a statement which deactivates DPMS for any of the monitors you use in a X11 based KDE5 plasma session.

Unfortunately, I do not know whether a similar problem can arise with Wayland and how it could be solved then.

Opensuse Leap 42.1 – Problem mit direktem X11 Remote Access (ohne SSH)

Es gibt manchmal - wenn auch sehr selten - Situationen, da will man im LAN ohne den Einsatz von SSH den graphischen Output einer Anwendung direkt in einem Fenster auf einem anderen Linux-System - genauer auf dessen X11-Server - ausgeben.

Unter Opensuse Leap 42.1 mit KDE geht das leider nicht mehr so ohne weiteres - selbst dann nicht, wenn man per Yast2 explizit den Zugriff auf den X-Server von außen erlaubt und lokal auf dem Zielsystem z.B. "xhost +" abgesetzt hat, um den Zugriff auf das Display zu erlauben. Was ist die Ursache und wie kann man dieses Problem beheben?

Das Problem

Nehmen wir an, das System auf dem die Applikation (z.B. kate) läuft, habe die IP 192.168.2.45 und der Host auf dem der X11-Server unter OS LEAP 42.1 läuft (und auf dem der Output von kate) erscheinen soll, habe die IP 192.168.2.4. Dazu sind dann drei Voraussetzungen zu erfüllen:

  • Der X-Server auf dem LEAP-System 192.168.2.4 muss eingehende TCP-Verbindungen auf einem definierten Port (Standard: 6000) entgegen nehmen können.
  • Auf dem X-Client 192.168.2.45, auf dem die Applikation läuft, muss die Umgebungsvariable DISPLAY richtig gesetzt sein; in unserem Fall muss dort ein
    "export DISPLAY:192.168.2.4:0"
    abgesetzt werden.
  • Der User, auf dem Remote-System 192.168.2.4, der den X11-Schirm geöffnet hat, muss den Zugang zu diesem Schirm per "xhost +192.168.2.45" freigeben - oder besser, viel sicherer und userspezifisch gestaltbar: es müssen Regeln/Secrets definiert und in einem .Xauthority File hinterlegt sein, anhand derer der X-Server den Gegenpart (auf 192.168.2.45) als berechtigt einstuft (z.B. per Xauth-Mechanismus).

Nehmen wir weiter an, dass wir die letzten beiden Punkte erledigt haben. Dann kann das Problem nur noch daran liegen, dass der X-Server keine TCP-Pakete entgegennimmt. Früher (bis Opensuse 13.2) konnte man über YaST2 konfigurieren, wie der X-Server gestartet werden soll. Dazu wählte man unter

"Yast2 >> Sicherheits-Center und Systemhärtung >&gT; Sicherheitsüberblick"

den Punkt "Fernzugriff auf den X-Server" und aktivierte ihn. Das führte dann zu einem Eintrag in der "/etc/sysconfig/displaymanager" der Form

DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes"

Der wurde dann später beim Starten des Displamanagers ausgewertet. Wenn man das unter Opensuse Leap mit KDE macht, erfolgt der Eintrag in der "/etc/sysconfig/displaymanager" zwar auch - er bleibt aber ohne Wirkung. Ein "netstat -an | grep 6000" zeigt leider rein gar nichts.

Lösung / Workaround

Eine Analyse ergab, dass der X11-Server nach wie vor vom Display-Manager gestartet wird. Der ist bei mir nach einer Standardinstallation aber nicht mehr "KDM" sondern "SDDM". Aber auch mit dem alten "kdm" ließ sich der X-Server bei mir nicht zum Arbeiten mit TCP bewegen. Also das Problem lieber gleich für SDDM lösen.

Nun fragte ich mich, wo "SDDM" eigentlich konfiguriert wird. Im Verzeichnis "/etc" wurde ich fündig. Dort gibt es eine Datei "/etc/sddm.conf". Ein Blick in die zugehörige man-Seite ("man sddm.conf") zeigt, dass es eine Option namens "ServerArguments" gibt.

Früher war es wohl so, dass ein Entfernen der Option "-no-listen tcp" aus der Konfiguration diverser Displaymanager automatisch zum Start eines X-Servers führte, der TCP-fähig war. Analog beim Start über "xinit" oder "startx", wenn man keinen besonderen Optionen angab. Dies scheint seit X-Version 1.17 anders zu sein (s. die Links weiter unten):
Man muss dem X-Server beim Start nun explizit "-listen tcp" mitgeben.

Geht das auch mit SDDM?

Also in der /etc/sddm.conf:

[XDisplay]
DisplayCommand=/etc/X11/xdm/Xsetup
MinimumVT=7
ServerPath=/usr/bin/X
SessionCommand=/etc/X11/xdm/Xsession
#ServerArguments=-listen tcp +iglx
ServerArguments=-listen tcp

Speichern, ausloggen, X-Server an Konsole stoppen (z.B. mit init 3), X-Server neu starten (init 5) und dann Ports checken:

mysystem:~ # netstat -an | grep 6000
tcp        0      0 0.0.0.0:6000            0.0.0.0:*               LISTEN      
tcp        0      0 :::6000                 :::*                    LISTEN   

 

Ja, es funktioniert!

Nun muss man nur noch dafür sorgen, dass jedwede zwischen den Hosts installierte Firewall, wie etwa die SuSEFirewall2 den Port 6000 für den Zugriff von bestimmten IP-Adressen aus zulässt. (Bei der SuSEFirewall2 legt man am besten eine benutzerdefinierte Regel an).

Wenn man weiß, wonach man eigentlich zu suchen hat, findet man schließlich auch einen Bug bei Opensuse, der sich um das Thema dreht und dessen Kommentare einem noch ein wenig mehr mitteilen (s. den entspr. Link am Ende des Beitrags). Ich finde, trotz des Kommentars von W. Bauer von SuSE, dass YaST so modifiziert werden sollte, dass die notwendigen Einträge auch für SDDM vorgenommen werden, wenn man per YaST die Sicherheitseinstellungen für das System ändert. Oder man sollte wenigstens einen Hinweis darauf bekommen, welche Einstellungen manuell zu ändern sind. Man kann nicht erwarten, dass jeder Nutzer weiß, dass man die SDDM-Konfigurationsdatei ändern muss.

Indirektes OpenGL Rendering ?

Bei der Gelegenheit: Wenn man indirektes OpenGL-Rendern über X haben möchte, muss man zusätzlich die Option "+iglx" angeben (s. die auskommentierte Zeile oben). Der übliche Eintrag in der "/etc/X11/xorg.conf"

Section "ServerFlags"
Option "AllowIndirectGLX" "on" # or "off"
EndSection

allein scheint auch nicht mehr zu genügen.

Links

SDDM
https://wiki.archlinux.org/index.php/SDDM

Remote X
http://askubuntu.com/questions/615139/how-to-make-x-org-listen-tcp-port-to-remote-connections
https://lists.freebsd.org/pipermail/freebsd-x11/2015-October/016874.html
http://www.sbras.ru/cgi-bin/www/unix_help/man-cgi?startx
http://www.tldp.org/HOWTO/Remote-X-Apps-6.html
http://www.kai-hildebrandt.de/linux/xauth.html

YaST und X-Serverstart-Bug
https://bugzilla.opensuse.org/show_bug.cgi?id=978262

Hacking X11
http://colesec.inventedtheinternet.com/hacking-x11/