[PATCH powerd] Inhibit suspend while audio device is open

[Sascha Silbe]

Paul Fox <pgf at laptop.org> writes:

> i'm perfectly happy to enable this, if we think it fixes the problem
> well enough, and/or we think the applications can be fixed to do the
> right thing.  (for some reasonable value of "we".)

It does for me, but as much testing as I may have done can never account
for a million devices in the field. It does more good than harm (and
even the harm is on the "safe" side of consuming more power rather than
disrupting operation), so I'd recommend to merge it at least for the
next release (post-12.1). Whether it should go into 12.1 at this point
in time is not my call to make.


> in searching for a relevant ticket on d.l.o.  just now, i found #6670,
> which is quite relevant, if perhaps a bit dated. 

Thanks for the reference and for CC'ing me. I've commented on the
ticket; repeating here for convenience of others following this thread:

As Paul pointed out correctly on the mailing list (or maybe IRC), simply
reading the current status of the audio device is just a point-in-time
check. inotify doesn't notice changes to the status file either. So in
theory we're opening ourselves up for a race condition. However, it
would be a problem even with a better check: AFAICT using the audio
device doesn't increment wakeup_count, so if an Activity started using
the audio device right before we suspend, we'd have the same problem.

In practice, it will probably be less of a problem, as most usage of
audio devices is going to be the direct result of some external event
(user input or network traffic).

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20120522/325e0878/attachment.sig>