On Fri, Jul 27, 2007 at 06:21:56PM +0300, Alon Bar-Lev wrote:
> On 7/27/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > > (yes, i think i know what it does; writing 1 into the state of the
> > > framebuffer device just disables any drawing - and thus any access
> > > of possibly not really initialized hardware before running vbe_post
> > > etc...)
> > > At least it seemed to do no harm in my (limited) tests.
> >
> > I think it can go if
> > (1) it doesn't break any setups that currently work
> > (2) it fixes at least one box that currently doesn't work
>
> I don't wish to annoy any of you...
> But if it can be done via regular scripts before s2ram, why merging it?
> s2ram can be as small as possible having hibernate-script or pm-utils
> do this work...
> The same goes to vbe and stuff.
i'd guess s2ram.c will be pretty small then:
int main()
{
return 0;
}
;-))
But this is not the goal of s2ram, as i hopefully already explained
sufficiently in an earlier mail.
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel
