More evidence that this is a problem at a level below either USC or powerd:
0. Build a test program to use and print out events from ubuntu application proximity sensor api (you can use [1] as a starting point, just remove other sensors to reduce irrelevant messages).
1. Use "tail -F /var/log/syslog" to follow powerd messages
2. Start a phone call
3. Start the test program (the one built in step (0))
4. Cover/uncover the proximity sensor, note the powerd output in syslog and the test program output
5. Continue covering/uncovering, at some point (you need to be patient) powerd will stop reacting to proximity events (the screen won't turn on/off). Note how at this point (a) there is no powerd output as a response to proximity in syslog (b) there *are* kernel message about proximity near/far in syslog (c) the test program has also stopped reacting to proximity events (i.e. the sensor api has stopped calling the event callback)
The observed behavior strongly indicates that this is a problem at a layer below powerd. If it was just a powerd issue the test program would continue responding to proximity events.
Note, however, that I haven't been able to reproduce this problem with just the test program running. This suggests (but it's just a speculation at this point) that some additional interaction in powerd (screen on/off?, suspending?) triggers the problem at the lower levels, or at least makes the problem more likely to occur.
More evidence that this is a problem at a level below either USC or powerd:
0. Build a test program to use and print out events from ubuntu application proximity sensor api (you can use [1] as a starting point, just remove other sensors to reduce irrelevant messages). uncovering, at some point (you need to be patient) powerd will stop reacting to proximity events (the screen won't turn on/off). Note how at this point (a) there is no powerd output as a response to proximity in syslog (b) there *are* kernel message about proximity near/far in syslog (c) the test program has also stopped reacting to proximity events (i.e. the sensor api has stopped calling the event callback)
1. Use "tail -F /var/log/syslog" to follow powerd messages
2. Start a phone call
3. Start the test program (the one built in step (0))
4. Cover/uncover the proximity sensor, note the powerd output in syslog and the test program output
5. Continue covering/
The observed behavior strongly indicates that this is a problem at a layer below powerd. If it was just a powerd issue the test program would continue responding to proximity events.
Note, however, that I haven't been able to reproduce this problem with just the test program running. This suggests (but it's just a speculation at this point) that some additional interaction in powerd (screen on/off?, suspending?) triggers the problem at the lower levels, or at least makes the problem more likely to occur.
[1] https:/ /bazaar. launchpad. net/~phablet- team/platform- api/trunk/ view/head: /examples/ test_sensors_ api.cpp