xset does not turn off backlight

neonsignal · 07-25-2009, 06:30 AM

Debian Lenny on a Toshiba Portege 3500
00:08.0 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade XPAi1 (rev 82)
kernel version 2.6.26-2-686

On my system, "xset dpms force off" blanks the screen, but does not turn off the backlight. This means that the automated screen off in X does not actually save any power when it blanks the screen.

I can turn off the backlight manually using the BIOS tool "vbetool dpms off" (but then I have to turn it back on again manually too).

Question 1: is this a problem with the graphics driver interface, or with X, or with the power management driver interface?

Question 2: as a workaround, is there any way for me to hook into the dpms off/on that X is doing, and run a script to call vbetool?

The best workaround hack I have come across so far is to have a screensaver that calls vbetool, but I was hoping to find something that doesn't require me to run a daemon all the time.

Cyberman · 07-26-2009, 12:00 AM

Quote:

Originally Posted by neonsignal

Debian Lenny on a Toshiba Portege 3500
00:08.0 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade XPAi1 (rev 82)
kernel version 2.6.26-2-686

On my system, "xset dpms force off" blanks the screen, but does not turn off the backlight. This means that the automated screen off in X does not actually save any power when it blanks the screen.

I can turn off the backlight manually using the BIOS tool "vbetool dpms off" (but then I have to turn it back on again manually too).

Question 1: is this a problem with the graphics driver interface, or with X, or with the power management driver interface?

Question 2: as a workaround, is there any way for me to hook into the dpms off/on that X is doing, and run a script to call vbetool?

The best workaround hack I have come across so far is to have a screensaver that calls vbetool, but I was hoping to find something that doesn't require me to run a daemon all the time.

Question 1 reply:
Probably an issue with the program communicating with the driver. Try playing with setpci to alter light configuration. It mostly dims things. However, you might want to rely on the BIOS control to turn on/off the backlight. You could blame X for never having everything that works correctly working together.

Question 2 reply:
Combine mathematics, shell scripting, and various command-line programs to control your backlight. You'll want to track down the files that relate to the screensaver system you're using. You'll probably alter them to trigger some kind of script. Tie in a script that turns the backlight on after moving the mouse or keyboard.

I don't know the power management files for Debian Lenny. I think those relate to the gnome screensaver. I could be wrong. I guess you'll have to find the power management files and hack them. You'll eventually end up hacking something related to power management or a screen saver. That's the way I see it.

If the screensaver is timed, then you already have an open-lid scenario figured out. If open-lid input light changing is the issue, just hotkey stuff. If closed-lid is the issue, then dig around /proc/acpi and see if you can find something related to your lid. Maybe create a daemon that constantly greps to see if the lid is open/closed; if closed, then execute BIOS command. With such daemon, the requirement for X input to re-activate screen backlight would be reduced.

neonsignal · 07-26-2009, 02:55 AM

Thanks for taking the time to respond.

The reason I don't necessary think that it is the 'fault' of X, is that using the bios (as vbetool does) to change the setting is not ideal; I would expect drivers to access the hardware directly without being mediated by bioses of variable quality.

However, clearly there is some problem with the way the Toshiba hardware is being accessed. Not an issue of blame, so much as figuring out where the powersaving/backlight stuff is supposed to happen, so I can at least look at where I might patch (driver? X?).

Thanks for the setpci idea, at least it gives me a tool for figuring out the hardware.

As regards the screensaver; currently I don't run one, as I have a fairly cut-down install. I am just relying on the dpms control that X already has built in (but it isn't turning off the backlight). If I run a screensaver, I am able to fix the problem by scripting in a call to vbetool. I was hoping that X dpms control might have something I can hook into, but that might not be the case.

I have no problem with the /proc/acpi scripts on this system (suspend/resume works fine).

neonsignal · 07-26-2009, 07:30 AM

Hmm, reading Jonathan Buzzard's documentation, it would seem that access to the backlight control is through a Toshiba specific hardware control interface (HCI).

Since his toshset utility also allows me to turn the backlight on and off, it would seem that the Portege 3500 uses the same HCI registers to control the backlight.

So now I know how to turn the backlight on and off without using the bios, and just have to figure out where this is supposed to happen inside Linux.

There is some code for the backlight in the toshiba_acpi driver, but this is to control brightness rather than actually switching it on and off (and brightness=0 is still on, though dim). And I am guessing that this driver just provides the non-standard /proc/acpi/toshiba interface, which X would have no knowledge of.

Let me suppose that the dpms is done by X calling one of the xorg drivers (in my case the trident), then I start to understand the problem. The xorg driver is tied to the graphics chip; this is fine for an external monitor, where monitor dpms is controlled by video signals. But for a laptop, the backlight is controlled by non-video hardware. So the graphics driver would have to know both that it is on a laptop, and which laptop type it is, in order to control the backlight for the built in LCD display. This is difficult. Perhaps this could be handled by some new (laptop specific) Options in the Monitor section of xorg.conf?

Any comments?

neonsignal · 07-28-2009, 10:33 PM

Well, it looks too prickly to get X to access laptop specific hardware, so I've gone with a daemon that keeps track of the dpms status for now. This is my toshdpms daemon:

Code:

// Toshiba dpms backlight control
// include files
	#include <unistd.h>
	#include <sys/io.h>
	#include <X11/Intrinsic.h>
	#include <X11/extensions/dpms.h>
int main (int argc, char **argv)
{
// allow access to Toshiba port then drop privileges
	if (::ioperm(0xB2, 1, 1) || ::setuid(::getuid()))
		return 1;
// get display pointer
	XtAppContext context;
	Widget shell = ::XtAppInitialize(&context, 0, 0, 0, &argc, argv, 0, 0, 0);
	Display *pDisplay = ::XtDisplay(shell);
// check for DPMS extension and support
	int event, error;
	if (!DPMSQueryExtension(pDisplay, &event, &error) || !::DPMSCapable(pDisplay))
		return 1;
// watch DPMS state
	CARD16 state, state0 = 0;
	while (true)
	{
	// if state has changed
		BOOL onoff;
		if (::DPMSInfo(pDisplay, &state, &onoff) && state != state0)
		{
		// reset/set Toshiba backlight
			if (state > 0)
				__asm__("movw $0,%cx");
			else
				__asm__("movw $1,%cx");
			__asm__("movw $0xFF00,%ax");
			__asm__("movw $2,%bx");
			__asm__ volatile("inb $0xB2,%al");
			state0 = state;
		}
		::usleep(500000);
	}
}

Compilation (which requires X libraries libx11-dev, libxext-dev, libxt-dev, libxmu-dev) is as follows:

Code:

g++ -o toshdpms toshdpms.cpp -lXmu
sudo chown root:root toshdpms
sudo chmod u+s toshdpms
sudo mv toshdpms /usr/local/bin

It is designed for a single user system, and invoked from the user account (in my case, from .xinitrc).

The way it works is:
1. give itself access to the Toshiba hardware control interface, and then demote privilege level back to the user
2. get the display pointer
3. every half a second, check the dpms state
4. when dpms state has changed, set the backlight to match

It is working, but there are lots of possible improvements (feel free to make comments):
* verifying that the hardware really is a Toshiba laptop with this interface
* checking that the correct display has been selected
* allowing for multiple users
* testing on systems other than the Portege 3500
* shutting down gracefully
* possibly interrupts need to be disabled around the hardware access
* less magic numbers :-)