Proximity sensor is switched on and affect the notifications when they arrive

[Victor gonzalez]

Product: bq Aquaris E4.5 & E5
FW version: OTA-8 .5 & rc221

Preconditions:

STEPS TO REPRO:
1. Receive an SMS (OTA-8.5) or push notification/SMS (rc221)
2. Once the notification arrives cover and uncover proximity sensor, sometimes screen goes crazy

Actual Result:
When notification arrives prox sensor it's switched on
Expected Result:
When notification arrives prox sensor shuold not be enabled

Additional info:

- Repro time: 14:22
- Syslog attached
- 2 videos reproducing the bug with messagging app and telegram

Possible solutions:
We can enable it as it is now so in the in the pocket case it does not light up the screen. However once the proximity is not detected and the screen is turned on, we can disable it for the remainder of the time.

or I think iOS simply does not turn on the screen if the proximity was on when the event arrived.

[Julia Palandri (julia-palandri)]

Confirmed with aquaris E4.5 running OTA 8.5 with SMS notification

[Jean-Baptiste Lallement (jibel)]

It is a feature to prevent pocket dialling.

Use cases are:
With the phone in your pocket, receive a notification which would wake up the phone then you don't want to inadvertently (by touching the phone with your pocket):
- enter a wrong SIM code and lock you card
- enter a wrong PIN code/pass code and lock your phone
- Call an emergency number
- Do all sort of unexpected actions if your phone is not protected by a code.

does it make sense or do you have other expectations?

The screen going crazy is another issue and I couldn't reproduce it.

[Victor gonzalez (victor-gonzalez-0)]

Hi @jibel

Sorry for the delay.

I agree with you in the use cases, but please note that including this feature allows the phone do all those actions by mistake, that could end in a blocked device, blocked SIM, wrong emergency call etc. Some customers are experiencing a blocked device when notifications arrive because the screen does not stop blinking, please watch the vídeo (screen going crazy).

May be a great way to make all customers happy is letting them to choose if they want a "screen wake up" feature or not (just led,sound and vibration), with a simple toggle in Notifications or Security&privacy>locking&unlocking.

If there is a way to improve this let me know the logs you need and I'll reproduce to gather those logs.

[taiebot65 (dedreuil)]

it seems very weird that when you receive a text message. The thing i want to do is pull down the dash and read the text. But because the proximity sensor is enabled its like the screen is flashing all the time. Like you approach your hand to reach to the top and the screen goes off. so you pull back your hand and the screen switch on again.. it happens to me all the time like it would seem my phone is unusable but this is just because the sensor is enabled

[Josué (j2g2rp)]

It also happens to me. Not only the screen got crazy, the system restarted it self like is told in this bug:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1532607
The screen went definitely idle and the system restarted it self. The first thing I could see was the ubuntu init splash I said it because I don't know if it could be related.

If you got any question...

[kevin gunn (kgunn72)]

@anyone adding updates - please make sure to include which device you are seeing this on

also, if you would include /var/log/syslog and /var/log/lightdm/unity-system-compositor.log that would be helpful

[Victor gonzalez (victor-gonzalez-0)]

I was not able to pull /var/log/lightdm/unity-system-compositor.log by adb, so I took the output from vi, sorry. If there is a way please let me know!

Test description:

Behaviour 1: when notification arrives the prox sensor is enabled, and if this is a feature some devices are getting stuck or blocked. Video 1

Behaviour 2: proximity sensor is enabled before hanging the call, that is not useful and causes blocked devices in users hands.Video 2

You'll find both videos+syslog+output of unity-system-compositor.log in the file attached.

Thanks in advance!

[kevin gunn (kgunn72)]

@victor - thanks for videos, always best description.

with video#1 - this behavior is mostly appropriate, altho I do detect that the screen blanking/unblanking is being queued by the rapid application/removal of your hand over the sensor, resulting in some lag for the screen to blank/unblank. As we don't own the proximity sensor I'm not sure how much we could do about it's response behavior. It appears that while there may be some lag/hysteresis in the prox/screen blank/unblank, the phone eventually settles to the appropriate state (uncovered resulted in screen on)
I agree with you though, that at the point of the sms alert disappearing, the timer for the proximity sensor to be active should end...and the screen should simply remain blank. So I agree with you that is a bug. (as it could lead to inadvertent user interaction)
But are you also saying the resulting state of the phone is "stuck or blocked"? meaning, you cannot press the power button to unblank the screen? ( i saw you interact with the indicator panel, so it did not appear to be the issue here)

