Skip site navigation (1)Skip section navigation (2)
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>