| 2006-04-27 11:03:30 |
Tormod Volden |
description |
On my Presario 700, the consoles stay black after resume. I commented out the actual sleep trigger in sleep.sh to see if there was a hardware sleep issue, but no, the problem still appeared. In particular, the order and ways the vgastate is saved and restored, and in which mode, seems a little strange to me. I have tried to find documentation, but found nothing than the scripts themselves.
Looking at init.d/vbesave, prepare.sh and resume.sh I see:
If SAVE_VBE_STATE is set (in /etc/default/acpi-support)
1) save the vbestate at boot (before starting X)
2) save the vbestate before sleeping (which makes (1) pointless) unless vbemode=3
When it comes to the vbemode, I don't understand fully. Comments in prepare.sh explains that VESA modes are vbemode not equal "3".
So in case of vbemode !=3 (VESA)
set mode to 3
save state
(sleep and wake up)
set mode to original mode*
restore state
In case of vbemode =3
(do not save)
(sleep and wake up)
restore state from boot
*For me it sounds more natural to save and restore the state in the same mode, and then switch back to the original state. But I don't know these things.
For my laptop, the state at booting is 16334 (IIRC). When I comment out the "save state" above, it works correctly, resume restores the state saved at boot, and the consoles are fine. So the problem seems to be that the "3" state is saved and restored in a non-"3" state.
Please tell if I can provide more information, but be patient, since the laptop is not on internet... |
On my Presario 700, the consoles stay black after resume. I commented out the actual sleep trigger in sleep.sh to see if there was a hardware sleep issue, but no, the problem still appeared. In particular, the order and ways the vgastate is saved and restored, and in which mode, seems a little strange to me. I have tried to find documentation, but found nothing than the scripts themselves.
Looking at init.d/vbesave, prepare.sh and resume.sh I see:
If SAVE_VBE_STATE is set (in /etc/default/acpi-support)
1) save the vbestate at boot (before starting X)
2) save the vbestate before sleeping (which makes (1) pointless) unless vbemode=3
When it comes to the vbemode, I don't understand fully. Comments in prepare.sh explains that VESA modes are vbemode not equal "3".
So in case of vbemode !=3 (VESA)
set mode to 3
save state
(sleep and wake up)
set mode to original mode*
restore state
In case of vbemode =3
(do not save)
(sleep and wake up)
restore state from boot
*For me it sounds more natural to save and restore the state in the same mode, and then switch back to the original mode. But I don't know these things.
For my laptop, the state at booting is 16334 (IIRC). When I comment out the "save state" above, it works correctly, resume restores the state saved at boot, and the consoles are fine. So the problem seems to be that the state is saved in the "3" mode and restored in a non-"3" mode.
Please tell if I can provide more information, but be patient, since the laptop is not on internet... |
|
| 2006-10-15 00:14:13 |
Tormod Volden |
acpi-support: statusexplanation |
|
I have to reopen this bug. If laptop-detect (inside /etc/init/vbesave) fails to detect a laptop (for instance because of bug #40503), the vbestate is not saved.
In resume.d/17-video-restore.sh the vbestate is unconditionally restored. I guess the command will just fail if the $VBESTATE file does not exist. Anyway, it would be better to check if the file exist before carrying on.
suspend.d/80-video-vesa-state.sh also takes for granted that the file was saved at boot.
I guess this kicks in only in the case where SAVE_VBE_STATE has been set to true _and_ laptop-detect fails. Maybe SAVE_VBE_STATE should be disabled somehow if laptop-detect fails.
Since laptop-detect is broken on my laptop, I put "LAPTOP=true" in /etc/default/acpi-support, and this seems to have fixed the display corruption I had at resume from hibernation. |
|
| 2006-10-17 22:12:21 |
Tormod Volden |
acpi-support: statusexplanation |
I have to reopen this bug. If laptop-detect (inside /etc/init/vbesave) fails to detect a laptop (for instance because of bug #40503), the vbestate is not saved.
In resume.d/17-video-restore.sh the vbestate is unconditionally restored. I guess the command will just fail if the $VBESTATE file does not exist. Anyway, it would be better to check if the file exist before carrying on.
suspend.d/80-video-vesa-state.sh also takes for granted that the file was saved at boot.
I guess this kicks in only in the case where SAVE_VBE_STATE has been set to true _and_ laptop-detect fails. Maybe SAVE_VBE_STATE should be disabled somehow if laptop-detect fails.
Since laptop-detect is broken on my laptop, I put "LAPTOP=true" in /etc/default/acpi-support, and this seems to have fixed the display corruption I had at resume from hibernation. |
Although I feel that my comments above about SAVE_VBE_STATE should be addressed at some point, I close the bug again for this time since this update fixed my consoles:
acpi-support (0.90) edgy; urgency=low
* Explicitly switch the screen back to text mode if it was that way
before resume
-- Matthew Garrett <mjg59@srcf.ucam.org> Sun, 15 Oct 2006 18:09:03 +0100
|
|
