[Suspend-devel] Patch: remove incorrect vbestate_restore quirk for some laptops

[Stefan Seyfried]

On Thu, May 03, 2007 at 06:36:24PM -0400, David Zeuthen wrote:
> On Thu, 2007-05-03 at 23:24 +0200, Danny Kukawka wrote:
> > On Donnerstag, 3. Mai 2007, Richard Hughes wrote:
> > > On Thu, 2007-05-03 at 13:40 -0400, David Zeuthen wrote:
> > > > Ugh.. Hope I didn't start a flamewar here... I'm just trying to
> > > > clarify
> > > > that mixing fb and X drivers is problematic. Let's go continue
> > > > collecting quirks and make hal-info make more laptops work.
> > >
> > > Attached is a patch that removes all the UNSURE (i.e. not tested in
> > > s2ram) entries from hal-info. The last thing we want to do is break
> > > setups that already work, so I think this is the safest way to go
> > > forward.
> > 
> > No, this is not the way s2ram handle the unsure entries. s2ram print only a 
> > warning as I understand the code:
> > 
> > if (flags & UNSURE)
> >         printf("Machine is in the whitelist but perhaps using "
> >                "vbetool unnecessarily.\n"
> > 
> > Only because they are marked as unsure does not mean that they don't work 
> > correct. They are already since a while and there are user which use s2ram on 
> > such machines and it work. Maybe the problem is that we should find a way to 
> > force the user to report that they work to be able to remove the unsure tag. 
> > I would let the quirks in and wait for reports that it don't work instead of 
> > upset them with no longer working setups.
> 
> But we _cannot_ let these quirks in as they obviously break stuff [1]. I
> thought I'd explained that earlier...
> 
>      David
> 
> [1] :
> 
> First reported here by Zack:
> 
>  http://lists.freedesktop.org/archives/hal/2007-April/008158.html
> 
> E.g. s2ram says
> 
>  VBE_POST|VBE_SAVE|UNSURE

UNSURE just means "Was imported from the ubuntu acpi-support package about two
years ago".
For IBM/Lenovo systems i'd default to S3_BIOS|S3_MODE, and only if a system
is reported to not work with that, i'd try to figure out what is actually
needed (some of the R50 series seemed to need different options).

> and obviously this doesn't work for Zack (he needs S3_BIOS). The other
> example is this
> 
>  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238792
> 
> for the T43. Actually the quirks from s2ram makes suspend/resume _not
> work_ at all. OTOH, it works just fine without any quirks whatsoever.

I did not get many reports for the Thinkpad UNSURE entries (when i got one,
i removed it from the UNSURE list), so they either work for some people, or
nobody has tested them. Throwing them out completely is probably a good idea.
-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."