Why not restore them if they exist? You go out of your way to back them up, and then don't restore them? If there were files, you're not restoring them on uninstall. That's a change.

No, batterypatch does. I was reviewing both at once, since you clearly have the assumption that both are installed together. (Batterypatch having an implicit reliance on speedpatch being around to mount cgroups as an example.)

Fair enough. Can you mount cgroups with base PR1.3? I don't know, because I never tried.

I also see you never addressed one key point of what I was saying. Your description (both here and in the deb) says you're creating cgroups for the desktop and for apps, when in fact you're doing neither. They only cgroup you're making is for bash and shell scripts using bash. The desktop and user apps are already in a cgroup, created by Nokia as part of the kernel compile.

Can you please address why you're lying about what you're doing?

The kernel already does that if there's a lockup, even if you default it to something else. If you load a profile as default, and the system reboots twice in the span of a couple minutes, the kernel automatically rejects loading the default config and uses the built-in Nokia-based values (250-600, high-voltage). That's been in there since Titan's kernels, well before KP. The fact that you don't know this, shows how little you know about this whole process.

Again, you show you have no idea what you're talking about. A missing default kernel profile will never cause a reboot loop. A missing module or kernel file may, but a profile never will. It will simply stick with the built-in Nokia defaults if the profile it's instructed to read is not present, or is corrupt in some way.

Nokia, as part of the phone app, triggers the phone app to get real-time priority, and locks the kernel at a set speed (600 as I recall). At that speed, the phone app takes about 60% of the CPU and allows enough background time for apps to continue to function if needed. I made plenty of calls using the stock 250-600 kernel and noticed no quality issues. If you're seeing issues, it's probably because you're either running something highly CPU intensive in the background, or because you've installed a speedpatch that's screwing around with cgroups and letting shell scripts take higher priority than they should!

Also, you again show ignorance on your own scripts. In the postinst for batterypatch, you check for version 42, 47, and 48 of KP, and copy the config settings from /opt/dbus-scripts/ to /usr/share/kernel-power-settings. The config files put in place for those kernels is:
call: 750-850 non-call:250-805 sleep:125-600 (all with SR2 set)

For all other kernels, the files used are
call: 720-850 non-call:250-805 sleep:125-600 (all with SR1 & 2 set!)

Also, for all but 42, 47, and 48, you're enabling SR1, another problem. You do know that with K49 (and 43, 44, 45, & 46) that SR1 is not always stable, right? The patch to handle that is slated for K50, and only those doing kernel testing have a version of K49 that might be recent enough to allow this in a stable way. Did you know SR1 is also never stable for 125Mhz, since Nokia never enabled it and never setup the e-fuse stuff for that? Yet you tinker with it.

It's no wonder people are having problems with their devices using these patches.

Conservative module? Do you mean the config setting for the governor? All that does is tweak how quickly the system jumps from one frequency to the next. The "ondemand" setting sets up the governor so it quickly ramps up to top speed (>50% cpu use for a short time ups the clock). Where "conservative" requires >80% use for a moderatly longer time to up the clock. Upping the max frequency has no effect, since the "lag" you're seeing is caused by the governor not moving the clock speed up quickly enough. The only thing you can do to make the system more responsive with the conservative governor is to up the minimum frequency, so you start out at a higher basis.

How is it you're tweaking values when you don't even understand the basic concepts of what they do?

Also, are you mentioning it anywhere that you're overclocking people's devices? Are you warning people that your script, notably the batterypatch, is not only silently installing kernel-power (HAM installs prereqs silently), but is overclocking their device? Don't you think that's worth mentioning on the top post, or in the description?

And you're not just overclocking them... you're severely overclocking peoples devices, placing the minimum clock speed well above the maximum limit deemed "safe" by TI and Nokia. It suddenly makes sense now why so many people with your patches were complaining about how hot their phone gets when they use it to call people. You're locking it into a severely over-clocked state. It's getting hotter, and using more energy for calls for the sake some perceived "clarity". That's the opposite of battery savings...

And you're turning SR1 on in several kernel versions where it's known to have issues. And enabling a frequency known to be unstable by Nokia and all overclock developers.

So, lets address the key items here in a nice little list:

• You're overclocking peoples devices without telling them. (BP)
• You're setting a minimum clock of >700 when Nokia max is 600. (BP)
• You're using a known-defective frequency (125Mhz) when asleep. (BP)
• You're not remembering/restoring actual kernel config settings at install/uninstall (BP)
• You're causing a few apps to not trigger cpu raise when active, removing any "race to idle" benefits.
• You're claiming to setup cgroups that you're not actually setting up. (SP)
• You're setting up a cgroup for shell scripts, for no real reason. (SP)
• You're removing any other user/app settings placed in .profile & .bashrc (SP)
• And not restoring those when uninstalling. (SP)
• You're calling on cgroups in BP, which is mounted only in SP. (Mix)

The real irony I see here is that speedpatch does frankly almost nothing. Most of the speed increases are coming from batterypatch, which are a mix of sever overclocking, and renice-ing a few apps with a config setup to ignore load caused by them for governing purposes. Battery savings is coming almost exclusively from the fact that you're forcing KP install, with a very small margin possibly coming from renice-ing a few processes in a couple situations. (And even that's debatable.)

Side effects include heat and quicker battery drain while making calls (from sever overclocking), instability (from overclocking, SR1, and using unstable frequencies), and perhaps slightly faster script execution.

I also read in this thread something about a "completely fare scheduler". Where exactly is that being installed and enabled? I see nothing affecting the scheduling algorithm of processes, outside of the minor tampering with cgroups done in speedpatch (which is a far throw from changing the scheduler).