Documentation request: List of sys and other such files

Joerg Reisenweber joerg at
Sun Jun 1 02:27:33 CEST 2008

Am So  1. Juni 2008 schrieb Carsten Haitzler:
> On Sat, 31 May 2008 21:47:11 +0200 Joerg Reisenweber <joerg at>
> 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 
> > 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 
> > > indefinitely delayed (which is kind of odd - and well... bad - but 
> > the
> > > infra used).
> > 
> > So I can intercept apm -s (e.g replace by some script), and decide whether 
> > 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 
> etc. etc. - don't know the full details, all i knwo is that this is how you 
> to intercept a suspend request and do something before it. if you don't let 
> 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 
> it, or you die. we do need something much smarter than what we have though. 
> need some sort of daemon that handles suspending (and doing things on 
> that is trivial to talk to, allows for clients to block suspend  for 
> 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 
> 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 
> 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 
> they do such a thing when in "deep sleep", and knowing when to turn 
> 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. 
> then lets us do all the rest properly :)
> -- 
> Carsten Haitzler (The Rasterman) <raster at>

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : 

More information about the openmoko-kernel mailing list