* Pavel Machek <pavel@xxxxxxx> wrote: > > Even if one doesn't use the fb console at all, radeonfb apparently > > is still required on some ThinkPad models to work around BIOS bugs: > > > > http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off > > > s2ram should be able to work around this, it has parts from > radeontool. (suspend.sf.net). i'm wondering, do you have any idea how Windows handles the suspend/resume quirks problem area? Do they "curse BIOS vendors and maintain a large DB of DMI-driven exceptions", or do they perhaps have some fundamentally better approach than us? If it's the former, then we might as well try to bring more automatism (and more of your database) into the kernel itself. btw., the s2ram database seems quite a bit spotty: $ ./s2ram -n Machine is unknown. This machine can be identified by: sys_vendor = "System manufacturer" sys_product = "System Product Name" sys_version = "System Version" bios_version = "ASUS A8N-E ACPI BIOS Revision 1008" $ ./s2ram -n Machine is unknown. This machine can be identified by: sys_vendor = "Hewlett-Packard " sys_product = "compaq nx9030 (PG630ET#ABD) " sys_version = "Rev 1 " bios_version = "F.15 " See http://en.opensuse.org/S2ram for details. even at the link above i didnt find any clear algorithm about how to extend the quirks-list and the white-list - while i expect that most people experience what i did: that s2ram doesnt know their boxes. (otherwise they would not visit that URL at all i suspect) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
