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

[Michael Biebl]

2008/3/17, Victor Lowther <victor.lowther at gmail.com>:
> 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

Honestly, I don't really care for proprietary drivers, but I
understand your needs.

>  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.


>  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.


Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?