Improving the suspend quirks guessworking

[Victor Lowther]

On Tue, 2008-03-25 at 01:16 +0100, Danny Kukawka wrote:
> On Samstag, 22. März 2008, Martin Pitt wrote:
> > > This combination looks strange to me, but maybe Stefan can comment, he
> > > works on suspend since ages.
> >
> > I'm more or less just the messenger. According to Matthew (CC'ed
> > again, please keep him in CC) those are necessary to work around
> > kernel bugs which affect drivers other than fglrx, nvidia, and never
> > intel.
> 
> If you take a look at already existing quirks, I wouldn't say this is a common 
> combination to fix things generally or often.

It is getting to be more and more common.  Intel, AMD, and nVidia have
won the graphics wars for now.  Intel now has a sane in-kernel driver
that does not require quirks, the newly-opened specs for the ATI gpus
should really help the ATI drivers improve, and the latest nVidia binary
drivers are really quite good at this whole power management thing.

I know it seems to be popular to slag the binary video drivers, but for
some of us they are the only reasonable option.  

> > > > (1) laptop model has no matching FDI rule -> use the default quirks
> > > >     in the attached patch
> > >
> > > IMO not a good idea. I would still prefer that the people which have
> > > problems with suspending go the current workflow: test the needed quirks,
> > > report them back, we add them to hal-info.
> >
> > Me too, but I understand it as being a much better default than "no
> > quirks at all" if there is no FDI data for a particular model.
> 
> The 'no quirks at all' force the people to report the needed quirks back to us 
> to add them to hal-info. Without this policy we never get them reported and 
> if these affected machines don't need these strange default keys anymore the 
> suspend get broken again.

In that case, make it as easy as possible.  Have a hook that runs after
the first suspend/resume cycle that offers the uer a chance to "tell the
developers suspend worked on this machine", and then push pertinent
configuration information (including hardware, all drivers, and qny
quirks that were used) to a database somewhere we can use to refine the
quirks database.

> > > What you propose would cause also many trouble e.g. on machines
> > > which are not listed and don't need any quirks (only as one
> > > example).
> >
> > I understand that, but I can only parrot Matthew here: "no quirks" is
> > allegedly guaranteed to fail on those machines, whereas the above set
> > of quirks at least gives a good chance of succeeding.
> 
> See above.
> 
> > > 2) until these modules don't export (device) information (not that
> > > may a module with this name was loaded) to the sysfs we can't detect
> > > that in HAL.
> >
> > Oh the joy of proprietary X.org device drivers. But since the best we
> > can do is to prod AMD/NVidia to fix it, 
> 
> Not sure if this is possible at all, because of GPL violations.

Not exporting to sysfs?  Who cares.  The nvidia drivers (at least)
have /proc/driver/nvidia, and the fglrx drivers probably have a similar
mechanism.  Not utilizing that info is just foolish.

> Danny
> 
> _______________________________________________
> hal mailing list
> hal at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/hal
-- 
Victor Lowther
Ubuntu Certified Professional