backlight device, suspend/resume... / Suspend during calls
Carsten Haitzler (The Rasterman)
raster at openmoko.org
Wed Jul 9 17:34:02 CEST 2008
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
> |> | 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
> 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
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
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>
More information about the openmoko-kernel