* Suspend to RAM: help with whitelist wanted @ 2006-01-26 21:36 Pavel Machek 2006-01-27 17:04 ` Luca 0 siblings, 1 reply; 16+ messages in thread From: Pavel Machek @ 2006-01-26 21:36 UTC (permalink / raw) To: seife, kernel list Hi! 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). Routine I'd like you to modify looks like: if (!strcmp(sys_vendor, "IBM")) { if (!strcmp(sys_version, "ThinkPad X32")) { machine_known(); set_acpi_video_mode(3); radeon_backlight_off(); return; } } ... so it is pretty easy (but any patches are welcome). Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-26 21:36 Suspend to RAM: help with whitelist wanted Pavel Machek @ 2006-01-27 17:04 ` Luca 2006-01-27 23:05 ` Pavel Machek 2006-01-27 23:22 ` Pavel Machek 0 siblings, 2 replies; 16+ messages in thread From: Luca @ 2006-01-27 17:04 UTC (permalink / raw) To: Pavel Machek; +Cc: linux-kernel Pavel Machek <pavel@suse.cz> ha scritto: > Hi! > > 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: void machine_table() { if ((!strcmp(sys_vendor, "ASUS")) { if (!strcmp(sys_version, "My notebook")) { machine_known(); on_resume[NEED_VBETOOL] = 1; return; } } } void s2ram_restore(void) { if (on_resume[NEED_VBETOOL]) fork_and_exec(vbetool); if (on_resume[NEED_RADEON_STUFF]) radeon_stuff(); if (on_resume[NEED_FOOBAR]) black_magic(); } Ugly? Maybe, but you don't have to fiddle with a x86 emulator. Luca -- Home: http://kronoz.cjb.net Windows NT: Designed for the Internet. The Internet: Designed for Unix. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-27 17:04 ` Luca @ 2006-01-27 23:05 ` Pavel Machek 2006-01-28 1:05 ` Olivier Galibert 2006-01-27 23:22 ` Pavel Machek 1 sibling, 1 reply; 16+ messages in thread From: Pavel Machek @ 2006-01-27 23:05 UTC (permalink / raw) To: Luca; +Cc: linux-kernel On Pá 27-01-06 18:04:06, Luca wrote: > Pavel Machek <pavel@suse.cz> ha scritto: > > Hi! > > > > 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); > } Yes... that's what I wanted to avoid. ... ... I originally wanted to avoid calling external problems. That way, s2ram code could be pagelocked and you would get your video back even in case of disk problems etc. [I thought that it would bring problems with suspend-to-both; but I was wrong, no such problem exists.] > Ugly? Maybe, but you don't have to fiddle with a x86 emulator. ...and then there's a issue of how to do vbetool vbestate save. According to docs it should be done just once, but that looks pretty fragile to me. Perhaps we can just do it unconditionaly? Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-27 23:05 ` Pavel Machek @ 2006-01-28 1:05 ` Olivier Galibert 2006-01-28 8:12 ` Pavel Machek 0 siblings, 1 reply; 16+ messages in thread From: Olivier Galibert @ 2006-01-28 1:05 UTC (permalink / raw) To: Pavel Machek; +Cc: linux-kernel On Sat, Jan 28, 2006 at 12:05:35AM +0100, Pavel Machek wrote: > I originally wanted to avoid calling external problems. That way, > s2ram code could be pagelocked and you would get your video back even > in case of disk problems etc. You should not add yet another program that does video card accesses from userspace. The xorg and fbdev developpers are having a hard enough time already making sure both sides have a consistent view of the video card state, and it looks like they're on the way to unifying as much as they can in the kernel under drm just because of these difficulties. Do not add to them by frobbing the card in unpredictable ways from userspace, please. OG. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-28 1:05 ` Olivier Galibert @ 2006-01-28 8:12 ` Pavel Machek 0 siblings, 0 replies; 16+ messages in thread From: Pavel Machek @ 2006-01-28 8:12 UTC (permalink / raw) To: Olivier Galibert, linux-kernel On So 28-01-06 02:05:25, Olivier Galibert wrote: > On Sat, Jan 28, 2006 at 12:05:35AM +0100, Pavel Machek wrote: > > I originally wanted to avoid calling external problems. That way, > > s2ram code could be pagelocked and you would get your video back even > > in case of disk problems etc. > > You should not add yet another program that does video card accesses > from userspace. The xorg and fbdev developpers are having a hard There's no other solution, sorry. xorg are not even involved -- we do it on text console. And unless you want x86 emulator in kernel, we need something to restore our video in userspace. Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-27 17:04 ` Luca 2006-01-27 23:05 ` Pavel Machek @ 2006-01-27 23:22 ` Pavel Machek 2006-01-28 1:31 ` Matthew Garrett 2006-01-28 15:58 ` Luca 1 sibling, 2 replies; 16+ messages in thread From: Pavel Machek @ 2006-01-27 23:22 UTC (permalink / raw) To: Luca, mjg59; +Cc: linux-kernel Hi! > > 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... Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-27 23:22 ` Pavel Machek @ 2006-01-28 1:31 ` Matthew Garrett 2006-01-28 8:42 ` Pavel Machek 2006-01-28 15:58 ` Luca 1 sibling, 1 reply; 16+ messages in thread From: Matthew Garrett @ 2006-01-28 1:31 UTC (permalink / raw) To: Pavel Machek; +Cc: Luca, linux-kernel On Sat, Jan 28, 2006 at 12:22:07AM +0100, Pavel Machek wrote: > 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. That's the primary purpose, though there's a couple of edge cases. For VBE state saving/restoring, it seems to be important to save the state before X has started rather than doing so at suspend time - some i855 systems break otherwise. Not strictly related - Pavel, try taking a look at the acpi-support package in http://archive.ubuntu.com/ubuntu/pool/main/a/acpi-support/ . There's a large list of witelisted hardware there. OSDL recently set up a mailing list (desktop-portables@lists.osdl.org) for cross-distribution laptop discussion. It would probably be helpful to discuss working machines there, rather than duplicate the whitelisting efforts. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-28 1:31 ` Matthew Garrett @ 2006-01-28 8:42 ` Pavel Machek 2006-01-29 7:12 ` Matthew Garrett 0 siblings, 1 reply; 16+ messages in thread From: Pavel Machek @ 2006-01-28 8:42 UTC (permalink / raw) To: Matthew Garrett; +Cc: Luca, linux-kernel Hi! > > 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. > > That's the primary purpose, though there's a couple of edge cases. > For VBE state saving/restoring, it seems to be important to save the > state before X has started rather than doing so at suspend time - some > i855 systems break otherwise. Well, doing it at boot is slightly ugly; I'd like s2ram to just work, and not need boot-time-hooks. [If there's no other solution... what can I do, but I do not like it.] > Not strictly related - Pavel, try taking a look at the acpi-support > package in http://archive.ubuntu.com/ubuntu/pool/main/a/acpi-support/ . > There's a large list of witelisted hardware there. OSDL recently set > up Thanks for pointer! Anyway, AFAICT the list is not really adequate. It lists working machines, but does not really list all the switches neccessary to get the video working. (Well, it tries in some cases, *strange*, perhaps less switches are neccessary than I think?) > a mailing list (desktop-portables@lists.osdl.org) for cross-distribution > laptop discussion. It would probably be helpful to discuss working > machines there, rather than duplicate the whitelisting efforts. I'm afraid I don't have a time for another mailing list, and this should not be really related to the desktop... Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-28 8:42 ` Pavel Machek @ 2006-01-29 7:12 ` Matthew Garrett 2006-02-04 21:11 ` Pavel Machek 0 siblings, 1 reply; 16+ messages in thread From: Matthew Garrett @ 2006-01-29 7:12 UTC (permalink / raw) To: Pavel Machek; +Cc: Luca, linux-kernel On Sat, Jan 28, 2006 at 09:42:25AM +0100, Pavel Machek wrote: > Well, doing it at boot is slightly ugly; I'd like s2ram to just work, > and not need boot-time-hooks. [If there's no other solution... what > can I do, but I do not like it.] Indeed. The symptoms are that X stops drawing the background to windows, and it seems to be very strongly tied to saving the state while X is running (even if X is not currently the foreground VT). > Thanks for pointer! Anyway, AFAICT the list is not really adequate. It > lists working machines, but does not really list all the switches > neccessary to get the video working. (Well, it tries in some cases, > *strange*, perhaps less switches are neccessary than I think?) For machines where nothing is listed, we do POSTing and restore the VBE state. These may not be necessary in all cases, but they don't seem to be actively harmful except on the machines where they're explicitly switched of.f -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-29 7:12 ` Matthew Garrett @ 2006-02-04 21:11 ` Pavel Machek 0 siblings, 0 replies; 16+ messages in thread From: Pavel Machek @ 2006-02-04 21:11 UTC (permalink / raw) To: Matthew Garrett; +Cc: Luca, linux-kernel Hi! > > Thanks for pointer! Anyway, AFAICT the list is not really adequate. It > > lists working machines, but does not really list all the switches > > neccessary to get the video working. (Well, it tries in some cases, > > *strange*, perhaps less switches are neccessary than I think?) > > For machines where nothing is listed, we do POSTing and restore the VBE > state. These may not be necessary in all cases, but they don't seem to > be actively harmful except on the machines where they're explicitly > switched of.f Ahha, nice. vbetool seems to work on very wide range of machines. Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-27 23:22 ` Pavel Machek 2006-01-28 1:31 ` Matthew Garrett @ 2006-01-28 15:58 ` Luca 2006-01-28 16:04 ` Jan De Luyck ` (2 more replies) 1 sibling, 3 replies; 16+ messages in thread From: Luca @ 2006-01-28 15:58 UTC (permalink / raw) To: Pavel Machek; +Cc: Matthew Garrett, linux-kernel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-28 15:58 ` Luca @ 2006-01-28 16:04 ` Jan De Luyck 2006-01-28 17:11 ` Luca 2006-01-28 16:27 ` Pavel Machek 2006-01-28 16:36 ` Pavel Machek 2 siblings, 1 reply; 16+ messages in thread From: Jan De Luyck @ 2006-01-28 16:04 UTC (permalink / raw) To: linux-kernel, kronos; +Cc: Pavel Machek, Matthew Garrett On Saturday 28 January 2006 16:58, Luca wrote: > - 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. You can fix that by e.g creating a file /tmp/acpi_sleep, and checking in the powerbutton routine if the file is present. Delete it if it is present, and just shutdown the machine if not. I have to do that too on my Acer TM803. -- If this were Ada, I suppose we'd just constant fold 1/0 into die "Illegal division by zero" -- Larry Wall in <199711100226.SAA12549@wall.org> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-28 16:04 ` Jan De Luyck @ 2006-01-28 17:11 ` Luca 0 siblings, 0 replies; 16+ messages in thread From: Luca @ 2006-01-28 17:11 UTC (permalink / raw) To: Jan De Luyck; +Cc: linux-kernel Il Sat, Jan 28, 2006 at 05:04:18PM +0100, Jan De Luyck ha scritto: > On Saturday 28 January 2006 16:58, Luca wrote: > > - 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. > > You can fix that by e.g creating a file /tmp/acpi_sleep, and checking in the > powerbutton routine if the file is present. Delete it if it is present, and > just shutdown the machine if not. > > I have to do that too on my Acer TM803. Well this is not a big deal, my suspend script just does: /etc/init.d/acpid stop echo mem > /sys/power/state /etc/init.d/acpid start Luca -- Home: http://kronoz.cjb.net La vasca da bagno fu inventata nel 1850, il telefono nel 1875. Se fossi vissuto nel 1850, avrei potuto restare in vasca per 25 anni senza sentir squillare il telefono ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-28 15:58 ` Luca 2006-01-28 16:04 ` Jan De Luyck @ 2006-01-28 16:27 ` Pavel Machek 2006-01-28 16:36 ` Pavel Machek 2 siblings, 0 replies; 16+ messages in thread From: Pavel Machek @ 2006-01-28 16:27 UTC (permalink / raw) To: Luca; +Cc: Matthew Garrett, linux-kernel Hi! > > > 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. I work around this one by pressing lid button to wake the machine up. > - 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... No, I'm not... I'd just load state file into memory before even starting suspend :-). Thanks for the patch! Pavel > --- 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 -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-28 15:58 ` Luca 2006-01-28 16:04 ` Jan De Luyck 2006-01-28 16:27 ` Pavel Machek @ 2006-01-28 16:36 ` Pavel Machek 2006-01-29 14:42 ` Luca 2 siblings, 1 reply; 16+ messages in thread From: Pavel Machek @ 2006-01-28 16:36 UTC (permalink / raw) To: Luca; +Cc: Matthew Garrett, linux-kernel Hi! > > 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 ;) Thanks; applied after some cleanups. Could you fetch it from cvs and confirm it still works? Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Suspend to RAM: help with whitelist wanted 2006-01-28 16:36 ` Pavel Machek @ 2006-01-29 14:42 ` Luca 0 siblings, 0 replies; 16+ messages in thread From: Luca @ 2006-01-29 14:42 UTC (permalink / raw) To: Pavel Machek; +Cc: linux-kernel Il Sat, Jan 28, 2006 at 05:36:11PM +0100, Pavel Machek ha scritto: > > > 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 ;) > > Thanks; applied after some cleanups. Could you fetch it from cvs and > confirm it still works? Yup, it's ok. Luca -- Home: http://kronoz.cjb.net The trouble with computers is that they do what you tell them, not what you want. D. Cohen ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2006-02-04 21:11 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-01-26 21:36 Suspend to RAM: help with whitelist wanted Pavel Machek 2006-01-27 17:04 ` Luca 2006-01-27 23:05 ` Pavel Machek 2006-01-28 1:05 ` Olivier Galibert 2006-01-28 8:12 ` Pavel Machek 2006-01-27 23:22 ` Pavel Machek 2006-01-28 1:31 ` Matthew Garrett 2006-01-28 8:42 ` Pavel Machek 2006-01-29 7:12 ` Matthew Garrett 2006-02-04 21:11 ` Pavel Machek 2006-01-28 15:58 ` Luca 2006-01-28 16:04 ` Jan De Luyck 2006-01-28 17:11 ` Luca 2006-01-28 16:27 ` Pavel Machek 2006-01-28 16:36 ` Pavel Machek 2006-01-29 14:42 ` Luca
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).