Am So 1. Juni 2008 schrieb Carsten Haitzler: > 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]> >
100% ACK. Just for now: when I like to run some script to [scan WiFi|flash LED|whatever], how shall I avoid to have to tap the screen every 10sec, to block suspend? On OM stack there was a power setting to disable suspend all together [[dim, then lock...]], is there a config file|device|* to control this behavior from out of my script? /j
signature.asc
Description: This is a digitally signed message part.
