I note your interest, and I will guys let you know when I have an IPK ready. This will be for a 2.4 kernel, by the way (I will be using pdaXii13 to compile this, but fortunately I think there are no binaries in this package, so it should be actually compatible with any kernel ) I am working on finishing the Fluxbox 1.0.0 package (tracking how to provide for auto-rotate at the moment,) and when I get done with that I'll look into IPK control file syntax, because this package will replace some startup scripts in the system.
As a form of informal documentation, I'm going to provide a little overview on this issue, which has a couple of different facets:
Naturally, KO/PI needs to rely on the OS itself to wake up the device before KO/PI can issue an alarm. Originally (and I'm talking in the Sharp ROM versions,) I believe KO/PI used the atd/at infrastructure, and that worked perfectly fine. In pdaXrom I'm not aware of the original situation, but at some point one of the users in the forum (caitlin, I believe) provided a solution using apm instead. This solution was a step in the right direction, but due to some bugs pertaining to apm (namely, the inability of apm to schedule wakeups wrapping around midnight) it showed some problems. Then, another user (I think zumi) came up with a solution using atd/at, and that worked mostly to perfection.
I say mostly, because there was a conflict with one of the suspend scripts that Meanie had implemented in order to preserve the integrity of the system clock on suspend/resume. That script needed to use hwclock, and because hwclock can't run while atd is running, it thus shut down atd when the Zaurus was suspended, and woke it up again on resume. This obviously made atd incapable of waking up the Zaurus to respond to the KOPI alarm. Not only that, but due to some implementation details, it caused the Zaurus to not be able to wake up in some situations, which made it necessary to perform a hard reset. I have solved this problem by stopping atd just before invoking hwclock, and waking it up right after that, both in the suspend and resume scripts.
The other issue that I found (which I referred to in this thread) has to do with a bug in the script that decides which of the KO/PI alarms to use (the pending alarm or the suspended alarm.) When the Zaurus is going into a suspend, a script looks into both of these alarms, and due to a bug in the script, suspended alarms were not being chosen if there existed a pending alarm, even if the pending alarm had expired.
Sorry if I have gotten any names or details wrong, but this is a basic outline of the problem.
My solution is quite simple (about 3 lines added/modified in a few different scripts.) But I will release an IPK, because it's good practice to do so, plus it will give me a good chance to look into how the control script in IPKs is coded.
