Documentation request: List of sys and other such files

[Joerg Reisenweber]

Am So  1. Juni 2008 schrieb Carsten Haitzler:
> 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>
> 


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
-------------- 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 : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080601/c38f1192/attachment.pgp