So i've watched video #2 - and I am unclear what exactly the bug is that you are trying to exhibit.
What I witness in video#2 is incoming call
- uncovered prox sensor, screen is lit and ready for user input
- covered prox sensor, screen is blanked & disallows user input
This is all expected behavior.
Was there something else I am not understanding about the video?

[Pat McGowan (pat-mcgowan)]

@kevin I think you are right we need better heuristics to filter the events.

[Pat McGowan (pat-mcgowan)]

another thought. we can enable it as it is now so in the in the pocket case it does not light up the screen. However once the proximity is not detected and the screen is turned on, we can disable it for the remainder of the time. I think now we disable it only after the user touches the phone. The bad symptom occurs when my hand goes to the indicator panel and triggers the proximity again.

[Victor gonzalez (victor-gonzalez-0)]

Hi all!

@kevin, about video#1,please watch videos attached in #4. I was not able to reproduce yet "screen blocked or stucked" but customers do.

The point is, notifications like SMS or telegram messages shouldn't trigger the proximity sensor because that increases the probability of a stuck or blocked screen (like in their cases). What I suggested in #4 was having a toggle option to enable this or not, let the users choose if they want an always "waking up screen" feature for notifications using the prox sensor or not.

About video #2, the idea I wanted to show is that, having the prox sensor enabled before picking up the call increases the probability of a stuck or blocked screen again, like the previous case. The main goal of prox sensor in a phone call was always turning the screen off while you're on call, but we don't know what's the purpose of having it enabled in the incoming call dialogue.

[Julia Palandri (julia-palandri)]

I think there are a couple of things that we could do here:
a) make it an option, so depending on the user's case of use this can be enabled or not
b) make it behave differently for calls and for other notifications, such as sms and telegram messages
c) activate only after the call has been accepted?

[kevin gunn (kgunn72)]

OK, so to be clear we have a well known bug 1532607 that we fixed & a release is on it's way, which is/was the "phone getting stuck"

For text msgs, we worked closely with the design team which produced a detailed spec around screen blanking. Using the proximity sensor for this case was a hard requirement. As such, I've add ubuntu-ux to the bug.

So I would like to keep this bug but make it be solely about
1) the proximity sensor use on text msgs - as a design question, should there be an option to turn off
2) engineering - still need to tweak the hueristics to limit the timer of active screen+prox sensor after incoming text

[Pat McGowan (pat-mcgowan)]

I strongly suggest we implement what I suggested in comment #11
The proximity sensor should defeat the screen becoming active when its in your pocket, which resolved a dozen previous bug reports.
I don't think we need a user option, lets keep it simple and do the right thing for them/me :).

[Josué (j2g2rp)]

Hi all. Today it happened again. The system restarted itself after receive a notification and I was touching the screen and the sensor.
After that I copied logs that @kevin was looking for.
My device is BQ E4.5 ubuntu edition.
Regards

[Julia Palandri (julia-palandri)]

