[Pm-utils] [PATCH] parse video quirks in uswsusp sleep module

[Victor Lowther]

On Mon, 2008-03-17 at 03:26 +0100, Michael Biebl wrote:
> 2008/3/17, Michael Biebl <mbiebl at gmail.com>:
> 
> >
> >  I actually think, that the QUIRK_NONE tests in 99video could/should
> >  also be removed.
> >
> >  As said, combinations like --quirk-none --quirk-vbe-mode are simply invalid.
> 
> Or put in other words: The correct behaviour would be to abort the
> suspend if such
> invalid quirk combinations are given (and not to clear other quirks if
> --quirk-none is present).
> There currently isn't support in pm-utils to abort a suspend from
> within a hook or a module (and rollback correctly), though. So, the
> safest thing for now, is to simply ignore QUIRK_NONE, imho.

I understand your position, but I have to disagree.  Here is a scenario:

My primary laptop is a Dell Latitude D820.  When Dell was selling them,
they could be purchased with 2 types of video cards:

Intel 945 GMA
nVidia GeForce 7400 Go

That gives us a few different drivers options:

Intel video driver
nv open-source video driver
nvidia binary driver

The whitelist from s2ram specifies that the D820 requires the vbe_post
quirk and the vbe_mode quirk. The HAL quirks list specifies just the
vbe_mode hack.

I run the nvidia binary drivers, and if I allow either of those quirks
to happen the system will hardlock.

On those rare occasions when I have used the nv open-source drivers it
has not survived a suspend/resume either.  I have no particular desire
to further troubleshoot this particular scenario -- the nv drivers are
unsuitable for my system (they cannot driver my flatpanel at 1920x1200
without video corruption).

I don't have access to a D820 with the Intel graphics drivers, but I
suspect the quirks in the s2ram whitelist are written to cover that
particular hardware combination.

This would not be such a big deal if it was easy to tell s2ram or the
HAL quirks list what to do on X system with Y video hardware and Z video
driver -- I would patch my local copy of the HAL quirks list and submit
a new quirks entry covering that combination.  Problem is, the HAL
quirks list only appear to look at system mfgr/make/model -- I have not
been able to find an exmaple of anything more complicated, and the docs
on the fd.o HAL quirks list are lacking on how to write a new quirk that
can express all the conditions I need to express.

Asking an end-user to write their own quirk entry
in /usr/share/hal/fdi/information would be a great way to drive people
away from Linux.

The easiest thing for me to do as a service to the end users is to make
it easy for them to override HAL when it is getting it wrong.  The
current quirk_none is not the best way of doing that, but it is loads
easier to say either of
	now, type 'echo video >>/etc/pm/blacklist'
	now, type 'echo --quirk-none >>/etc/pm/parameters'
then it is to have them edit the HAL quirks list or file a bug with
their distro, work thru what is needed, and then wait for an updated
uswsusp or hal package.

I don't think ignoring quirk_none in either location where we parse
video quirk parameters is a good thing.  

> Cheers,
> Michael
> 
> 
-- 
Victor Lowther
Ubuntu Certified Professional