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

Bug #1426115 reported by Pat McGowan on 2015-02-26
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Canonical System Image
High
kevin gunn
Unity System Compositor
High
Alexandros Frantzis
unity-system-compositor (Ubuntu)
High
Alexandros Frantzis

Bug Description

When receiving an SMS notification or a calendar event the screen is left on for the full min or more as set by the user. This is not necessary and not how other phones behave.

I would suggest 15 secs and go direct to suspend.

Related branches

description: updated
Ricardo Salveti (rsalveti) wrote :

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

affects: powerd (Ubuntu) → unity-system-compositor (Ubuntu)
affects: unity-system-compositor (Ubuntu) → unity8 (Ubuntu)
Michał Sawicz (saviq) wrote :

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

affects: unity8 (Ubuntu) → unity-system-compositor (Ubuntu)
Pat McGowan (pat-mcgowan) wrote :

can this get in the to be fixed queue

Changed in canonical-devices-system-image:
assignee: nobody → kevin gunn (kgunn72)
importance: Undecided → High
status: New → Confirmed
kevin gunn (kgunn72) wrote :

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

Changed in unity-system-compositor (Ubuntu):
assignee: nobody → Andreas Pokorny (andreas-pokorny)
Daniel van Vugt (vanvugt) wrote :

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?

kevin gunn (kgunn72) on 2015-03-27
Changed in unity-system-compositor (Ubuntu):
assignee: Andreas Pokorny (andreas-pokorny) → Alexandros Frantzis (afrantzis)
Changed in unity-system-compositor (Ubuntu):
assignee: Alexandros Frantzis (afrantzis) → nobody
tags: added: pm-fail
Launchpad Janitor (janitor) wrote :

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

Changed in unity-system-compositor (Ubuntu):
status: New → Confirmed
Changed in canonical-devices-system-image:
milestone: none → ww28-2015
kevin gunn (kgunn72) on 2015-07-07
summary: - Screen timeout for events needs to be a shorter duration than the
- standard inactivity timeout
+ Screen timeout for system event (e.g. notification) needs to be a
+ shorter duration than the standard inactivity timeout
Changed in canonical-devices-system-image:
milestone: ww28-2015 → ww34-2015
kevin gunn (kgunn72) on 2015-07-07
Changed in unity-system-compositor:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Alexandros Frantzis (afrantzis)
Changed in unity-system-compositor (Ubuntu):
assignee: nobody → Alexandros Frantzis (afrantzis)
Changed in unity-system-compositor:
status: Confirmed → In Progress
Alexandros Frantzis (afrantzis) wrote :

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

Alexandros Frantzis (afrantzis) wrote :

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?

Pat McGowan (pat-mcgowan) wrote :

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.

kevin gunn (kgunn72) on 2015-07-21
Changed in canonical-devices-system-image:
status: Confirmed → In Progress
Changed in unity-system-compositor (Ubuntu):
status: Confirmed → In Progress
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in unity-system-compositor:
status: In Progress → Fix Committed
kevin gunn (kgunn72) on 2015-07-28
Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in unity-system-compositor (Ubuntu):
status: In Progress → Fix Released
kevin gunn (kgunn72) wrote :

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.

Changed in unity8 (Ubuntu):
importance: Undecided → High
Changed in canonical-devices-system-image:
status: Fix Committed → In Progress
kevin gunn (kgunn72) on 2015-08-04
Changed in unity-system-compositor:
status: Fix Committed → Fix Released
kevin gunn (kgunn72) on 2015-08-04
Changed in unity8 (Ubuntu):
assignee: nobody → Michael Terry (mterry)
Michael Terry (mterry) wrote :

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?

kevin gunn (kgunn72) wrote :

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

Michael Terry (mterry) wrote :

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?

Michael Terry (mterry) on 2015-08-06
Changed in powerd (Ubuntu):
assignee: nobody → Michael Terry (mterry)
status: New → In Progress
Changed in telephony-service (Ubuntu):
assignee: nobody → Michael Terry (mterry)
status: New → In Progress
no longer affects: unity8 (Ubuntu)
Changed in powerd (Ubuntu):
importance: Undecided → High
Changed in telephony-service (Ubuntu):
importance: Undecided → High
Michael Terry (mterry) wrote :

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.

Michael Terry (mterry) wrote :

Filed bug 1482317 about unifying calls.

Michael Terry (mterry) wrote :

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

kevin gunn (kgunn72) on 2015-08-19
Changed in canonical-devices-system-image:
milestone: ww34-2015 → ww40-2015
kevin gunn (kgunn72) wrote :

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

Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
no longer affects: powerd (Ubuntu)
no longer affects: telephony-service (Ubuntu)
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers