LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware
User Name
Password
Linux - Hardware This forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?

Notices

Reply
 
Search this Thread
Old 07-25-2009, 07:30 AM   #1
neonsignal
Senior Member
 
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Wheezy (Fluxbox WM)
Posts: 1,364
Blog Entries: 52

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
xset does not turn off backlight


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.
 
Old 07-26-2009, 01:00 AM   #2
Cyberman
Member
 
Registered: Aug 2005
Distribution: Debian Stable
Posts: 190

Rep: Reputation: 17
Quote:
Originally Posted by neonsignal View Post
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.

Last edited by Cyberman; 07-26-2009 at 01:31 AM.
 
Old 07-26-2009, 03:55 AM   #3
neonsignal
Senior Member
 
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Wheezy (Fluxbox WM)
Posts: 1,364
Blog Entries: 52

Original Poster
Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
more detail

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).
 
Old 07-26-2009, 08:30 AM   #4
neonsignal
Senior Member
 
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Wheezy (Fluxbox WM)
Posts: 1,364
Blog Entries: 52

Original Poster
Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
next step

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?

Last edited by neonsignal; 07-26-2009 at 10:18 AM.
 
Old 07-28-2009, 11:33 PM   #5
neonsignal
Senior Member
 
Registered: Jan 2005
Location: Melbourne, Australia
Distribution: Debian Wheezy (Fluxbox WM)
Posts: 1,364
Blog Entries: 52

Original Poster
Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
daemon solution

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


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Force Backlight to turn off? mEo Linux - Laptop and Netbook 2 04-01-2008 02:40 PM
xset dpms force on lowers my backlight redjokerx Linux - Laptop and Netbook 1 11-13-2007 11:55 PM
xset dpms force off does'nt turn off screen anirudh.iitm Linux - General 3 02-24-2007 02:54 PM
Satellite M30-742 Backlight doesn't turn off cyberjun Linux - Laptop and Netbook 1 09-25-2005 11:22 PM
LCD backlight does not turn off on console (acer travelmate 291LMi) zen_guerrilla Linux - Laptop and Netbook 0 07-16-2004 12:49 PM


All times are GMT -5. The time now is 06:18 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration