[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.00.0802211723510.19896@woody.linux-foundation.org>
Date: Thu, 21 Feb 2008 17:28:53 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jesse Barnes <jesse.barnes@...el.com>
cc: Jeff Chua <jeff.chua.linux@...il.com>,
Romano Giannetti <romano@....icai.upcomillas.es>,
suspend-devel List <suspend-devel@...ts.sourceforge.net>,
Dave Airlie <airlied@...ux.ie>, Greg KH <gregkh@...e.de>,
lkml <linux-kernel@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...k.pl>, linux-acpi@...r.kernel.org
Subject: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off
aftersuspend-to-disk. Screen becomes green.
On Thu, 21 Feb 2008, Jesse Barnes wrote:
>
> So the advantage of the kernel suspend/resume hooks for the DRM layer is that
> the kernel video drivers can do full state save/restore (which X usually
> doesn't do, and isn't really designed to do), so that if your platform
> *doesn't* do it all, you'll still end up with a usable machine in the end.
Well, I'm also hoping that eventually we could even just not do the VT
switch at all, and the kernel can treat X as "just another user process"
that it freezes.
At least from a mode setting standpoint.
We'd still want to make sure that X repaints the screen if the contents
were lost, of course. And this is going to depend very intimately on the
type of graphics card and whether the video RAM is saved by STR or not -
for the Intel integrated graphics kind of situation, the video RAM will be
refreshed along with all the other memory, but for other cards we may end
up having to do the VT switch not so much for modesetting reasons as just
a way to get X to save and restore all the *other* state.
How close is the i915 driver from not having to even signal X? Or is that
just a pipedream of mine?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists