Unexpected display on

[Pat McGowan]

NOTE: kgunn suggests this bug be about 1) not 2) here

1)
I have been noticing my phone and tablet occasionally turning on without interaction. Several times with my phone in my pocket I found it in the emergency call UI
I also see the tablet display turn on while lying idle on the desk. Freiza & Arale

2)
I have reproduced one case such that turning on a BT device (headset) causes the phone to light up and display the volume slider. Similarly turning on the BT keyboard while the tablet screen is off caused the display to turn on.These may be as intended.

I suspect other BT events can similarly resume the device and/or turn on the display if it happens to be awake due to the 5 min polling timer.
The proximity sensor is also not honored when this happens, if its covered the screen still comes on.

[Pat McGowan (pat-mcgowan)]

Syslog when the headset was activated and display turned on

[Simon Fels (morphis)]

For a mouse and a keyboard this for sure intended. Both act as input device like the power key and therefore can activate the device. For example when I have the tablet or the phone working as a converged device I as a user want the device to go to sleep when I wake up but be back when I active either one of those input devices (power-button, mouse or keyboard).

That the device wakes up from a deep-sleep is something we can't prevent and really shouldn't. If I turn on my paired headset I expect it to be usable no matter what state the other device is in. So connection establishment is fine here.

What we should fix is the use of the proximity sensor or other sensors to find out if the device is in a state where a turned on display is intended (like it being in your pocket or somewhere else).

[kevin gunn (kgunn72)]

It seems like there is 1 bug and then 1 potential bug/feature depending based on the original description

1) actual bug - display turning on by itself (btw, i know this happens with Flo/N7 as well)

2) feature - bt devices are input, and we do want the screen to wake up on keypress or mouse move.

I would propose we keep this bug to be about #1)
If we feel something else needs to happen with #2) please spawn another bug - i worry a little with the suggestion to use the proximity sensor, eats battery and creates yet another complicated wrinkle in the display blanking policy. Also, we've kicked off a powerd rewrite to help consolidate policy - i would propose if we do want to address #2) let's do it as part of the powerd rewrite.

[kevin gunn (kgunn72)]

@pat - also does the screen dim/blank at after expected expiry in the case of #1) ?
and second, same question in the case of #2) ?

[Pat McGowan (pat-mcgowan)]

For case 1 I always back out of emergency calls or wherever it got to and manually turn it off.
For case 2 yes it dims and turns off.

My hypothesis was that case 1 is caused by some variant of case 2 since it seems to be a relatively new phenomenon and I can't think of anything else that can cause a known wakeup event. However I have no proof of that other than I had debug logging on and saw a lot of BT and pulse activity when the MX4 woke up yesterday. I had moved out of range of my connected headset.

Fix 1: I think the policy for screen management is simple, never turn the display on if proximity is detected, it should not be specific to SMS or calls.
Fix 2: We are waking up on a headset connection not a HID. Connecting this IMO should never turn on the display. Only HID profile devices should turn on the display.
Fix 3: I suspect other BT events are also taking the phone out of suspend and may need to be filtered

[Pat McGowan (pat-mcgowan)]

When a keyboard connects, it doesn't turn on the display, the user needs to type on a key
The headset may be turning on the display because the connection triggers the volume slider OSD

[kevin gunn (kgunn72)]

>Fix 1: I think the policy for screen management is simple,
> never turn the display on if proximity is detected, it should
> not be specific to SMS or calls.

So you are saying we should have the proximity sensor on all the time ?
I disagree, first that's a power drain. Second, people will complain about the screen blanking off just interacting with the device.
The right answer is to get the policy correct in the first place and filter the events properly into those that you want to turn on the display and those you don't.

[Alexandros Frantzis (afrantzis)]

> So you are saying we should have the proximity sensor on all the time ?
> I disagree, first that's a power drain. Second, people will complain about the screen blanking off just interacting with the device.

There is a third, ideal way which would be to check the proximity value just before making the transition from off to on. This is currently difficult due to the overall power management architecture and the fact that the proximity API given to us doesn't provide a query function (we get change events, but can't get the current state). In the current system we have worked around this for SMS, calls etc with some funky hacks in USC and powerd which would be difficult to extend to other use cases. In the new architecture I expect that we will be able to manage proximity (and this case in particular) much more elegantly.

> The right answer is to get the policy correct in the first place and filter the events properly into those that you want to turn on the display and those you don't.

This is correct. Currently USC wakes up the screen when any key other than power and volume (which are handled specially) or a pointer events arrive. Perhaps there is a bug in our input subsystem and we send stray key events, or perhaps the events are valid (some kind of special key event not corresponding to user input?) and we should filter more strictly. In any case, we need to find out more about these unexpected events to make an informed decision.

[Pat McGowan (pat-mcgowan)]

@kevin I agree with your comment in 7 that the policies should be correct then we dont have the issue

[Alberto Aguirre (albaguirre)]

If 1) happens without keyboard or mouse attached that definitely counts as a bug

As for proximity - the main issue is there's no API to query the current state of the sensor (as Alexandros mentioned).
However done properly the power drain should be minimal as it should only be turned on during an off to on transition (at least to handle the cases described here).

[Launchpad Janitor (janitor)]

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

[Randall Ross (randall)]

I can confirm that my Nexus 7 also awakens on its own for no apparent reason.

Environment information
Ubuntu 15.04 (r425)
Nexus 7 (2013) flo
rc-proposed channel

[Rick Timmis (rick-timmis)]

Aquaris M10, running first update after purchase. Screen comes on to lock prompt, stays on and even pressing power button it goes off for 1 second then back on again.

[Pat McGowan (pat-mcgowan)]

It could be useful to have these logs when it occurs
/var/log/syslog
/var/log/upstart/powerd.log

[Oliver Grawert (ogra)]

On the MX4 specifically there is also the issue with the "home" button staying active for about 30sec when the display was turned off, when shoving the phone into your pocket it is easy to create a button press event if you do not wait long enough.

[Alejandro J. Cura (alecu)]

The "home" button accidentally turning the screen on is confirmed in this thread: https://plus.google.com/u/0/108188125572924200710/posts/aBuWYcnSyQt?cfem=1

[Pat McGowan (pat-mcgowan)]

Case 1 has been resolved with recent sensor control fixes as far as I can tell.
Will mark incomplete to see if there are any lingering issues with update 12.

[Daniel van Vugt (vanvugt)]

Just remembered that Mir actually doesn't control the backlight at all. That's USC/repowerd communicating with the kernel.

[Daniel van Vugt (vanvugt)]

Ubuntu Touch is no longer supported.