Paul Fox <[email protected]> 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/
pgpGcv5nktLnz.pgp
Description: PGP signature
_______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
