![]() |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
-rw-r--r-- 1 root root 404 Sep 7 18:23 powerbutton
missing executable bit! chmod a+x powerbutton |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Yes, it was the missing +x!
|
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
hm, then I must chmod it in postinst. I wonder why it didn't happen to me.
|
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Just change them in your source directory,
dpkg will install your files with the same permissions. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
0.0.9 in devel with fixed permissions. Foobar I'd appreciate if you could purge and install to see if it's fixed for you too.
|
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Yes, 0.0.9 works, thanks!
|
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
I put 0.0.9 to a real-life test on my main phone today and, unfortunately, I have to report that the current behavior is not perfect. The problem is the unlocked touchscreen and the fact that the desktop is shown (and active) if the phone isn't locked (by lock code) yet. So sometimes I found various programs running that were started by 'accidental' taps inside my pocket or bag.
Obviously it would be ideal if only the lockscreen could be shown without the actual powerbutton actions. Does anyone have any idea what part of Memo listens to (and reacts on) powerbutton clicks? How does qtlockscreen do its job? |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
You mean that the phone gets unlocked by accidental slides of the "slide to unlock" or that it unlocks by itself when the proximity sensor is opened? The first one can be fixed by appending
Code:
sleep 0.2 |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
1 Attachment(s)
Quote:
Regards |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
I also installed the latest version and then lifted my finger couple of times from the sensor in about 10 seconds. First 2 times the lockscreen came up but on third time the phone unlocked and desktop came up.
|
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
So this still happens for some weird reason. I can't reproduce neither Kossuth's nor D@vIcHoJD's behavior but I will take a look at my code and see what can be done.
|
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
The bug D@vIcHoJD reported should be fixed now.
(On the other hand there is no code to unlock the device in timenow, and no combination of powerbutton presses unlocks the device. I don't know what could be happening) And I found a bug in hildon desktop too :) Go to the lockscreen and press ctrl+backspace to see what happens. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Updated and with few minutes testing (lifting finger from the sensor) everything seems to work fine. Now I'll start testing it in actual use.
Btw, the need to stop-killall-start went away already with your previous version. I just have to say, absolutely and totally awesome work. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
The issues I had encountered earlier were (most likely) caused by timenow and powerlock interfering with each other. I have just removed powerlock and 0.0.10 is now absolutely awesome. Thanks!
|
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
I accidentally reproduced two old bugs this morning. After installing the 0.0.10 version yesterday, I noticed this morning as I took the phone from my pocket and unlocked it with the slider as the lockscreen was visible, it opened the desktop as expected, but second later just as I was about to press the clock to adjust the alarm, the powerbutton menu slid open and I accidentally pressed "reboot" button I had placed there instead of clock. After the reboot, I had to do again the stop-killall-start, but couldn't reproduce the powerbutton menubug even though I tried hard. As if the rebooting cured the bug from me (maybe this is the reason why I didn't see it before, because I was always testing after installing if I had to do the killall-routine after rebooting). Well now it works for me, I dont mind the killall-routine at all anymore.
Also before rebooting, I might have experienced an anomaly, that when I covered the sensor while the desktop was active, it showed the lockscreen. I'm not sure about this, but it is also gone now after reboot. (not sure about this, but when your in such hurry that you don't have time to lock the phone before you put it in pocket, you really don't have time to investigate its behavior) Ps. with yesterdays upgrade (apt-get upgrade) came over 50 cssu updates, so they might have someting to do with this? Pps. this post only to inform about my findings, I'm happy user now, thanks. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Kossuth I think I know why you saw the old bug: The uninstall script stops timenow but stop does not relegate to the actual timenow process, (that's why killall is needed) so after the installation of the upgraded package there were two timenow daemons running. The old and the new.
Now we've got to solve the need to stop and kill each reboot. One obvious workaround is to put this procedure in the init script, but that's an ugly workaround. The thing is that I change batteries atleast twice a week and timenow always starts ok after boot. Please check whether there are more than 1 timenow related files in /etc/event.d The only other thing I can think of is purging timenow, making sure that there is no timenow.conf in /etc/event.d + /etc/init.d and reinstalling. (kill everything between) |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Please also do
Code:
~ $ ps aux | grep timenowdresult here is Code:
~ $ ps aux | grep timenowd |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
There is timenow.conf from 7.9.2012 (I installed latest version yesterday 11.9.2012?) and proximityd from 24.1.2012 in etc/event.d folder, is this how it's supposed to be?
I'll try the purging when I have some extra time in the evening. Edit: and also your suggested ps aux.... command |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
That seems correct. Another thing I can think of if everything else fails is to try installing shortcutd and see if that fixes timenow (maybe shortcutd does something at boot to start proximityd, i'll check it's upstart jobs later) I don't have that installed however so that does not explain why it works here.
|
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Here are the results:
$ ps aux | grep timenowd 1805 user 2084 S sh -c run-standalone.sh /opt/timenowd/bin/timenowd 1848 user 2084 S /bin/sh /usr/bin/run-standalone.sh /opt/timenowd/bin/ 1981 user 25076 S /opt/timenowd/bin/timenowd 3269 user 2088 S grep timenowd ~ $ I'll try the purging later and also the shortcutd. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Tried stopping and killing all and everything, and then purging timenow and proximityd and installing them without any effect.
After that tried to install shortcutd, but no help. Then the same killing and purgin and reinstalling and now I cant get it to even work with the stop-killall-start-routine. I'm pretty sure it's my system and not timenow that has the problem, but cant get what it is. Btw, when I try to stop proximityd it says job not changed. Is this ok? I also saw in the previous ps aux listing that I had 2 standalone.sh lines, is that ok? Edit: got it working with the routine, remenbered that I had to start the proximityd. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Just wanted to note that I don't have to do any start/stop magic to get timenow running on my devices. It just works after a reboot.
|
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
I'm debugging this right now and I think the problem is that timenow starts before proximityd. So I modified the upstart job to look like this.
Code:
start on started proximitydThe fact that it happens to some people and not other is probably due to the different startup services of each setup. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Quote:
On the other hand, proximityd was not started on boot despite the /etc/event.d/proximityd file. After some tests, I discovered that the proximityd start script did not grab the right dbus-daemon pid in order to launch proximityd correctly. I added the following line after the "respawn" line and proximityd is now started correctly on boot: Code:
respawn limit 15 3 |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Editing the proximityd as pierrem suggested made it work for me. Yiehaa....
Tested only once. I'll report back after some charging and more reboots. Megathanks to everyone. Edit: sorry, forgot to mention that ofcourse I tried first editing the timenow.conf, but that didnt help. Now I'm using original timenow from the repo and edited proximityd. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Ok, couple of reboots later the Timenow is still working and I find it very usefull. I usually check the clock from my phone while working (I'm not usually front of computer during work) and some time have dirty hands, so it's a major improvement over the usual routine that I have to use the button or the slider to see the clock. This, I think, was the biggest downside when I replaced my old Nokia Dumbphone with N900 last year, but now it is fixed. Thanks.
I would think that anybody who uses lockscreen to check the clock or missed calls would benefit from this software enormously, and I think there are many people who do. I'd even recommend this to be added to the next CSSU if it could be toggled on/off easily from some UI (Yeah, I'm newbie here in Maemo community, so I can suggest stupid ideas...). |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
I was wondering... Would it make sense to add the reverse operation to timenow, too? I.e. locking the screen after the proximity sensor has been covered for some time, e.g. 10 or 30 seconds? Optionally security-locking the device, too.
What do you guys think? Would that be doable? |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Seeing things only from user side, isn't that what the proximity sensor is there to do in first place, to lock the screen when the phone is by your ear and you are talking to it :-). Can't code, so I cant comment to that part. I would use the reverse operation or at least test it, so I wouldn't have to lock the phone with slider when putting it back to my pocket in a hurry ...
Come to think of it, I think I wouldn't use the slider at all if the locking was reliable enough. Maybe it should lock the screen temporarily (if you uncover in this state, the screen opens back) almost instantly (say 1-2 sec) and make it permanent after 10 to 30 secs. So if you accidentally cover the sensor it wont affect the usage much, but it would lock the phone quick enough to avoid unintended operations. I Don't know if the system is responsive enough to accomplish this. |
Re: [Announce] Proximity enabled idle screen with time [was:turn the screen on programmatically]
Quote:
/Truc |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Interval means how often to check if the proximity sensor is covered. With 5000 you will just have to uncover the phone and wait between 0 and 5 seconds until timenow realizes there has been a change.
If you want to change the time the lock screen stays on after taking out of pocket you have to modify the timeout setting. The number is in milliseconds so setting in to 5000 means that light will stay on for about 5 seconds (up to 7). This setting can't get lower than the default powerbutton press timeout, i.e. 1-2 seconds. (Nothing bad will happen, it just won't have any effect below a certain value) |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Just for the record: I have just discovered my hot n900 with timenowd using 90% of my cpu without any reason. As I was not able to reproduce this situation, I guess there must be a race condition somewhere.
What is sure is that it started when the n900 was idle and continued after I started to use it again, resulting ( what a shock ;) ) in a huge battery drain |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
I saw in your controlPolling fuction (timeow-0.0.10)
void manager::controlPolling(QString status){ if (status == MCE_TK_LOCKED) { modifyProximitydState("turnOn"); } else { modifyProximitydState("turnOff"); pressPowerTimer->stop(); // killEverybody(); } } Should we comment out the call to modifyProximitydState, because as far as I understand, not commenting this would cause de-registre/re-register the timenowd process with proximityd, and there are no set interval call, so the polling interval would be set to default 100ms, which consume battery a lot. And these call are not necessary as the app would only need to register to proximityd once during it lifetime (which was done in the constructor for manager) (IMO) I have test with a dummy process for timenowd which set polling interval to the highest of 2000 ms, and the battery consumption is only about 2mA, which is very good, while with the current version of timenow, the power consumption would be 6-8mA even if I set interval to 2000. (And my typical bat. consump. is about 8mA, so which timenow it would reduce batt. life to 50%) Could this be the culprit? I'm trying to test but not success with building the package yet. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
the reason that line was there was that there is no reason to have proximityd poll the sensor when the phone is unlocked. We could just set the interval again after each register.
Unfortunately I have broken my dev environment for Fremantle right now so I can't test right away, but I'll have it in mind for when I set it up again. You should be able to build though through qtCreator with fremantle target using the defaults. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
I have found another problem.there are too many timenow process, and it seems all of them register to proximityd,but only one set interval to desired value(setting file), the other uses default interval which is 100ms.the way proximity work is that it poll based on the lowest interval process, this render the setting useless.
If you set by hand the interval for all timenow process, then it will work correctly. You can test this: if the screen black immediately when you cover the proximity sensor,then proximityd is polling at 100ms. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
There shouldn't be more than one process.
What do you see in htop? Is there something that can point us out to why more than one process exists? |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
$ ps | grep timenowd
3625 user 2084 S sh -c run-standalone.sh /opt/timenowd/bin/timenowd 3626 user 2084 S /bin/sh /usr/bin/run-standalone.sh /opt/timenowd/bin/ 3635 user 25292 S /opt/timenowd/bin/timenowd 3637 user 2088 R grep timenowd But I found out that the prob is not by many timenowd processes,but because timenowd failed to change interval (qdebug() does not show intervalRegistered, use a new message when change interval solved this) On other thought, maybe we should save setting values as some static variables instead of reading from disk,it should save some battery. The static variable can also be used to store current brightness settings, then we can reduce brightness to minimum when showing the time, then restore original value when screen is locked again. Just some thought.... [Edit] I saw in the shcript file there is a line for reduce brightness, but it was commented out, I removed the comment and it seems to work fine so far(brightness dim when show lock screen and return to normal when unlocked) and this is great especially when you are sleep and does not want to be waken up by the too bright light from the screen. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
I have changed my interval to 2000, and it takes about second to go back to black when I cover the sensor, so I think the interval setting is set correctly in my system.
Ps. If I remember correctly I also had two lines in the ps listing with reference to timenow, when I tried to troubleshoot the starting problem. One starting with the "sh -c..." start and other with "/sh/bin/...." start. My processes can be found in one of my previous post concerning the stop-killall-start routine. |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
Quote:
Another hint is that if the interval is set correctly then battery time should be normal |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
http://www.mediafire.com/?c3uh4814ivagkii
Above is my modified version of timenow (source) And below is the compiled version, please note the version information is not correct (default to timenow 0.0.1), so therefore, this is for brave soul want to test only. . It has some debug information so if run in console we can see its output. http://www.mediafire.com/?dkv51wl0v1k7p8a |
Re: [Announce - #MCCXII] Timenow: Proximity enabled lock screen
cantruchd do you have a github account? If yes please fork and create a pull request, if everything is proven to be ok I'll merge your code.
the processes you see I think are not multiple, just ps prints one line for every program in the chain (sudo shell, sh, run-standalone and actual timenow). I'm not sure this is the correct explanation though, a more experienced linux user should tell us. |
| All times are GMT. The time now is 11:23. |
vBulletin® Version 3.8.8