This is what I know:

kernel provides info through /proc/apm

apm allows you to read this in a nicely formatted manner (but provides no more info).

apmd sits there and looks at /proc/apm waiting for events to occur.

Now my question is what does the light & power applet actually change? I presume there must be a config file somewhere which is written to by this applet (and it's not the same one as is passed to apmd afaik).

Also, apmd just sits there waiting for the events, what actually times inactivity and then decides to suspend/turn down backlight/etc.?

I'm after this info as I'd like to improve power management on the pdaXrom.

Cheers,


Simon

Wow, don't all shout at once ;-)

Well I presume that kapm-idled is the beast I need to be looking at (or more exactly how to control it). A Google-whacking search phrase this certainly isn't though unfortunately.

Can anyone shed any light (for example is this actually what I want to look at?)?


Simon

I'm not exaclty sure on the whole apm setup, but my understanding is that the light & power applet writes to the kernel via apmd.

kapm-idled is the kernel apm idle daemon which uns when the processor is not doing anything and calls the idle/call
instructions to cool the processor/slow the processor/save battery. I don't think it has anything to do with light however.

During boot up there is a message about lcd brightness - sorry can't remember the name, but if you have a look in the kernel source and dmesg you might get more pointers

hope this helps somewhat

Stu

Thanks for the reply Stu,

I've looked at the source of the opie light & power applet and it seems to read/write using the line



Now I don't know what a Config object is, or where it's defined, or what it actually does.

I imagine that kapm-idled also produces the events which apmd listens for, and that it also handles power-off/suspend after X min of inactivity, etc. Although it may not do the screen brightness, I'd have thought that this would be a good place to do it as it is power management related. What I need to know is what I write to to alter its behaviour (like /proc/pm or similar which doesn't exist on my machine)

The problem is that I just don't know, and can't find anything about it. Can anyone point me in the right direction?

I'd really like to be able to get power management on my c750 (pdaXrom) as configurable as it is with OZ - different behaviour with external power, etc., and I also think this is a rather interesting facet of Linux on handhelds (but that's just my strange inclination ;-))

Cheers again for the info Stu,


Si

I beleive that all GUI power management is performed by Qtopia itself. You should look into QPE server source code.

Simon,

The best place to get familiar with power management is to start reading kernel source. That may sound akward, but if you can read c language, it shouldn't be hard to get an idea fairy quickly. Like Stu says, kapm-idled thread has nothing to do with power management control, all events get sent thru apm api and proceeded by the apm kernel driver (zaurus has no apm bios, so driver accesses hardware directly). And I think Anton is right that Qtopia doesn't relay on anything, all it probably does is just sends apm suspend event when thinks it's a right time to go to suspend. Resume is controlled by kernel via installed hook to On/Off button. Screen backlight and brighteness is different story. There was a sample code on Sharp dev site that demonstrated how to control that thru various IOCTLs. I should have it somewhere, let me know if you need it.

If you have a strongarm-based Zaurus, take a look at the following files:
linux/arch/arm/mach-sa1100/collie_apm.c
linux/arch/arm/mach-sa1100/collie_power.c

For xscale-base Zaurus, looks at:
linux/arch/arm/mach-pxa/sharpsl_apm.c
linux/arch/arm/mach-pxa/sharpsl_power.c

Lineo's code is a bit of mess, but still you should be able to get an idea.
I hope that would help...
-albertr

Thanks for that info.

I had sort of concluded that most of the power management would have to be carried out by Qtopia/Opie itself, but I was a little hesitant as I don't know how idle time can be calculated in that case (to do the light level changes and suspend after various lengths of inactivity). I'll take a look at the launcher code (and the kernel code too) and see whether I can work out what is done to work this out.

So what does kapm-idled actually do? I can only presume that this is merely how the data in /proc/apm is read and written by the kernel?

Thanks for all of your help,

Sorry for the (almost endless) silly questions,


Si

Power management is primarily handled by the kernel, with Qtopia/Opie sending signals when appropriate. For the backlight, Opie's code hidden in libopie/odevice.cpp in the setDisplayBrightness() function. Depending on the kernel in use, it involves writing to either a file in /dev or /proc that is created by the kernel as an interface to the backlight control. I'm not sure off hand how the apm sleep control works, and I don't see the code anywhere. It is likely to be similar to the backlight.

kapm-idled does nothing, literally. It's a kernel thread that puts the cpu to sleep when nothing is happen to conserve power.

It's just a kernel thread that accumulates all time that is not beeing claimed by any other processes, i.e. when the system is idle and there's no processes in a run queue.
Here' s snipset from collie_apm.c that runs inside indefinite loop that you see as "kapm-idled" kernel thread:

        for (;;) {

                /* Nothing to do, just sleep for the timeout */

                timeout = 2*timeout;

                if (timeout > APM_CHECK_TIMEOUT)

                        timeout = APM_CHECK_TIMEOUT;

                schedule_timeout(timeout);

                if (exit_kapmd)

                        break;



                /*

                 * Ok, check all events, check for idle (and mark us sleeping

                 * so as not to count towards the load average)..

                 */

                set_current_state(TASK_INTERRUPTIBLE);

                apm_event_handler();

#ifdef CONFIG_APM_CPU_IDLE

                if (!system_idle())

                        continue;



                if (apm_do_idle()) {

                        unsigned long start = jiffies;

                        while ((!exit_kapmd) && system_idle()) {

                                apm_do_idle();

                                if ((jiffies - start) > APM_CHECK_TIMEOUT) {

                                        apm_event_handler();

                                        start = jiffies;

                                }

                        }

                        apm_do_busy();

                        apm_event_handler();

                        timeout = 1;

                }

#endif

        }

As you can see, we just call apm_do_idle(void) if we have nothing else to do. All the time spent in there is accounted to "kapm-idled" thread.

I don't know how Qtopia calculates inactivity timeout, maybe by measuring time since last key pressed/released and touch-screen events? Just a guess...
-albertr

Good guess - it is so.