Date: Wed, 13 Jun 2007 10:33:29 -0700 From: Nate Lawson <nate@root.org> To: Anish Mistry <amistry@am-productions.biz> Cc: freebsd-acpi@freebsd.org, Brian Gruber <knightbg@yahoo.com> Subject: Re: no video coming out of S3 Message-ID: <46702A69.9070705@root.org> In-Reply-To: <200706131225.40136.amistry@am-productions.biz> References: <807070.64626.qm@web32411.mail.mud.yahoo.com> <466F98A2.3010800@root.org> <200706131225.40136.amistry@am-productions.biz>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46702A69.9070705>