Re: Determining idleness when auto-suspending

["Odysseus Flappington" <deriziotis gmail com>]

On 14/11/2007, Richard Hughes <hughsient gmail com> wrote:

> Obviously, I don't think that this has to specifically include all
> devices that make up a system. For instance, checking the graphics
> card to see whether it's in use would be useless since a screensaver
> could be using it while the computer is idle. However, if data being
> transferred through the network interface, then I should think it's
> safe to say that the computer isn't idle

I don't think this is correct - liferea could be downloading new rss
feeds or PackageKit downloading updates; both of these can be
interrupted (and should be) to suspend on battery while idle.

I can see the problem here. I feel a bit dumb for not spotting this sooner. As there's no way to tell the OS to ignore traffic from a specific application, there's no way to say 'inhibit the OS if there's traffic on eth0, but not if it's from PackageKit', unless you start trying to check patterns of traffic, which I agree would be a very bad idea.

> I would at least think things like the hard-drive, network interfaces,
> audio devices, firewire, pc cards and usb devices can be queried at
> all times to see if they're in use and effectively allow the OS to
> automatically determine whether the computer can be suspended or not.

Err, no polling allowed. It all has to be async.

Why? Because it consumes too much power? Even if it's only polling at large intervals?

> If querying other devices on a system is just as easy, would we not be
> interested in coming up with a mechanism to automate determining when
> the computer is idle? For what reasons are we not looking into this
> kind of solution? If it's possible, it seems like it would be a much
> more elegant solution than putting the ownus on every single developer
> that wants to write an app that will work in Gnome.

No. Say you are writing a CD-Writer application. You only want to
prevent suspending when actually writing the disk, not when you are
choosing files and then get called away by the doorbell.

The cd-rom doesn't remain spun-up while you're 'choosing files', only when it's actually in the middle of reading from the device. i.e. while listening to music, playing music, or copying files. I don't see how this situation will cause the OS to inhibit suspending.

What I'm trying to say is that only the application knows itself what is
a good idea and what isn't - guessing based upon some heuristic is not a
good idea in my opinion. If you want something that does do heuristics,
have a look at OHM, although that is targeted mainly to embedded stuff
like OLPC.

I see what you mean, and it makes sense. It is a heuristic process, and should definitely be avoided from the moment that it can make it impossible for some applications to have the computer suspend despite knowing they shouldn't be inhibiting it. However, the question remains, are there any devices that can be said with certainty shouldnt be interrupted while in use?

Seeing as from your point before, the network interface will be impractical to poll, but how about the audio device? It is even possible to even submit a bug to gstreamer and have them inhibit the OS when the audio device is in use. Is this something that would be aligned with the requirements of the user?

I can understand leaving firefox open on a flash advert which is using the soundcard might be a problem, but how many flash adverts loop the ad and continuously use the soundcard? Also, if I leave a webpage open on a page playing sound, should I expect the computer to auto-suspend? Personally, I don't really fully see this as expected behaviour. It could go either way. It would be nice to have a default, but then have a set of options to tweak the behaviour as I see fit.

Not to mention cdroms. I should think that at least when writing to a cdrom, it is definitely safe to inhibit the os from suspending, and as far as I can tell, also reading.

Have we considered a set of base-rules that we are certain won't have exceptions? It's not a complete framework, but I believe it could work as an underlying framework that would certainly make a difference to alot of users out there.

Alex Deriziotis