On Mon, 2011-10-17 at 15:11 +0100, Matthew Garrett wrote: > On Mon, Oct 17, 2011 at 03:06:26PM +0200, Peter Zijlstra wrote: > > On Mon, 2011-10-17 at 13:46 +0100, Matthew Garrett wrote: > > > They're orthogonal. Sometimes you want timer-driven behaviour (how else > > > are you going to draw animations?) and that's obviously going to > > > generate wakeups. This is for the idle case, where the user is no longer > > > sitting in front of the machine but you don't want to trigger a full > > > system suspend. We either need every application that ever uses > > > timer-driven behaviour to support setting its own timer slack on some > > > sort of external policy decision, or we need a way to let the kernel > > > force them to. > > > > No!! you want that application to stop drawing stuff that is invisible. > > Setting your own timerslack for something you know is pointless is worse > > than doing something pointless, its down right stupid. > > Whether or not you want the animation to carry on animating is policy, > and you need something to be the policy agent. Let's say firefox is > invisible. I now grab a copy of its window contents. What do I get? An XDamage and repaint from the X client, after which your copy will complete and you get what you asked for? > > Please, work with the X folks and make it an error to draw to invisible > > surfaces. And yes, I know that composition makes that a non-trivial > > problem. But at least the blank screen case should be trivial, and I > > suspect there's more tractable cases as well. Mostly the desktop is > > still a very static place and a few extra timer ticks for when you're > > spinning your desktop cube around isn't going to be a problem. > > So, just to be clear on this, you want to change the semantics of X and > modify every piece of userspace that currently uses X (because it'll now > otherwise crash when the screen blanks) Or even when I minimize firefox. That said, ff will probably crash as soon as I open a second tab because the retarded thing will very likely continue animating everything on the invisible tab anyway. You could start by making the X lib of the day, is that XCB these days?, issue an error print (you get plenty of those anyway) and progress to full on crashing later. This gives developers a migration window and incentive to fix up their apps. > in preference to merging a piece > of code that's functionally consistent with the rest of the cgroups > infrastructure? Yep.. because as of yet there isn't a sane use-case to warrant adding the maintenance burden. Any cgroup controller is functionally consistent, per definition, that doesn't make it useful or even sane. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
