so how many times a second does this thimg poll the proximity sensor?
I did not read the code, but I think you and the OP are not understandig each other because the thing should not poll the sensor. The sensor is polled via HW and a dbus signal is emitted. Then there are interfaces exposed to react to those signal. More on your original thread which I found looking about that. BTW congrats for this app idea though I won't use it becuase while sleeping I am sleepanalized, I think it's really useful for who could need it
BTW congrats for this app idea though I won't use it becuase while sleeping I am sleepanalized, I think it's really useful for who could need it
Nice new word: sleepanalized
I'm using both of them, SleepAnalyser and ProximityClock. As my phone is laying beside my pillow it's not covered all night and I can easily open the clock by skimming over the device. Very useful!
I did not read the code, but I think you and the OP are not understandig each other because the thing should not poll the sensor. The sensor is polled via HW and a dbus signal is emitted. Then there are interfaces exposed to react to those signal. More on your original thread which I found looking about that. BTW congrats for this app idea though I won't use it becuase while sleeping I am sleepanalized, I think it's really useful for who could need it
Orly? THen why must I install the proximityd package to get the proximity sensor to emit a signal on dbus? Further more proximityd works by polling the sensor (by a user configerable sample rate). This leads me to believe that the proximity sensor is not connected to a hardware interrupt and is 'read' whenever it's state is needed to be known.
Unless you are using some custom magical way for reading the sensor you are polling it.
So, how many times a second are you polling the sensor OR are you just using the proximityd defaults?
Are you even using proximityd at all?
What is this thing programmed in?
Has anyone run powertop while this thing is running?
nice app that I did not know I wanted!
Could it be made so that when the device is locked and the app wakes it up to show the time, afterwards it locks itself again?
Also perhaps another way to exit in addition to timeout could be if you tap the screen.
I tried powertop
first result is with proximityclock inactive and second when it is active
Total wakeups 4009, 133.6/s | IRQ 3184, 106.1/s | Timers 825, 27.5/s
HW wakeups 191, 6.4/s | Real gp_timers expired 141, 4.7/s
@vi_ : I didn't use proximityd or dbus. I simply read the state (through the /sys file) every 100ms only when the daemon is active.
@evan: thanks. Your request sounds good, maybe I'll implement it
I've also tested the behavior with top, and I think that it use not so much in term of resources.
I've just upload a new version (0.3) to extras-testing.
With this new version you can change the color of the clock's background and the numbers. You can also set the clock timeout (in seconds).
All these settings are accessible through a home widget's setting button.
Test&Vote
Tank you.
Best Regards,
Daniele Maio.
Great app!! Thanks a lot!
Works fine, except that the colours don't seem to work: I can change them but the end-result is always white numbers on black background.
An other remark is when I activate it by moving in front of the proximity sensor when my screen is on stdby, I am seeing (for a split-second) my home screen before seeing the time. This may be due to a slow unit...?
Edit: I also discovered that if you receive a phone call while Proximityclock is ON, the screen remains sensitive! So you have to be careful not to press your ear too hard against the screen...
