Bug 352235 - Screens return from DPMS Suspend Mode to Normal Mode When Receiving Google Hangouts Messages
Summary: Screens return from DPMS Suspend Mode to Normal Mode When Receiving Google Ha...
Status: RESOLVED FIXED
Alias: None
Product: Powerdevil
Classification: Plasma
Component: general (show other bugs)
Version: 5.4.1
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Development Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-03 18:36 UTC by Gil
Modified: 2015-12-14 21:04 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.6.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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