Bug 352235

Summary:	Screens return from DPMS Suspend Mode to Normal Mode When Receiving Google Hangouts Messages
Product:	[Plasma] Powerdevil	Reporter:	Gil <gilberto.limon.perez>
Component:	general	Assignee:	Plasma Development Mailing List <plasma-devel>
Status:	RESOLVED FIXED
Severity:	normal	CC:	bhush94, kde, plasma-bugs
Priority:	NOR
Version:	5.4.1
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:	http://commits.kde.org/powerdevil/eca79138c15575f6f523a8680919b407f84da2e2	Version Fixed In:	5.6.0
Sentry Crash Report:

Description Gil 2015-09-03 18:36:35 UTC

This started happening when I upgraded to Plasma 5. I would randomly see my monitors return from Suspend mode and I was not sure what was happening. After some experimenting with it I was able to narrow it down to certain events. I'm not convinced that this is the only thing that causes a return from suspend, but I can confirm that this happens every time I receive a message from someone on Google Hangouts when using Chrome.

Reproducible: Always

Steps to Reproduce:
1. Turn on DPMS.
2. Launch Chrome browser.
3. Login to GMail and Google Hangouts.
4. Allow for signal to be sent to enter suspend mode.
5. Send yourself or have someone send you a message.

Actual Results:  
Monitors return to normal mode from suspend.

Expected Results:  
Nothing should happen. Monitors should stay suspended unless I press a key on my keyboard, move my mouse or personally send the signal from CLI using xset.

Comment 1 Kai Uwe Broulik 2015-09-06 21:08:39 UTC

When a hangouts message is received and it plays a sound, Chrome sets an inhibition. It does this to ensure while playing a video it doesn't turn off the screen. Unfortunately it does so even for short sounds. Once an inhibition is released, PowerDevil (KDE's power management system) simulates user activity so when a timeout (such as auto screen turn off) outlasts the inhibtion (watching a movie) it would still turn it off eventually. It is likely that this causes the screen to turn on. I'll investigate what could be done to satisfy both needs.

Comment 2 Kai Uwe Broulik 2015-11-23 15:04:47 UTC

Please give a try to https://git.reviewboard.kde.org/r/126145/

Comment 3 Kai Uwe Broulik 2015-12-14 21:04:18 UTC

Git commit eca79138c15575f6f523a8680919b407f84da2e2 by Kai Uwe Broulik.
Committed on 14/12/2015 at 21:02.
Pushed by broulik into branch 'master'.

Wait 5s before enforcing an inhibition

Whenever Chrome plays a sound it posts an inhibition. This is great, except that it does that
also when playing a short sound, eg. when receiving a message.
This patch makes PowerDevil wait 5 seconds before actually enforcing the inhibition. In
any case I don't want to have the system wake up for any such short inhibitions.

Also cleanup; the inhibition and inhibition with explicit dbus service methods were
virtually identical.

REVIEW: 126145
FIXED-IN: 5.6.0

M  +42   -35   daemon/powerdevilpolicyagent.cpp
M  +3    -0    daemon/powerdevilpolicyagent.h

http://commits.kde.org/powerdevil/eca79138c15575f6f523a8680919b407f84da2e2