backlight device, suspend/resume... / Suspend during calls

[Carsten Haitzler (The Rasterman)]

On Wed, 09 Jul 2008 16:21:01 +0100 Andy Green <andy at openmoko.com> babbled:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> | On Wed, 09 Jul 2008 15:23:59 +0100 Andy Green <andy at openmoko.com> babbled:
> |
> |> -----BEGIN PGP SIGNED MESSAGE-----
> |> Hash: SHA1
> |>
> |> Somebody in the thread at some point said:
> |>
> |> |> That blocking "veto" is a simple but fairly reliable way to come at it
> |> |> (although it might need some musing if the app crashes).  If you held
> |> |> open some magic dev node or somesuch while you wanted to stay up, that
> |> |> would be reaped cleanly on app exit by crash or exit.
> |> |
> |> | yeah. right now on app crash the veto stays. i need to track the dbus
> |> client and
> |> | see if it loses its dbus connection. right now though anyone can
> |> remove a block
> |> | even if you are not the owner. it's meant to be simple so u can do
> |> this from
> |> | scripts using dbus-send so the dbus connection going away doesn't
> impact
> |> | anything. i know it has pitfalls, but for now am willing to live with
> |> them.
> |>
> |> Well OK, I will direct people who don't like this "userspace shakiness"
> |> that results to Werner and yourself for "re-education".
> |>
> |> | btw - how do you turn off touchscreen interrupts from userspace? i
> |> really want
> |> | to actually! :) i just want to disable the touchscreen (and re-enable
> |> it later
> |> | when needed).
> |>
> |> Why do you want to kill the interrupts?  They only fire if stylus down
> |> anyway.  Just ignore /dev/input/event1 or tslib or whatever it is by
> |> then.  I think it's really cheap on power to run if no stylus down (and
> |> there are no interrupts happening then), it supplies via a large series
> |> resistor when idle and waiting for stylus down.  There's no ts api type
> |> thing to do it that I saw.
> |
> | there is no mechanism in x to tell it to ignore its core pointer
> device input,
> | so i was hoping to just turn it off outside of x. this means i need to
> develop
> 
> There is no touchscreen "API" in linux, you roll it yourself in the
> driver with input subsystem.
> 
> But just hold up a minute, this too is part of the larger issues around
> suspend and power management I keep alluding to, finegrained control
> over individual peripheral power state.  You can't do this stuff in
> userspace.

you can - if the kernel lets you. i can very easily have a userspace daemon go
"i see you want to suspend. i am going to turn off touchscreen interrupts now,
so if i resume and the resume is for gsm for example i wont re-enable
touchscreen so x can't get any ts events and wake up the screen just because
the cpu woke up to handle some cell broadcast message". :)

> Somebody (it wasn't one of the usual suspects either) had a cool idea to
> abuse the suspend / resume callbacks by calling them to implement
> finegrained power management.  THIS is something new, cool, fairly small
> and giving new powers: you can then utilize this API to request ts (or
> anything else with suspend / resume callbacks) to put itself into "off
> mode".

this would be very nice. then userspace can fine-grained suspend/turn off
specific devices when/if needed.


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>