858444 - [Call] Proximity sensor does not work during phone call when screen is off.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System, defect, P2)

Description

[hanj.kim25]

It appears that the proximity sensor does not work during phone call when screen is off. However, the proximity sensor should still work even after the screen is off.

Comment 1

[hanj.kim25]

There is also a bug 845660, which shows that the proximity sensor should not be working in speaker mode or in bluetooth mode. Let me set this bug as depends in this bug so they are linked and can be fixed all at once.

Comment 2

[Marco Chen [:mchen]]

Hi,

May I knew the what function and user scenario is performed by proximity sensor when screen is off?

Thanks.

Comment 3

[Joe Cheng [:jcheng] (please needinfo)]

adding UX to confirm expected behavior for this bug and bug 845660

Comment 4

[Leo]

User scenario : 

When turning off screen by user, proximity sensor does not work.
but, when turning off screen due to timed-out(wait some minute, turn screen off automatically), proximity sensor should work.

Comment 5

[Leo]

In Android case, proximity sensor is working after the screen turned off by screen time-out timer,
But GAIA doesn't work, please give your UX confirm for current operation is correct or not

Comment 6

[Dylan Oliver [:doliver]]

This issue was identified as a Leo QE1 blocker. Nominating for leo?

Comment 7

[Casey Yee]

Here is my suggestion:
When a call is initiated (answered or dialed), the proximity sensor should become active.

If the user puts the phone up to their ear, the screen should turn off.  When the user removes the phone from their ear, the screen should turn on showing the active call screen (not lock).

As per comment 1, the proximity sensor should be disabled for speakerphone or when Bluetooth is enabled.

Comment 8

[Leo]

I agree Casey's opinion. But you miss one point regarding the comment5. Please check the UX scenario.

Comment 9

[Alex Keybl [:akeybl]]

needinfo on cyee for comment 8, and leo+ along with bug 845660

Comment 10

[Casey Yee]

Just to clarify the point in comment 5 as per my offline discussion with LG here at the Madrid work week:

For the case:
1. While the user is on a active call and removes the phone from their ear, the phone screen turns On.
2. If the user leaves the phone idle for a certain amount of time, the screen will turn Off after a set time-out period.
3. When the user returns the phone to their ear, the proximity sensor should still be active so that when the user removes the phone from their ear, the screen should turn back On.   

The current behavior is that in step 3, the screen remains Off.

Comment 11

[Marco Chen [:mchen]]

Attachment: Patch v1

In this patch, I used the argument called instant in turnScreenOff() to identify whether this screen off is caused by power key or screen timeout. If it is caused by power key then remove detecting of proximity sensor or keep to detecting.

There are two case for instant to true. One is caused by power key and the other is by screen timeout in lockscreen. But in voice_call state, there is no lockscreen there. So I can use instant == true to identify whether this screen off is caused by power key or not.

Comment 12

[Kai-Chih Hu [:khu]]

Based on the information from Marco, it can be fixed before the end of this week.

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Marco Chen [:mchen] from comment #11)
> There are two case for instant to true. One is caused by power key and the
> other is by screen timeout in lockscreen. But in voice_call state, there is
> no lockscreen there.

No, there's a chance to have lockscreen.Locked when on a call, or did I misunderstand what do you mean by no lockscreen?

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Alive Kuo [:alive] from comment #13)
> (In reply to Marco Chen [:mchen] from comment #11)
> > There are two case for instant to true. One is caused by power key and the
> > other is by screen timeout in lockscreen. But in voice_call state, there is
> > no lockscreen there.
> 
> No, there's a chance to have lockscreen.Locked when on a call, or did I
> misunderstand what do you mean by no lockscreen?

Yeah, re-read the screen_manager.js code I found that |instant| doesn't hold the value Marco expects, specifically on L436, where the lock screen might be underneath the attention screen.

Need a better solution here.

(In reply to khu from comment #12)
> Based on the information from Marco, it can be fixed before the end of this
> week.

Ah, no.

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Update: we had some plan after a quick offline discussion.

Comment 16

[Marco Chen [:mchen]]

Attachment: Patch v2

1. This patch is created by following the discussion.
2. According to modify something related to screen off so the testing includes
  not on in_call state:
    a. timeout on homescreen/lockscreen.
    b. press power key on homescreen/lockscreen.
  on in_call state:
    a. timeout on homescreen/lockscreen.
    b. press power key on homescreen/lockscreen.

3. The reason of asking feedback only is
    I found that scm_toggleScreen() will call scm_turnScreenOff() but I don't know the use case of it and don't find any one calling it. Could Alive or Tim give the suggestion for this? Is it related to reason of timeout or we need to create a new reason for it?

Thanks.

Comment 17

[Marco Chen [:mchen]]

Attachment: Patch v2

Hi Alive,

Please help to review this patch.
Thanks.

Comment 18

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 742238 [details] [diff] [review]
Patch v2

Review of attachment 742238 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, r=me

Comment 19

[Marco Chen [:mchen]]

https://github.com/mozilla-b2g/gaia/pull/9425

Comment 20

[Marco Chen [:mchen]]

https://github.com/mozilla-b2g/gaia/commit/e335d27bcb1919f79215d8b47fa57cbc572d5862

Comment 21

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted e335d27bcb1919f79215d8b47fa57cbc572d5862 to:
v1-train: 41260ba88cd55136229f9835009a4700be9a2bbc