-----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. 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". - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh0110ACgkQOjLpvpq7dMqRJACdEQLPpYnGQfKofgk4BBhtJzpb qQEAnA5/r4Mz7mfuLQ7ItKqa+daJLUjj =v8Qs -----END PGP SIGNATURE-----
