[greeter] Screen and input should be disabled with proximity sensor when on greeter

Not sure if telepathy-ofono will be involved with this for long, but affecting for now.

It's estimated to have a moderate impact on a large portion of Ubuntu users.

Another scenario is with incoming text messages. The screen turns on and the greeter starts processing touch events in the pocket, of which there will be many. This can lead to apps being launched. This may be a trigger for the case where the edges no longer function when removing a phone from the pocket (bug #1408263)

Bumping priority as I just experienced this several times

This could also result in the phone remaining unsuspended while continuous touch events are being processed.

Although touch events really require a capacitive connection so in pocket events unlikely

IIRC it's telepathy-ofono that wakes the screen up for this still (I know, not the greatest architecture...), and powerd/u-s-c are responsible for actually turning it on and off based on proximity. So, as long as the screen is kept on with proximity enabled by telepathy-ofono, u-s-c and powerd should do the right thing and check proximity before turning the display on.

It is the opposite, powerd wakes the screen up [1] and telepathy-ofono enable/disable the proximity sensor based on audio outputs [2] (speaker mode must keep the screen on):

[1] http://bazaar.launchpad.net/~phablet-team/powerd/trunk/view/head:/src/powerd.cpp#L257
[2] http://bazaar.launchpad.net/~phablet-team/telepathy-ofono/trunk/view/head:/powerdaudiomodemediator.cpp#L41

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

This is a severe issue in my case because:

* Phone is locked in pocket or purse
* Incoming call is not heard or lost
* SMS is sent to caller with default message ("I'm busy, I'll call later")

In my case, SMS are expensive, and the people I communicate via cellphone with do not speak in English, so the English SMS is a total waste of money. Not to mention this could happen when on roaming, and then SMS charges are in foreign currency for me.

This is actually working per the design we agreed on some months back (I can't seem to find the bug that has the discussion thread).

Here are the points, I believe:
1) You do want the screen to light up even when the proximity sensor is covered on an incoming call. If the phone is in your purse or bag and it's ringing you need to be able to see it. This is how iOS works, probably Android as well.
2) The incoming call notification is modal. You can only interact with it and there is no other input available that you can accidentally interact with (i.e. indicators, launcher)
3) You have to swipe to answer/decline a call which is difficult to do accidentally
4) The quick reply could be an issue, but even that requires 2 taps. One tap to show the menu then another to select the option.

If there is an issue with 4 happening automatically we should revist the design of the notification.

I think the bottom line is that every notification that occurs when the phone is locked needs:
a) to always be modal so no other actions can be taken on the ui (think this is true already)
b) needs to use swipe to perform an action, not tap

Sounds like we need a design decision here.
a) do we keep the current design, where on alerts & the proximity sensor is covered we still light the screen ? or do we keep the screen blanked until the sensor is uncovered ? (see bfiller's #1 above)

b) if we keep our current design around proximity sensor, should we alter the message quick reply (see bfiller's #4 above)

The latest instance of this was my phone locked after too many unlock attempts while in my pocket making it quite inconvenient to take a picture.
Contrary to my comment #6 I can trigger touch events through lightweight fabric like pocket lining.
I disagree with point 1 in comment #9, If you can see the screen the proximity sensor will be disengaged. If you can't it should prevent the screen from coming on. That is:
Event happens - proximity is true - screen off
user takes phone from pocket - proximity now false - screen comes on unless timeout period has passed

I think all the issues with inadvertent touches are resolved by fixing this to keep the screen off until proximity is not detected.

Also see bug #1426115 to shorten the time the screen is on when triggered by an event

Fix committed into lp:unity-system-compositor at revision 237, 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

USC 0.1.0+15.10.20150728.1-0ubuntu1 solves one aspect of the problem which involves SMS messages, but does not help with the phone call accept/reject prompt or with turning on the screen in general when we are in the greeter. Further discussions are needed (also in cooperation with UX/design team), to decide the best way forward.

u-s-c change available in silo 30
based on conversation with alf, see comment above, 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
https://code.launchpad.net/~afrantzis/powerd/phone-call-notification-enable-proximity
 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.

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

A fix was made but a further bug#1489326 entered to address other issues

Reopening this bug, after some testing and discussion. We now believe we need to add a separate "reason" for the notification of an incoming call. Otherwise the incoming call screen would time out too quickly (15 sec for system notif).
Once this is added, we would need the calling client to set this reason.

Please refer to Screen blanking policy document: https://docs.google.com/document/d/1RBoVknCLZ4GQ8E_iVftd3i_KmdxI5d6JrBt7i5EDZO0/edit#heading=h.u7wixzf783ng

fix verified on Krillin rc-proposed r224 (20160108-020304)