[Tfug] APM mechanisms

[John Karns]

On Dec 30, 2007 1:43 PM, Bexley Hall <bexley401 at yahoo.com> wrote:
> Greetings!

Sorry about the delay in posting this; I was away from a net
connection for the holiday ...

> --- John Karns <johnkarns at gmail.com> wrote:
> > > The box runs NetBSD 3.1 (quite nicely).  *But*,
> > > the damn LCD backlight is *always* on!  :<

Oops, I glossed over that detail.


> > I have an old Dell Inspiron 8100 with an nVidia card
> > that won't
> > respond to the xset command to turn off the
>
> Hmmm... my xset has no such "feature" (unless it
> hides under a different name/description).  While
> I don't run X on that box (I use the display just as
> a text console when things have bit-the-shed).  But,
> if it *did*, I could scan the sources to see *how*
> it is trying to do so...>

My old Dell runs Ubintu 5.x, which of course includes X from Xorg.
That xset supports the syntax:

xset [[+-]dpms] [dpms standby [ suspend [ off]]] [dpms force
standby/suspend/off/on]

which, as I mentioned, didn't work for the nVidia gforce2-go, but was
effective on a nearly identical Inspiron 8000 with an ATI card.


> > backlight.  After some
> > fishing around, I found a work-around for it.  I'll
> > have to take a
> > look at the script I implemented it in to see what
> > the command is.  It might be of use to you.
>
> Excellent!  I can always DL the source of xset
> from whatever distro you are using to see what's
> under the hood...

My work-around uses a package called vbetools.  I'm not sure if it
requires having X installed, but I do know that the command will work
from a virtual text console, so I think the chances are fair that it
would:

vbetool dpms off

For auto LCD shut-off, I modified a perl script I dug up somewhere,
which piggy-backed off of xscreensaver, which I called from
~/.xsession:

usr/bin/xscreensaver -nosplash &
/usr/local/bin/lcdOff.pl &

=================== cut here =======================

#!/usr/bin/perl

# lcdOff.pl

use strict;

#  This handy script watches when the screensaver activates and
#  toggles the lcd backlight.  You won't see more than a
#  second of the screensaver, so you might as well chose one
#  which consumes few mips.

$ENV{'PATH'} = '/bin:/usr/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};

# $<=0;  # become root not just effective root

open(XS,"/usr/bin/xscreensaver-command -watch|") or die;
while(<XS>) {
   if(/^BLANK/i) {
      system("/usr/sbin/vbetool dpms off");
#      system("echo off > /proc/omnibook/lcd");
   } elsif(/^UNBLANK/i) {
      system("/usr/sbin/vbetool dpms on");
#      system("echo on > /proc/omnibook/lcd");
   }
}

# eof

=================== cut here =======================

As you can see, the original I modified peeked at a status flag in
/proc which must have had kernel support for the particular model,
which appears to have been an HP, I believe.


> <grin>  Ever notice how piss-poor the documentation
> on open-source projects is?  :>  (FWIW, PostgreSQL
> really stands out as an exception, here)

Yes, the Postgres docs are rather quite thorough, especially in
comparison to a lot of other FOSS projects.


> > solution.  It gets rather contorted for some
> > machines which date back
> > to that period (ca. 2000 - 2001), due to the fact
> > that some of them
> > (at least the Dells) tried to put a foot in both
> > camps by implementing
> > parts of both ACPI and APM support in the BIOS, but
> > didn't adhere to
> > strictly to the standards of one / both of the
>
> Yes, I think that's the case.  And, I think it was a
> typical MS inspired hack vs. a well thought out
> "feature".

Indeed.  Add to that a notoriously buggy BIOS on some makes (think
Dell here).  I formed the impression that some of the mfr's purposely
deviate from the APM / ACPI standards to dodge competition, or heaven
only knows why.


> > specs.  My take on it
> > at the time was the backlight control was more
> > dependant on the quirks
> > of the video card BIOS than the machine BIOS.
>
> Hmmm... this is an oddball design.  IIRC, the video
> card is *almost* off-the-shelf but modified to
> talk to an LCD instead of external monitor (though
> I think the external monitor connector is still
> present... perhaps wired in parallel, etc.)

Well, I hope the vbetools solution is helpful.

-- 
John Karns