Patch: remove incorrect vbestate_restore quirk for some laptops

[David Zeuthen]

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

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.