On Wednesday 01 April 2020, Doug McGarrett wrote:
On 3/31/20 2:22 AM, Michael Hamilton wrote:
On Tuesday 31 March 2020, Doug McGarrett wrote:
On 3/31/20 12:09 AM, Michael Hamilton wrote:
On Tuesday 31 March 2020, Doug McGarrett wrote:
On 3/30/20 2:53 AM, Michael Hamilton wrote:
The chrome browser, and possibly others, may keep a screen from going into power saving if a media is being played somewhere on an active page. For example, video/audio adverts that auto-play and auto-rollover can cause this.
You can manually check if your screen is able to be put into power saving by issuing an xset command in konsole:
xset dpms force suspend
The plasma settings for how long to wait can be found in:
System Settings -> Power Management -> Energy Saving
Michael
/snip/
On Monday 30 March 2020, Doug McGarrett wrote: > > On 3/29/20 2:36 PM, Doug McGarrett wrote:
>>> >> I see that once in a while, but not consistently. I'd say once every week or so. >> But then activating the computer by using it for something, and then leaving it, it will turn off as it should. >> --doug > > This is my message after upgrading my tumbleweed system this afternoon, 29 March. It now appears that the display does > not turn off after being left for over an hour. I would appreciate any input that would tell me how to fix this. > I am not a programmer, so please be specific and simple! (I don't know what the "configured period of time" is--I was > relying on whatever the OS thought it ought to be--something like 20 minutes, I suspect, but I never timed it.) If there > is a file I should look at, (and perhaps modify) please specify. I will post anything here if I can't figure it out. > > --doug >
I followed the instructions above--
You can manually check if your screen is able to be put into power saving by issuing an xset command in konsole:
xset dpms force suspend
The plasma settings for how long to wait can be found in:
System Settings -> Power Management -> Energy Saving
And running the command on a root konsole, the screen goes black, as it should, and rolling the mouse brings it back to like. The system settings call for a ten minute blackout. I'll check that right now: (Starting 10:48 PM.) Screen came back to life in about one minute.
Anyone have a solution, please?
--doug
The manual xset command should have caused the display to stay blank indefinitely So if it woke up after 1 minute it's likely something software or hardware on the system is doing something to wake things up. So you need to figure out what that is.
I'm not 100% sure on the best approach, but the plasma sub-system that does power management is called powerdevil. It seems to be responsible for inhibiting and restoring display power management. Powerdevil writes to the system journal and can be monitored with journalctrl.
journalctl -f
This will tail the journal contiguously and can be exited by using control-C or you can review the past n entries or entries sine the last boot:
journalctl -n 1000 journalctl --boot
For example, here are some journal entries where powerdevil has inhibited the DPMS (Display Power Management System) while briefly I briefly watched a video in chrome:
... org_kde_powerdevil[2931]: powerdevil: Enforcing inhibition from ":1.74" "/usr/bin/google-chrome-beta" with cookie 22 and reason "Playing audio" ... org_kde_powerdevil[2931]: powerdevil: Scheduling inhibition from ":1.19" "/usr/bin/google-chrome-beta" with cookie 23 and reason "Video Wake Lock" ... org_kde_powerdevil[2931]: powerdevil: Disabling DPMS due to inhibition
When I close the chrome tab, powerdevil restored DPMS
... org_kde_powerdevil[2931]: powerdevil: Releasing inhibition with cookie 20 ... org_kde_powerdevil[2931]: powerdevil: Restoring DPMS features after inhibition release
As I mentioned earlier, it could be that some piece of software, such as chrome is preventing dpms from kicking in due to media being played.
Running journalctl in a root shell or via sudo would likely give you even more info (not necessarily all useful):
sudo journalctl -f
The last time I had a similar problem I had left a chrome tab active on a page that auto played adverts. If it's not powerdevil inhibiting DPMS, then I'm at a bit of a loss. In that case I might try a different mouse to see if it's some kind of sensitivity to jittery input or vibration. Or start selectively shutting down any likely software candidates - such as a music player or alarm clock.
BTW, I'm on TW 20200326 and DPMS seems to be working fine (with the proprietary nvidia driver 440.64-24).
Michael
Well, I'm not using a chrome tab, whatever that is, and I use Firefox as my browser. I don't know what DPMS is, and I don't think I invoked it, or if I did it was by accident. Please adopt me as a wayfayrer on unmapped streets.
--doug
What applies to the chrome browser likely applies to them all. Some of the more recent replies also describe issues with other browsers and music players.
DPMS is the standard that allows software to put the monitor into power saving. For a starter on DPMS - see:
https://wiki.archlinux.org/index.php/Display_Power_Management_Signaling
I would add TW is not a distribution that I would recommend unless you are keen on getting under the hood and using google to figure things out. It's bleeding edge emphasis often introduces little annoyances, it's the price for playing with the latest stuff.
Michael
Michael, I selected TW for its rolling release capabilities; I do not wish to have to reinstall the OS every few months, or, in fact, ever. It looks now that I have been bitten by some bug in the latest download, and I hope somebody finds the bug and stomps on it soon! I am not a programmer, and I don't know my way around the operating system, but I'm not afraid of the root console when it's required to enter a command. Is it possible to edit the DPMS command in order to make it work properly, and if so, how? When I use "find" fpr DPMS, I find two outputs, one says "on" the other says "off" and they are both dated today at the same time--one is called file:///sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1/dpms and the other is called file:///sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-2/dpms. --doug PS: Is someone watching to see if this is fixed, and if so, how would I know?
I'm afraid there may be no magic bullets. You are experiencing a problem that some aren't seeing. It may be a bug, it may be a configuration issue, it might be being cased by a browser, video player, audio player, media editor, game or some other piece of software that decides to inhibit power saving. Using the find command in this way isn't appropriate. DPMS is a low level internal way for PC's to control monitors. The X11 windows system handles DPMS for us - we can view/change X11's behaviour with the xset command (man xset) and X11/xorg configuration. KDE/plasma power management sits about X11 and provides another layer of abstraction with services such as powerdevil - which are controlled via the plasma desktop System Settings. It's had to tell whats going on without investigating at the issue systematically. You need to gather more info, and in order to do that you may have to be prepared to do some googling and reading based around the possibilities people have already raised in their replies before you can sensibly approach the problem. You could google plasma powerdevil and see how that relates. You could google X11 DPMS and find out what that is. You could google linux journalctl and see how that allows you to retrieve diagnostic messages about what is going on in the operating system. You could google firefox media.autoplay.enabled At the moment people are only guessing that your problem might be related to the browser (firefox or any other) playing media. It may have nothing to do with your case. You could test that by shutting down firefox and seeing if the problem no longer occurs. Maybe it's being caused by an audio player or media editor. Progressively reducing what's running or running the desktop with no programs running might narrow this down. Does an empty first logged in desktop work properly? As I've already mentioned KDE plasma powerdevil logs to the journal when some programs inhibit powersaving - so is there anything relevant in the journal? I gave you some command lines to check that. If you can pin this down to an actual fault in plasma or some other component you should raise a bug at https://bugzilla.opensuse.org/index.cgi You could also search for existing bugs at the bugzilla site. This advice is not just true for TW, or Linux, a similar approach with different OS tools would be required to track down such a problem in Windows too. You have to be prepared to learn a bit about the OS in order to be able to work with it and converse with others about it. Alternatively you put up with faults that are too complex to bother with and see if a future release fixes them. TW weed as a rolling release has the advantage that you get all the latest stuff including the latest bugs (some of which will be from upstream projects that may not feed through fixes to TW for some time). A non-rolling release such as Leap has the advantage of long periods of stability but older software. I've never found Leap upgrades to be difficult - I don't see that as an issue, older software is the issue for me). Michael -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org