[Tfug] APM mechanisms

[Predrag Punosevac]

On Wed, 02 Jan 2008 17:25:50 -0700, John Karns <johnkarns at gmail.com> wrote:

> 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:
>


NetBSD is using XFree86 not Xorg!!! Even the most recent 4.0 release  
(released 10 days ago)
uses XFree86. One of the reasons for that decision is rapid lack of  
support for older hardware
by Xorg. Even the change from 6.9 to 7.2 (FreeBSD is already on Xorg 7.3)  
has made configuration of
X on some older hardware a pain.

Best,
Predrag








> 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.
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/