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: The X11 connection broke: Unsupported extension used (code 2) 2019-12-25T10:43:56.793629+01:00 mytux systemsettings5: powerdevil: ("LowBattery", "Battery", "AC") () 2019-12-25T10:43:56.793813+01:00 mytux systemsettings5: powerdevil: "Bildschirm-Energieverwaltung" has a runtime requirement 2019-12-25T10:43:56.794221+01:00 mytux systemsettings5: 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.