no video coming out of S3

[Nate Lawson]

Anish Mistry wrote:
> On Wednesday 13 June 2007, Nate Lawson wrote:
>> Brian Gruber wrote:
>>> I'm having trouble bringing my computer out of S3
>>> suspend, and am hoping someone may be able to help me.
>>>
>>> The computer itself successfully comes out of suspend
>>> when I press the power button, but the video does not
>>> come back. Reading about this i discovered
>>> hw.acpi.reset_video, which sounded like exactly what I
>>> needed; alas, it did nothing.
>>>
>>> Reading further mailing lists, I found mention that
>>> X's DRI could screw this up. So I set up my computer
>>> not to launch X on boot, and rebooted it (since emails
>>> seemed to say that once DRI was loaded, there was no
>>> undoing its affects without a reboot). Still, the
>>> video did not come back.
>>>
>>> i'm not sure what to do now, or even what details are
>>> helpful. I will tell you that I'm using an ATI Radeon
>>> QY RV100 7000/VE, and the computer is an IBM NetVista
>>> 8307-82U. uname -a:
>>> FreeBSD calvin 6.2-RELEASE-p4 FreeBSD 6.2-RELEASE-p4
>>> #0: Fri Apr 27 16:11:48 EDT 2007
>>> root at calvin:/usr/obj/usr/src/sys/CALVIN  i386
>>>
>>> Also, I've noted that under windows on this same
>>> computer (i have it setup to dual-boot), where S3
>>> works fine, I can bring it out of suspend with both
>>> the keyboard and mouse (both PS/2) as well as the
>>> power button. Probably just an implementation
>>> difference, but perhaps important in a way I don't
>>> understand.
>> Try using the radeontool port.  I think you might find some info in
>> the acpi@ archives.
>>
>> I think one solution we should try is to do the various BIOS video
>> reset routines after powering up everything again (D3->D0).  At the
>> moment, the code runs kind of early since it runs in real mode. 
>> We'd have to do it in VM86 mode after the video hw was powered back
>> up.
>>
>> I thought jhb@ once had a DPMS patch that did something like this
>> but I dunno.
>
> Google for acpi_video_dpms

That's what I was thinking of.  This is similar but not quite the same
as what I think we should do with the lcall 0xc0000 code.

-- 
Nate