From: Mark S. <ma...@ri...> - 2003-07-25 13:38:20
|
On Fri, Jul 25, 2003 at 07:25:04AM -0600, M. Warner Losh wrote: > In message: <Pin...@pu...> > David G Hamblen <dave@AFRInc.com> writes: > : S3 refrigerates everything and suspends, leaving the display white. > : Resuming turns the backlight off. I can retrieve the backlight with the > : LCD/CRT button. > > I've seen exactly the same problem under FreeBSD which has supported > S3 state for a long time. I've seen the problem going back at least 9 > months. This needs to be handled by the video driver afaik. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM |
From: David G H. <dave@AFRInc.com> - 2003-07-25 13:52:50
|
On Fri, 25 Jul 2003, Mark Santcroos wrote: > On Fri, Jul 25, 2003 at 07:25:04AM -0600, M. Warner Losh wrote: > > In message: <Pin...@pu...> > > David G Hamblen <dave@AFRInc.com> writes: > > : S3 refrigerates everything and suspends, leaving the display white. > > : Resuming turns the backlight off. I can retrieve the backlight with the > > : LCD/CRT button. > > > > I've seen exactly the same problem under FreeBSD which has supported > > S3 state for a long time. I've seen the problem going back at least 9 > > months. > > This needs to be handled by the video driver afaik. I'm using the vesafb driver; I also tried with non-framebuffer VGA console with the same behavior. I'm not running XF86 for these experiments. Should I look into the vesafb code? dave |
From: Mark S. <ma...@ri...> - 2003-07-25 13:57:12
|
On Fri, Jul 25, 2003 at 09:39:34AM -0400, David G Hamblen wrote: > > > : S3 refrigerates everything and suspends, leaving the display white. > > > : Resuming turns the backlight off. I can retrieve the backlight with the > > > : LCD/CRT button. > > > > > > I've seen exactly the same problem under FreeBSD which has supported > > > S3 state for a long time. I've seen the problem going back at least 9 > > > months. > > > > This needs to be handled by the video driver afaik. > > I'm using the vesafb driver; I also tried with non-framebuffer VGA console > with the same behavior. I'm not running XF86 for these experiments. > Should I look into the vesafb code? I don't think there is a generic solution for this. We need specific code for every video driver that needs it. That's my educated guess though. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM |
From: Pavel M. <pa...@su...> - 2003-07-25 15:31:42
|
Hi! > > > : S3 refrigerates everything and suspends, leaving the display white. > > > : Resuming turns the backlight off. I can retrieve the backlight with the > > > : LCD/CRT button. > > > > > > I've seen exactly the same problem under FreeBSD which has supported > > > S3 state for a long time. I've seen the problem going back at least 9 > > > months. > > > > This needs to be handled by the video driver afaik. > > I'm using the vesafb driver; I also tried with non-framebuffer VGA console > with the same behavior. I'm not running XF86 for these experiments. > Should I look into the vesafb code? I believe you need to use specific kernel fb driver, and write suspend/resume code for it :-(. Pavel -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] |
From: Mark S. <ma...@ri...> - 2003-07-25 17:20:32
|
On Fri, Jul 25, 2003 at 05:31:10PM +0200, Pavel Machek wrote: > I believe you need to use specific kernel fb driver, and write > suspend/resume code for it :-(. I did it once for my ATI Radeon 7500, I will look it up and post it here. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM |
From: David G H. <dave@AFRInc.com> - 2003-07-25 18:08:57
|
On Fri, 25 Jul 2003, Mark Santcroos wrote: > On Fri, Jul 25, 2003 at 05:31:10PM +0200, Pavel Machek wrote: > > I believe you need to use specific kernel fb driver, and write > > suspend/resume code for it :-(. > > I did it once for my ATI Radeon 7500, I will look it up and post it here. Stuff like this might help. I haven't looked closely, but grepping thru linux/drivers/video shows a few drivers (including atiradeonfb.c) that have code relating to backlight power. Dave |
From: Pavel M. <pa...@su...> - 2003-07-25 15:30:52
|
Hi! > My problem is the backlight on a Dell Inspiron 8100 with the nVidia VGA > controller. Everything seems to work as expected in all modes detected > (S0, S1, S3, S4bios, S4, S5), except that the backlight stays on after > "echo [1,3] > /proc/acpi/sleep". S1 just refrigerates everything, and > leaves the display on, resume works fine. > > S3 refrigerates everything and suspends, leaving the display white. > Resuming turns the backlight off. I can retrieve the backlight with the > LCD/CRT button. > > Both S4's behave properly (full power off/restore with the power button). > > What part of the code should I look at to attack this problem (ACPI > tables, linux/arch/i386/kernel/acpi/*, or linux/drivers/acpi/*)? DSDT > compiles ok with the iasl assembler/disassembler, and Windows XP goes into > standby properly; so I assume that the ACPI tables can be driven by the > OS. Perhaps something along the lines of the asus_acpi code? Video is hard to do... You should write specific suspend/resume support for your video card. Bad luck if you are using vesafb :-(. > > Wakeup code should *not* be machine-specific, but video card > > save/restore is obviously video-card specific (and you basically can't > > get docs). Write beeping code in 8086 assembly and start debuggin' > > ;-))). -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] |
From: Karol K. <sz...@he...> - 2003-07-25 17:54:17
|
Thus wrote David G Hamblen: > standby properly; so I assume that the ACPI tables can be driven by the > OS. Perhaps something along the lines of the asus_acpi code? The asus_acpi module uses the ASUS-specific DSDT methods to handle the backlight switching. I have quite the same problem with S1 on my machine, but I get around it by doing echo 0 > /proc/acpi/asus/lcd; echo 1 > /proc/acpi/sleep; echo 1 > /proc/acpi/asus/lcd. You may want to look for the relevant methods in your DSDT and write a kernel interface to call them, so that you could then activate it prior to suspending. I suppose that's exactly what the Windows drivers do. You may also try something video-specific, i.e. radeontool. BTW: Pavel: will there be a place in the new PM interface for functions that drivers could bind onto, i.e. something like a generic disable_backlight(), assigned to {asus,dell,toshiba,nvidia,radeon,etc.}_disable_backlight()? I think this could solve some important problems. Best regards, -- Karol 'sziwan' Kozimor sz...@he... |
From: David G H. <dave@AFRInc.com> - 2003-07-25 18:18:44
|
On Fri, 25 Jul 2003, Karol Kozimor wrote: > Thus wrote David G Hamblen: > > standby properly; so I assume that the ACPI tables can be driven by the > > OS. Perhaps something along the lines of the asus_acpi code? > > The asus_acpi module uses the ASUS-specific DSDT methods to handle the > backlight switching. I have quite the same problem with S1 on my machine, > but I get around it by doing echo 0 > /proc/acpi/asus/lcd; echo 1 > > /proc/acpi/sleep; echo 1 > /proc/acpi/asus/lcd. You may want to look for > the relevant methods in your DSDT and write a kernel interface to call > them, so that you could then activate it prior to suspending. I suppose > that's exactly what the Windows drivers do. You may also try something > video-specific, i.e. radeontool. > > BTW: Pavel: will there be a place in the new PM interface for functions > that drivers could bind onto, i.e. something like a generic > disable_backlight(), assigned to > {asus,dell,toshiba,nvidia,radeon,etc.}_disable_backlight()? I think this > could solve some important problems. The /linux/drivers/skeletonfb.c file has some potential sample hooks for this kind of thing. Several of the drivers in that directory have code drive the various power states. When I get a chance, I might try hacking the vesafb driver. I don't know if I can get any hints out of the nv driver for XF86. Dave |
From: Pavel M. <pa...@uc...> - 2003-07-25 22:14:56
|
Hi! > BTW: Pavel: will there be a place in the new PM interface for functions > that drivers could bind onto, i.e. something like a generic > disable_backlight(), assigned to > {asus,dell,toshiba,nvidia,radeon,etc.}_disable_backlight()? I think this > could solve some important problems. I guess you should create sysfs node for your video card, and hook your methods there. If you can't place it in the sysfs hierarchy place it into system devices... BTW ACPI lid refresh code should be also moved to sysfs like that... Pavel -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] |