> 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1552371 Title: Unexpected display on To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1552371/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
