On the IDEAL I had before I had "750:45". I don't know if that was the original one or was a modified one.

Questions regarding battery-patch:

1) why not copy the customized kernel profile (currently named 'ideal', which is less than ideal...) to '/home/user/.kernel/' so that it doesn't conflict with the profile named 'ideal' already in '/usr/share/kernel-power-settings' / and use a different distinquisable profile name too, like 'profile-ideal-battery' or something else?

2) after 'kernel-config load /home/user/.kernel/<profile>', do an 'kernel-config default /home/user/.kernel/<profile>' too and omit 'kernel-config save /home/user/.kernel/<profile>' instead

3) for '/opt/scripts/' and 'opt/scripts/*.sh', is it necessary to have executable rights for 'group' and 'others'? i did:
- 'sudo chown root:root /opt/scripts && chown root:root /opt/scripts/*.sh'
- granted 'w' only to 'u', so it looks like 'rwr-x-rx' for '/opt/scripts/*.sh'
- i did 'chown root:root /etc/event.d/dbus-scripts' too
- i did 'chown root:root /etc/dbus-scripts.d/*' too

Should be more 'correct' and enough i think?

@don_falcone
1-)my next update will have a file called custom and it's placed at /home/user/.kernel so i don't mess with anything else

2-)that's fixed in the next update too

3-)it must have executable rights because the dbus-script does this when the screen is locked

/opt/scripts/cpu_normal.sh

it executes it
withoiut the executable rights
it doesn't execute it
BTW haven't tried chown root:root

but i'm used to do chmod +rwx on anything

I know that 'x' is eXecutable, for scripts to be 'executable' the attribute has to be set. For directories 'executable' means something different; the ability to 'cd' into the directory in question

My question was more if executable right is also needed for 'group' and 'others', instead of only needed for 'user/owner'? Scripts/files should not have more rights granted than necessary. Ok it's nothing security related here, it's merely for correctness.

Btw; maybe outsource the dependencies installation too in a separate script and do a test using dpkg or apt before if they are installed, otherwise download & install package(s).

Hey karam.

Thanks for Your efforts.
Here I have another 'correction':
the dbus-scripts and dbus-scripts-session, You provided, are a little bit mixed (not messed, but ...), The dbus-scripts does not need to be provided, as it is already there. Only dbus-scripts-session with correct content necessary.
The file dbus-script-settings, containing Your triggers, should be renamed to e.g. vfs-cache-pressure(_by_karam) before upload.

I also added this line to the vfs-cache-pressure file:
#:vfs_10
/opt/scripts/cpu_sleep.sh * * org.freedesktop.Hal.Device Condition ButtonPressed cover
which make this patch also active after device has gone inactive with kb open and the kb being closed later (without activating again). But, this may NOT be the thing one wants; maybe one wants the device to stay 'active'. But for me this is perfect.

Subjective my battery life is better now, although I have also eliminated a problem with some python server, not letting my device go into C4 (deeper sleep) state at all; always at C3 only.
Thanks to vi_ for giving me the pointing about right interpretation of powertop...

aah sorry but what did you mean with this

Btw; maybe outsource the dependencies installation too in a separate script and do a test using dpkg or apt before if they are installed, otherwise download & install package(s).

i guess i have bad english please make it more clear to me

@peterleinchen

hmm i was thinking to make the vfs-cahe changes when the brightness is on (will do this in the next update )

but i don't have my N900 now
so will be a bit late till the next update

oh BTW
thank you guys for your suggestions
i have finally felt that i'm not working alone

To get rid of "apt-get install *" in install scripts directly, and to move them out to a separate 'install-dependencies.sh' like script. In it, before directly calling 'apt-get install', you should test if the package in question, like 'dbus-scripts', is already installing by executing 'dpkg –get-selection | grep dbus-scripts' or similar ('apt-show-versions' maybe), also for 'kernel-power-settings'.

For the scripts itself, when using 'bash' or 'ash', there should be a shebang in the respective shell scripts that specify the correct shell to use:

#!/bin/bash

#!/bin/sh

For further read: http://en.wikipedia.org/wiki/Shebang_%28Unix%29

As /bin/sh is usually a symbolic link on *NIX systems, it is the system's default shell if not specified otherwise. On N900, it's ash.

---

A small addentum: i'm a fan of 'neatness' / 'tidyness', so _i_ would rename all scripts to something like:

(- speedpatch-dependencies-install.sh)

- speedpatch-main-install.sh
- speedpatch-main-remove.sh / speedpatch-main-uninstall.sh

- speedpatch-battery-install.sh
- speedpatch-battery-remove.sh / speedpatch-battery-uninstall.sh

For all software, it should be clear what it is from the filename itself, and all filenames should be unique, not ambiguous. So install.txt /install.sh is way too generic and could belong to anything, as well as like for example readme.txt for documention - it _should_ be <package>-readme.txt or so.

I see this often for Miranda (a Windows messenger) plugins, in those cases you often overwrite the readme's from separate plugins in directory /docs because they are not made unique. It would be nice to adhere to a certain standard here. Thank you anyway for your efforts!

No, leave vi_'s settings (kb open, brightness on) as they are. This keeps this trick to be activated only when the device should be sleepy

And about check for installation: only needed not to upgrade accidentally an already existing install with a higher version, right?

@don_falcone
aaah i understand now
well yes that's true it would be better to do that
but it's only dbus-script
it doesn't worth to make another script for it IMO

and for the names
i will do this on the next update
Thanks

@peterleinchen
no no you got me wrong
i meant that when the brightness is on
the vfs_cache changes to 100 (default)
so when you receive a call the vfs_cache changes to 100

PS: CAN SOME ONE TEST VFS_CACHE 1000
IT MIGHT GIVE MORE CONTINUES USAGE TIME