On Sun, Mar 11, 2007 at 09:20:02AM +0100, Ingo Molnar wrote:
quoted text
> 
> * Pavel Machek <pavel@suse.cz> wrote:
> > Unfortunately, these tend to crash the box when you pass wrong 
> > options, and I do not see easy way to test "can user see whats on 
> > display" automatically.
> 
> you could perhaps try what X's modesetting utility does: display a 
> dialog box that times out if it does not get clicked on, and reboot if 
> it did not get clicked on. Likewise, detect upon the next bootup that a 
> suspend-test was in progress (and didnt get back via normal resume), via 
> some temporary file. That way both the 'did not resume and i had to 
> power-cycle' and the 'resume did not restore my X' problems can be 
> handled.
> 
> Finally, when the correct options have been established (worse-case with 
> a small number of reboots and "yes, indeed the resume did not work fine" 
> clicks done upon bootup by the user), automatically fill in a webform in 
> firefox and ask the user to do a single click to submit that form.

There is ongoing work to make something like this happen, but it will
take some time (very probably the whitelist will end up in a HAL fdi-file
which gives the additional advantage that interested vendors can supply a
linux-"driver" for their notebooks which makes suspend "just work" (the
"driver" simply being a .fdi-file that lists the workaround for this
particular machine)

quoted text
> techniques like that have more chance i think to get Linux 
> suspend/resume anywhere near to working. The current 'rely on the 
> developer' technique apparently does not work.

It is not too bad actually, i seem to be getting lots of whitelist
entries from people that are first time shell users, and i usually
walk them through the process in just one or two mails. But yes, it
does not scale well ;-)

I was already thinking about some more sophisticated "wildcard" matching,
something like "if it is a HP and it has an ATI gfx chip, and we do
not have an exact match, then do VBE_POST|VBE_MODE" or similar, which
would probably get many machines working fine (it turns out that almost
all new machines from a vendor with similar hardware need similar
workarounds, but for example the hp's with ATI need different quirks
than the hp's with intel. Only thinkpads seem to almost universally work
with s3_bios,s3_mode, with some x86_64 models being the exception).
Something like that should be pretty easy once the whitelist is kept
in HAL.
-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out." 
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/