Documentation request: List of sys and other such files
joerg at openmoko.org
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 openmoko.org>
> > > 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
> 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,
> 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 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080601/c38f1192/attachment.pgp
More information about the openmoko-kernel