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

Andy Green andy at
Wed Jul 9 17:21:01 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| On Wed, 09 Jul 2008 15:23:59 +0100 Andy Green <andy at> babbled:
|> 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

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

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list