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

[Victor Lowther]

On Mon, 2008-03-17 at 04:26 +0100, Michael Biebl wrote:
> 2008/3/17, Victor Lowther <victor.lowther at gmail.com>:
> >  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
> 
> Honestly, I don't really care for proprietary drivers, but I
> understand your needs.

As long as there is an understanding that they are not just my needs. I
am not the only person who must run using proprietary drivers on my
hardware, and that we cannot ignore them.

> >  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.
> >
> 
> Richard can probably give you more insight on this.
> 
> >  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.
> 
> Imho it's much worse to provide several different ways to do the same thing.
> 
> I don't think it's that hard to cp the fdi file from
> /usr/share/hal/fdi into /etc/hal/fdi and simply change the quirks for
> your model.
> Especially as this is very well documented.

I think you vastly overestimate the willingness or ability of a
nontechnical user to make the quirk changes you are describing. 

Either that, or too may years to doing technical support have made me
very, very cynical in this department. 

I have no problem picking one method of overriding HAL parameters and
coding to it exclusivly.

But that capability must be there, if only for troubleshooting purposes.

> >  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'
> 
> As I explained in my earlier mail, this only allows to clear the
> quirks, not override them. In case you need --quirk-s3-bios, it's not
> possible.
> With a hal fdi file in /etc/ you can easily achieve this.

I am well aware of what my QUIRK_NONE patches do and do not do.  They
meet my needs.  Any help generalizing them would ne much appreciated.

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