Il Sat, Jan 28, 2006 at 12:22:07AM +0100, Pavel Machek ha scritto:
> > > On www.sf.net/projects/suspend , there's s2ram.c program for
> > > suspending machines. It contains whitelist of known machines, along
> > > with methods to get their video working (similar to
> > > Doc*/power/video.txt). Unfortunately, video.txt does not allow me to
> > > fill in whitelist automatically, so I need your help.
> > >
> > > I do not yet have solution for machines that need vbetool; fortunately
> > > my machines do not need that :-), and it is pretty complex (includes
> > > x86 emulator).
> >
> > What about adding something like:
> >
> > void s2ram_restore(void) {
> > if (needed)
> > fork_and_exec(vbetool);
> > }
> >
> > machine_table could set a global flag or something. It would be
> > possibile to us an array to carry the informations about what need to be
> > done on restore, i.e. something like:
>
> I can imagine fork_and_exec... Disadvantages are:
>
> * if disk driver is toast, user does not see anything
>
> * vbetool can be missing from the system, or wrong version, or
> something like that.
>
> Other solution is to just integrate vbetool into s2ram. Advantages
> are:
>
> * s2ram is nicely integrated.
>
> Disadvantages are:
>
> * code duplication.
>
> If vbetool's primary purpose is to fix video after suspend/resume,
> then perhaps right thing to do is to integrate it into s2ram and
> maintain it there.
>
> Matthew, what do you think?
>
> Luca, would you cook quick&hacky fork-and-exec patch? I do not have
> machine that needs vbetool...
Very quick and very hacky ;)
The following patch works on my notebook. A few notes about it:
- I must stop acpid before suspending otherwise it will get a "power
button pressed" event on resume and shutdown the machine; not related
to s2ram though.
- vbetool manpage says that it must be invoked from a text console;
since it works from X on my system I never bothered to do a chvt from
my suspend script.
- I always save state before suspend since sometimes I STR from X,
sometimes from the console and the state file generated by vbetool is
different. According to Matthew Garrett this will break on some
setups... if state needs to the saved before X is started then I guess
that we need an init script that dump the state in a known place; even
if you integrate vbetool into s2ram it will need the state file, so if
the disk doesn't come back to life you're screwed...
--- suspend/s2ram.c 2006-01-28 13:59:41.000000000 +0100
+++ suspend/s2ram.c 2006-01-28 14:19:37.000000000 +0100
@@ -15,2 +15,4 @@ int test_mode;
+static int need_vbetool;
+
static void machine_known(void)
@@ -49,2 +51,9 @@ static void machine_table(void)
}
+ if (!strcmp(sys_vendor, "ASUSTEK ")) {
+ if (!strcmp(sys_product, "L3000D")) {
+ machine_known();
+ need_vbetool = 1;
+ return;
+ }
+ }
@@ -59,2 +68,30 @@ static void machine_table(void)
+static int vbe_state_save() {
+ int err;
+
+ err = system("vbetool vbestate save > /tmp/.vbe.state");
+ if (err)
+ printf("vbetool failed to save video state with error %d\n.", err);
+
+ return err;
+}
+
+static int vbe_state_restore() {
+ int err;
+
+ err = system("vbetool post");
+ if (err) {
+ printf("vbetool failed to POST video board with error %d.\n", err);
+ return err;
+ }
+
+ err = system("vbetool vbestate restore < /tmp/.vbe.state");
+ if (err)
+ printf("vbetool failed to restore video state with error %d.\n", err);
+
+ remove("/tmp/.vbe.state");
+
+ return err;
+}
+
/* Code that can only be run on non-frozen system. It does not matter now
@@ -66,2 +103,5 @@ void s2ram_prepare(void)
machine_table();
+ if (need_vbetool)
+ if (vbe_state_save())
+ exit(1);
}
@@ -81,2 +121,7 @@ void s2ram_do(void)
+void s2ram_resume(void) {
+ if (need_vbetool)
+ vbe_state_restore();
+}
+
int main(int argc, char *argv[])
@@ -103,2 +148,3 @@ int main(int argc, char *argv[])
s2ram_do();
+ s2ram_resume();
return 0;
Luca
--
Home: http://kronoz.cjb.net
"Chi parla in tono cortese, ma continua a prepararsi, potra` andare avanti;
chi parla in tono bellicoso e avanza rapidamente dovra` ritirarsi"
Sun Tzu -- L'arte della guerra
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]