Screen timeout for system event (e.g. notification) needs to be a shorter duration than the standard inactivity timeout

I think this is a Unity8 bug, as it's the one that knows when to release the display lock from powerd.

It's actually u-s-c that deals with that still, even if that's not our target architecture.

can this get in the to be fixed queue

we can put it in the queue, but this is really a feature add

I believe the screen timeout is already separate to the lock timeout.

I have my phones set to lock after 10 minutes but the screen dims after about 1 minute still. Doesn't seem to be configurable.

Shall we differ between 'keep display on' due to a notification and other cases. Like the media player requesting the screen to stay on during playback.

I believe that all the other use cases involve user interaction, and will probably involve the user touching the screen (->inactivity timeout gets reset based on user input).

So we do not need to differ between who made the displayOn request?

Status changed to 'Confirmed' because the bug affects multiple users.

Do we want to turn the display off immediately after the timeout (e.g. 15sec) has expired, or dim first a few seconds before?

Also, do we want the timeout to be configurable through dbus (like the normal inactivity timeouts), or are we happy with a fixed value in USC?

Lets mimic what the other OSes do. I do not think it needs to be configurable in the UI but it would be prudent to not hard code it.

Fix committed into lp:unity-system-compositor at revision 236, scheduled for release in unity-system-compositor, milestone Unknown

This bug was fixed in the package unity-system-compositor - 0.1.0+15.10.20150728.1-0ubuntu1

---------------
unity-system-compositor (0.1.0+15.10.20150728.1-0ubuntu1) wily; urgency=medium

  [ Alexandros Frantzis ]
  * Support different screen timeout values for notifications
    (LP: #1426115)
  * Enable and handle proximity events properly (LP: #1291455)
  * Don't force gcc 4.9 when building the package (LP: #1478926)
  * Introduce new versioning scheme

  [ Alan Griffiths ]
  * Port to mir SystemCompositorWindowManager

  [ Robert Ancell ]
  * Depend on the new xmir package instead of the obsolete
    xserver-xorg-xmir (LP: #1204505)

  [ CI Train Bot ]
  * New rebuild forced.

 -- CI Train Bot <email address hidden> Tue, 28 Jul 2015 18:55:28 +0000

u-s-c change available in silo 30
based on conversation with alf, this bug won't be closed based on the u-s-c changes alone.
We need components to employ this change in order to get the benefit

excerpt from alf mail

What's missing
--------------

* Other components that emit notifications and turn the screen on need
  to use reason 'notification' (integer value 4) to take advantage of
  the reduced timeout and proximity behavior.

* Phone calls display an accept/reject prompt, but proximity is not
  enabled for this prompt, so one could inadvertently reply to a phone
  call (although it requires a slide gesture, which makes it more
  difficult). I have an MP [1] that tries to improve this in powerd,
  but has a few drawbacks:

  - If the proximity sensor is covered when a phone call is received,
    the screen turns on momentarily before turning off again.
  - If the screen is already on, proximity is still enabled.

  For SMS messages we avoid these issues by handling everything inside
  USC. We could go the same way here by introducing a new reason 'call'
  for turning the screen on. I would recommend against this though,
  since we would be adding even more complexity and inelegance to a
  system that's already broken design-wise.

So there are a few other places I would consider using the NOTIFICATION reason instead of NORMAL:

- in powerd, when receiving a USSD signal from ofono
- in powerd, when an incoming call happens
- in telephony-service, when an mms comes in (or some other telephony account)

Does that sound right?

I tested and Telegram messages (which presumably work via ubuntu-push) don't turn the screen on (image 22 in stable channel). Is that intentional?

not sure about "- in powerd, when an incoming call happens" that might be one special case where you want the screen to continue to be on (assuming proximity is uncovered) - since it's urgency is a tad more ?
I agree with the others.

wrt telegram, could that just be a separate bug ?
sounds very similar to bug 1445345 and bug 1413818

Also, I just looked up how long phone rings last, and it's much longer than 15s (reports vary from 30s to a minute). So it makes sense to have the longer screen wakeup.

re: Telegram, those other bugs seem to be about the notification showing at all or the sound not triggering. And both mention BQ phones. I'm using a mako and both the sound and notification appear. The screen just doesn't turn on. I didn't know if we treated push notifications differently. Maybe ubuntu-push should have a USC::setScreenPowerMode call?

Looking into the ubuntu-push issue... I feel like it's weird that the turn-on-screen code is spread around the place. It seems like logically, the component that is showing the notification on the screen should be turning the screen on. It doesn't feel like a telephony-service decision, for example.

It would also mean that we wouldn't miss cases like ubuntu-push or even direct dbus notifications:

import dbus
bus = dbus.SessionBus()
proxy = bus.get_object('org.freedesktop.Notifications', '/org/freedesktop/Notifications')
interface = dbus.Interface(proxy,dbus_interface='org.freedesktop.Notifications')
interface.Notify('Notification', 0, '', 'Testing 123', 'Hello World', [], {}, 0)

I guess that would mean either turning on the screen in unity-notifications or unity8. And it feels like a different bug should be opened for unifying calls to setScreenPowerMode in one place. For this bug, I've filed MPs for all the existing calls to setScreenPowerMode I could find, to update their 'reason' parameter to use the new NOTIFICATION reason.

Filed bug 1482317 about unifying calls.

And filed bug 1483697 about ubuntu-push not showing notifications at all when the screen is locked.

the rest of this is going to be handled via branches associated with bug 1291455