Date: Thu, 29 Jan 2004 18:31:14 +0000 From: James Green <jim@thebadger.org> To: freebsd-current@freebsd.org Subject: Re: API to turn off the display Message-ID: <1075401074.2660.106.camel@mobius.int.thebadger.org>
next in thread | raw e-mail | index | archive | help
On Thu, 2004-01-29 at 16:32, John Baldwin wrote: > On Thursday 29 January 2004 11:20 am, Mark Santcroos wrote: > > On Thu, Jan 29, 2004 at 01:21:28AM +0000, James Green wrote: > > > > > I find DPMS works for me.. > > > > > > > > > > xset dpms force off > > > > > > > > > > My Monitor section in the X config has.. > > > > > Option "DPMS" > > > > > > > > > > My video chipset is an ATI Rage 128 Mobility in a Dell Inspiron 8000. > > > > > > > > I use the above, one minor thing though, the backlight on the laptop > > > > stays on (NEC Versa S900 with ATI radeon 9000 mobility) yet under > > > > windows the backlight turns off, still haven't got it worked out :/ > > > > > > There is a fix for DPMS for the Radeon 9000. The bug report/patch etc. > > > is here: http://bugs.xfree86.org/show_bug.cgi?id=26 > > > See comment #10 for details. > > > > ports/x11-servers/XFree86-4-Server-snap/ has the fix too, I just tried > > it and it works for my Latitude C640. > > > > Which leads me to think... can we do this with ACPI only or do we need > > to do what DPMS is doing?? I think it is the latter. > > I read the spec yesterday, and what is supposed to happen is this: The > display (LCD, CRT, etc.) is supposed to be powered down using DPMS. The > actual adapter is then supposed to be powered down using either PCI or ACPI > sleep states, and the adapter should not be powered down to a lower sleep > state (like D3) w/o using DPMS to power the display down to at least that > state first. This means that the kernel might need to grow a dummy vga > driver of some sort and some simple dpms support for suspend/resume. I have had a bit more of a play with the acpi_vid module that Taku YAMAMOTO posted a link for earlier in this thread. I was seeing a hairy mess when turning the display back on with # sysctl hw.acpi.video.lcd0.active=1 when running X. (although not a problem on the console) The above gave me an idea, which I tested over ssh: Turn off the LCD with: # xset -display :0 dpms force off && sysctl hw.acpi.video.lcd0.active=0 (you can see the difference between DPMS off and adaptor off on the screen) and then turn it back on with # xset -display :0 dpms force on and it all works beautifully! Interestingly, however, is that: # sysctl hw.acpi.video.lcd0.active=0 && acpiconf -s 1 will turn off the LCD and suspend gracefully, whereas # xset -display :0 dpms force off && sysctl hw.acpi.video.lcd0.active=0 && acpiconf -s 1 just locks everything up... (discovered by adding the commands to /etc/rc.suspend and getting a lock up) James
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1075401074.2660.106.camel>