On Wed, 09 Jul 2008 16:21:01 +0100 Andy Green <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]>
