Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 03 Jun 2010 17:28:01 +0200
Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
> > On Thu, 03 Jun 2010 09:40:02 +0200
> > Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > 
> > > Same for firefox, you can teach it to not render animated gifs and run
> > > javascript for invisible tabs, and once the screen-saver kicks in,
> > > nothing is visible (and with X telling apps their window is visible or
> > > not it knows), so it should go idle all of its own.
> > > 
> > > Fix the friggin apps, don't kludge with freezing.
> > 
> > Of course programs should be as smart as possible. But that is an
> > orthogonal problem.
> > 
> > Suppose firefox were fixed. It still needs to fetch my rss feeds every
> > minute, because I'm sad if it doesn't. It just can't be fixed at the
> > application level.
> 
> Sure it can, why would it need to fetch RSS feeds when the screen is off
> and nobody could possible see the result? So you can stop the timer when
> you know the window isn't visible or alternatively when the screensaver
> is active, I think most desktops have notification of that as well.

This is arguing on a very thin line. In fact it is becoming pointless. 

Suppose there were an RSS-feed plugin that signals events to an event
Plugin. That event plugin could be either visual notification or sending
audio-signals. But the RSS feed doesn't know what specific plugin it
talks to. So screen off is _not always_ the right indicator. Sometimes
it is, sometimes it's not. 
There would be a seperate infrastructure needed in the program to tell
the different plugins that the core thinks everything should stop.
How does the core knows when to stop? And then there probably need to
be some kind of "suspend blockers" in the program. *g*

Just solve it at the right level, so that the apps don't need to be
infected with this shit. And this belongs between the iron and the
apps. And it seems it needs to be some cooperative approach of kernel
and userspace-framework as it isn't right to put that much policy in
the kernel.

I don't think it is a black and white thing, where you can just say
"fix the friggin apps". 

And this is a really f*beep*ng serious point. (at least to me)

Cheers,
Flo

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux