Documentation request: List of sys and other such files

[Carsten Haitzler (The Rasterman)]

On Sat, 31 May 2008 21:47:11 +0200 Joerg Reisenweber <joerg at openmoko.org>
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) <raster at openmoko.org>