backlight device, suspend/resume...

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

|> What happens if we reversed this then, anything blow up?
|
| Yes, everything. Please leave it as is.

OK.

|> We clearly need a "resume reason handler" who operates before backlight
|> comes up at least and can fire some kind of event to userspace apps
|> blocked until they fire, even decide to go back to suspend afterwards if
|> if the app waiting on the event handled it and said it was OK.
|
| I agree. Can we add a sysfs node where we echo a filename into (think
hotplug
| handler)? Or would the more modern approach be to send this out via a
netlink
| socket and have userland listen there?

I guess the sysfs way is easier on everyone (even make ash scripts like
that)... also its compatible with schedule action, it votes for suspend
and blocks as you write "5m" or something there, with a promise to come
out of suspend and unblock in 5m.

But I can't quite see how the semantics of writing it there work, ie,
what it means, when some things might want to stay up, etc.  It needs
some kind of global view and simple easily expressed action to be
architected correctly.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhzfEMACgkQOjLpvpq7dMp/cgCgi1HUaDc+TaGhERdYLrZDyV5i
FksAn0NyiZBWVdloWU0rpAqcabujXbQD
=SIJB
-----END PGP SIGNATURE-----