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

[Carsten Haitzler (The Rasterman)]

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
a new extension and new protocol calls - and given x is running out of
extension i'd rather not go invent a new x extension, new protocol, new x
internals, new x library to access the extension etc. so its me looking for a
much simpler solution. the alternative is to throw out all of x's blanking
infrastructure and re-implement is elsewhere. blank the screen outside of x and
dont use its inactivity timeouts or use them in a very different way.

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