This is driving me crazy:
- When I have the phone in my pocket, a message arrives and the screen turns on. If I happen to move after that (which I don't know because I usually keep it silenced all the time), my pants start to try weird pin combinations. All successful, so far. Which means that by the time I actually want to use the phone I have to wait until the pin screen is unlocked because I've had too many unsuccessful tries. Which is a *bummer* when I need to make an urgent phone call or need to take a look at the map to check if I should already turn or get off the bus (both happened to me) [which tempts me to open another bug report about "letting the user decide if they want to block the screen after too many unsuccessful tries"].

- In the rare cases when the phone isn't in my pocket, and I get a couple of notifs in a row (like, telegram msgs) sometimes the screen starts to flicker and turns on and off in a frantic way that's very disruptive. Which reminds me I usually want to have it in my pocket except... above :) And even after cleaning all the notifs the led stays on flickering... (some notification service bug I guess, if I get to reproduce it I'll report it). Can we set a timer for the first notification and don't act on successive notifs if they're less than X seconds apart from the first one? At least the time it takes to turn the screen up, play the sound, show the message on screen and turn it off again. I've tried messaging me and it play EVERY SOUND for each message. it ended delivering the last message (with its sound) 3 minutes after the last message I'd sent from another account.

I'm on arale rc-proposed.

[Andrea Bernabei (faenil)]

Krillin, rc-proposed, r289

For the last few weeks I got used to my Krillin being unusable in the morning due to the screen flickering as described by the second half of comment #17

Basically I leave home, walk to the office, and when I get to the office I get the phone out of my pocket (usually jeans).

At that point, the phone starts blanking and unblanking the screen for a few *minutes*, and during that time the phone is *unusable*, i.e. I cannot interact with it. This is most likely caused by a huge queue of proximity uncover/cover events piling up as I walk.
I have to say that the fact that the proximity is triggered on/off from inside a jeans pockets sounds a bit suspicious...maybe our threshold is a bit low?

Sometimes it flickers with a frequency of 1hz, sometimes it's more like a disco light, like 3-4 blank/unblank per second.

This morning, this game lasted for 25 MINUTES, during which I could not interact with the phone.

[Andrea Bernabei (faenil)]

This is also annoying when keeping the phone on my desk, whenever I receive a notification and my hand happens to fly over the phone and back (maybe while trying to reach something) I see the phone blinking.

I haven't tested on other platforms, but I don't remember noticing anything like this on other OSes before.

[kevin gunn (kgunn72)]

so the complaint in comment #17 sounds to be the arale specific issue of sending repeat key events

for the other generic issue of proximity staying active - we are going to change policy to be a single trigger, e.g. once display turns on during an event, the display will remain on even if proximity is covered.

and unfortunately, we don't own the prox/display drivers - we don't want to get in the biz of tinker with every soc/device driver set, rather have a stack on top that can best accommodates many devices

so, the single trigger should help the queuing issue. however, it's a little concerning that your description indicates, the display is turning on in your pocket?

[Pat McGowan (pat-mcgowan)]

I still think my suggestion in comment #11 will fix this symptom.

The other issue here is why does the phone sometimes turn the display on when in the pocket, since the entire point of detecting proximity is to keep it off. Comment #17 is another issue tracked elsewhere.

@andrea when you see this had you received a large number of notifications, i.e. does the blinking correlate to the number you received?

As far as the screen going off when waving your hand over, again my suggestion will resolve that, its also the case that on the E4.5 the sensor enables when within say 5 in, which is futher than other devices, not sure if we can tweak that.

[Andrea Bernabei (faenil)]

@kevin: I don't know, I think the screen starts blinking *after* I take it out of my pocket (I think!)

@Pat: I don't think that's the case, it usually blinks for a couple of minutes or more, that would be 50-100 notifications during a 20mins walk, so it's unlikely. Moreover, it blinked for 25minutes this morning, which makes that correlation even more unlikely

Yes, I'm also surprised that the sensor gets triggered from within a jeans pocket

[Pat McGowan (pat-mcgowan)]

@andrea the continuous blinking is another issue bug #1512100 which on arale is a bug in the android hal

[Andrea Bernabei (faenil)]

@pat I am using Krillin

[Pat McGowan (pat-mcgowan)]

A couple observations

On the E4.5 the proximity senses its near at around 3 inches. We could tune this but I don't think that will help as the MX4 has the same issue and senses near at 1 inch.

Due to unfortunate coincidence the notification icon is almost directly below the sensor on both devices, far left on E4.5 and center on MX4, due to different physical sensor placement and location of the indicator due to screen resolutions.

[kevin gunn (kgunn72)]

We are attempting to fix this per the single trigger prox on an incoming system alert.
however, with krillin we are finding the "initial state" of the prox sensor to be unreliable.
not as simple as we'd hoped

[Pat McGowan (pat-mcgowan)]

Works nicely now IMO