Bug 56024
| Summary: | ACPI suspend drains battery while in S3 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | amistry |
| Component: | kern | Assignee: | freebsd-acpi (Nobody) <acpi> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 5.1-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
amistry
2003-08-27 06:20:09 UTC
Responsible Changed From-To: freebsd-bugs->njl I will look at this after some other PRs. I think that I have figured out why this mysterious drain is occuring. When I suspended today I noticed that the backlight turns of any everything sounds like it powers down, but if I look really close and have the right light angle, or have a lot of white text on the screen I can see that the display is STILL on. At first I thought that this what burn in, but it would change when I would have different stuff on the console, and wouldn't appear when the system was completely powered down. So it seems like ACPI is only turning off the backlight on the display, and not the display itself. Hope this points someone in the right direction to a solution. -- Anish Mistry =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did some more observing and noticed in Windows that it shuts off the disp= lay=20 before going into suspend (ie. before the acpi beep). This leads me to=20 believe that the ACPI suspend isn't responsible for shutting down the=20 display, but probably the driver, or just a generic VESA display shutoff=20 command if there exists one. So a fix might be to shutoff the display righ= t=20 before the ACPI actually calls the prep and suspend. =2D --=20 Anish Mistry =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/n1QJxqA5ziudZT0RAukuAJ97NJyOZsdBnQkZ0mRrIahkMNKaDgCgowYr 42yr6Aqvn0rlZLdzwNQ1CFI=3D =3Dj9BB =2D----END PGP SIGNATURE----- On Tue, 28 Oct 2003, Anish Mistry wrote:
> I did some more observing and noticed in Windows that it shuts off the
> display
> before going into suspend (ie. before the acpi beep). This leads me to
> believe that the ACPI suspend isn't responsible for shutting down the
> display, but probably the driver, or just a generic VESA display shutoff
> command if there exists one.
On most machines, the _PTS (prepare to sleep) node does the video shut
off. On my IBM T23, this is what happens. _PTS is called by
AcpiSleepStatePrep. I'll have to look at your ASL to see what it has for
_PTS for the video adapter.
Windows info doesn't help much since MS expects video driver authors to
handle the suspend operation as part of WDM. Since most don't release
specs on video drivers, we leave it up to X's drivers currently. But they
are incomplete.
-Nate
Responsible Changed From-To: njl->freebsd-acpi Passing this to the acpi mailing list for historical purposes. At some point, someone will have time to investigate suspend/resume. Responsible Changed From-To: njl->freebsd-acpi Passing this to the acpi mailing list for historical purposes. At some point, someone will have time to investigate suspend/resume. This problem will likely be solved by getting proper DPMS support in the kernel video driver and/or hooking X suspend/resume to /dev/apm when acpi is enabled. Is this still an issue? -- Andriy Gapon State Changed From-To: open->closed Closing 10 yrs old bug. |
