On Sat, 31 May 2008 21:47:11 +0200 Joerg Reisenweber <[EMAIL PROTECTED]> babbled:
> > in userspace its simple like this: > > > > 1. screenblank kickis in (if enabled). > > 2. a timer starts for N seconds (default is 10) > > 2.1. if screenblank interrupted (but touschreen press) timer is aborted > > 3. when timer ticks off "apm -s" is executed. > > > > the rest is the job of the apm subsystem and anything intercepting apm > suspend > > requests via the apm bios. technically qpe should be doing this and halting > any > > suspend requests during a phone call for example. no reason any other > process > > can't do the same. apparently the suspend can't be stopped - but it can be > > indefinitely delayed (which is kind of odd - and well... bad - but that's > the > > infra used). > > So I can intercept apm -s (e.g replace by some script), and decide whether I > like to let the device go to sleep or just discard the call. No? > Does anybody care about apm -s call return code? no script. you'll need to open() /proc/apm_bios i think and do some ioctl()'s etc. etc. - don't know the full details, all i knwo is that this is how you get to intercept a suspend request and do something before it. if you don't let the request pass on, then it is paused indefinitely - but never denied. the mechanism itself is rather flawed for stopping suspends - but it is ok for "do this cleanup thing just before suspend". > no device to write to each 5sec to simulate a touch action and thus reset > timer? none. i don't like a watchdog method anyway - its a real hack. i'd rather a sane lockin/out mechanism. you can put a block - and it stays until you remove it, or you die. we do need something much smarter than what we have though. we need some sort of daemon that handles suspending (and doing things on resume) that is trivial to talk to, allows for clients to block suspend for whatever reason the like (eg you are on a call, an ssh session is active etc.). it should also handle other power levels. eg "low power" mode and message all clients to say "go into low power mode" maybe also write the state to a file for those that don't want to connect. but in the end what we REALLY want is zero-clock. no suspend. we want to be able to wake up from zero clock and handle and interrupt within 100-200ms or so. this way being in suspend or not is never going to be the issue. the issue is simply deciding how long after going idle we go into zero clock - and what other separate power saving schemes do we use (screenblanking is another, turning off the touchscreen interrupt when going into "deep sleep" after a period of being idle, letting apps know to slow down or stop their polling if they do such a thing when in "deep sleep", and knowing when to turn interrupts back on on the touchscreen (ie go from deep sleep into high power mode again when an incoming call comes in or sms and you want the screen to come on, and a user possibly to interact with it etc.). so as such right now - we really should have a zero-clock solution imho. that then lets us do all the rest properly :) -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>
