On Monday 28 August 2006 04:18, Stefan Seyfried wrote: > Hi, > > On Wed, Aug 16, 2006 at 04:27:12PM -0500, Pat Double wrote: > > I have just started using powersave and kpowersave and really like the > > unified functionality. Much better than the collection of scripts in > > acpid etc, thanks for the work. > > > > One problem I am having is that when I close the lid the backlight will > > turn off for a minute or two and then back on. The screen is still blank, > > but the backlight is on. Also if I move the mouse or type a key the > > screen comes > > This is probably a problem in the X server, which i discovered two weeks > ago: basically, the X server turns on the backlight on every ACPI event. > Stupid, i know :-). There is a novell bugzilla report about this, it is > https://bugzilla.novell.com/show_bug.cgi?id=197858 > My workaround for this is to use > Option "NoPM" "yes" > in Section "ServerFlags" of xorg.conf.
Thanks, that seems to work. > > back, even with the lid closed. I guess this is because DPMS is used to > > turn off the backlight, and it will turn it back on when activity is > > detected. > > This is a second problem: basically, the X server does not know that the > lid is closed (and AFAIK there is not really a possibility to tell it about > this state) and it should leave the backlight alone. Fortunately, most > notebooks do handle the backlight in "hardware", means: the BIOS or even a > simple switch keeps the light off as long as the lid is closed, but some > don't - i have seen this a lot on Dell D600 for example. My Dell Inspiron XPS doesn't control this by hardware. :( > > Is there a solution to this? Before I did not use DPMS and had an acpid > > script that used radeontool to control the backlight. This worked good. > > You can still do some custom scripts for custom events, see > powersave_manual.html#Events and > powersave_manual.html#Scripts > in the documentation. > > Note that manipulating the graphics card behind X's back with radeontool is > "playing with fire", so i am hesitant to add such hacks to the powersave > code. > Note also that if you are using radeontool, you should _really_ consider my > fixes to it, available from ftp://ftp.suse.com/pub/people/seife/radeontool/ > I submitted them back to the author but have not heard from him since then. I'll take a look at your radeontool patches. I've been playing with another solution, but I'm not sure it'll work correctly. I'm using a script to use "aticonfig" to modify the enabled monitors to remove "lvds" (the LCD) from the enabled monitors list when the lid is closed and add it back when the lid is opened. (It also modifies the power state for the GPU, which seems to work nicely.) The only problem: it won't accept "none" for enabled monitors. Works pretty good when I have a CRT connected. Unfortunately this is not safe to have when I am on a VT that the X session is not, it corrupts the screen and locks the machine. Not sure what to do about this. I thought about detecting which VT is active and chose to use aticonfig for X sessions and radeontool for console sessions, but that won't work because if you switch VT after changing the lid state, that VT won't have the updated state. I'm not sure this is solvable without changes to X. Is there a VT switch event available? If I get a working ATI script, would you consider adding it to powersave? I would need to add some more checks to ensure the ATI fglrx driver is actually in use. -- Pat Double, [EMAIL PROTECTED] "In the beginning God created the heaven and the earth."
pgpYWr4lCHZWm.pgp
Description: PGP signature
_______________________________________________ powersave-users mailing list powersave-users@forge.novell.com http://forge.novell.com/mailman/listinfo/powersave-users
