Unexpected display on

Syslog when the headset was activated and display turned on

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).

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.

@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) ?

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

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

>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.

> 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.

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

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).

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

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

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.

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

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.

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

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.

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

Ubuntu Touch is no longer supported.