2008/3/17, Victor Lowther <[EMAIL PROTECTED]>: > On Mon, 2008-03-17 at 03:26 +0100, Michael Biebl wrote: > > 2008/3/17, Michael Biebl <[EMAIL PROTECTED]>: > > > > > > > > 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? _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
