[QUOTE=KingKurly;300898]You win this round...![/QUOTE]

LOL... You have to love cross posting...

This just shows that in software, like mathematics and life, there is usually more than one way to do something.... :smile:

@KingKurly: :tu:

12.04 LTS:

[CODE]$ gcc -ansi -Wall test.c
test.c: In function ‘onBattery’:
test.c:40:25: warning: implicit declaration of function ‘strstr’ [-Wimplicit-function-declaration]
test.c:40:29: warning: incompatible implicit declaration of built-in function ‘strstr’ [enabled by default]
test.c:51:17: warning: implicit declaration of function ‘atoi’ [-Wimplicit-function-declaration]
$ ./a.out
AC[/CODE]We merged in chalsall's code. Unfortunately, we do not have a laptop so we have no way of testing if the battery part works. Sorry!

A note on chalsall's code
 

If the file in /sys/ is opened, then his function is guaranteed to return and not check /proc/. This isn't normally an issue, but as chalsall himself told me, handling the errors is the hard part :smile:

(You never know if you might open a corrupted file or something silly :razz:)

[QUOTE=Dubslow;300909](You never know if you might open a corrupted file or something silly :razz:)[/QUOTE]

Sigh... The code is sane.

Since /sys/ is a virtual file system, opening a "corrupted" file in such a situation would mean you've got much bigger issues on your hands than possibly mis-detecting if you're on AC or battery....

Odd observations from my stepfather's laptop... it was upgraded to Ubuntu 12.04 LTS not too long ago. For /sys/class/power_supply/AC/online it uses ACAD instead of AC. And for /proc/acpi/battery/BAT0/state it has BAT1 instead of BAT0.

A few problems here. First, the old code wouldn't work on his laptop. Second, the new code wouldn't work either. Hrmm... what the heck?

The kernel was 3.2.0-24-generic.

Can anyone else confirm these findings? (Look in /sys/class/power_supply and /proc/acpi/battery)

Edit: I don't think it's a safe assumption that the contents of /proc/acpi/battery/BAT0/state are smaller than 180 bytes. Is the code not making that assumption? (I'm mildly rusty on my C.)

A feature request. I like the newer version of throttle where you specify the percent of time you want to be running. In Multi core systems where memory may be a bottleneck is it possible to stagger the periods of rest between cores? So if I am running 50 throttle I want one core to be running Prime95 half the time and the other core for the rest. Right now both cores run together and rest together.

A friend of mine took a look at the battery detection code and came up with this rendition: [url]https://gist.github.com/60de973a828979a17253#gistcomment-338482[/url]

I haven't yet checked how often the battery gets polled... that makes quite a difference in how this should be done.

To sleep, for me.

[QUOTE=KingKurly;300928]A friend of mine took a look at the battery detection code and came up with this rendition: [url]https://gist.github.com/60de973a828979a17253#gistcomment-338482[/url]

I haven't yet checked how often the battery gets polled... that makes quite a difference in how this should be done.

To sleep, for me.[/QUOTE]

On my laptop, "a few minutes" would be a perfect description of about how long it took to recognize changes. A decent guess would then be that it checks every five minutes.

[QUOTE]So if I am running 50 throttle I want one core to be running Prime95 half the time and the other core for the rest. Right now both cores run together and rest together.[/QUOTE][url]http://www.mersenneforum.org/showthread.php?t=12286[/url]

[QUOTE=Dubslow;300930]On my laptop, "a few minutes" would be a perfect description of about how long it took to recognize changes. A decent guess would then be that it checks every five minutes.[/QUOTE]
I decided to look at the code. Looks like every 15 seconds.
[CODE]
./commonc.h:#define TE_BATTERY_CHECK_FREQ 15 /* Check battery every 15 sec. */
./commonb.c: add_timed_event (TE_BATTERY_CHECK, TE_BATTERY_CHECK_FREQ);
[/CODE]