On Mon, 2007-04-16 at 03:55 -0400, Dave Jones wrote: > On Mon, Apr 16, 2007 at 03:32:02PM +0800, Antonino A. Daplas wrote: > > On Mon, 2007-04-16 at 03:23 -0400, Dave Jones wrote: > > > On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote: > > > > > > > CONFIG_ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE, which, in turn is > > > > enabled by FB_BACKLIGHT. So we can narrow it down further, can you > try? > > > > > > > > CONFIG_FB_BACKLIGHT=y > > > > CONFIG_ACPI_VIDEO=n > > > > > > That also gets me a dead display. Backlight doesn't turn back on. > > > > Anything under /sys/class/backlight? > > Entries from ibm_acpi. I rmmod'd that, leaving the dir empty, > and it still fails.
What happens if you never load ibm-acpi? I'm a bit puzzled as CONFIG_FB_BACKLIGHT doesn't do anything with the intelfb driver. One thing it does do is set CONFIG_BACKLIGHT_CLASS_DEVICE. When you disabled FB_BACKLIGHT and got a working display on resume, was that set and was (or had) ibm-acpi been loaded? A variety of other options such as ACPI_IBM also set CONFIG_BACKLIGHT_CLASS_DEVICE although without a backlight driver it will do nothing hence the suspicion is on ibm-acpi, perhaps interacting with the backlight class badly. Does echoing numbers to /sys/class/backlight/ibm_acpi/brightness change the backlight brightness as expected? If you can ssh into the machine after its resumed with the display problem, it would be interesting to know what the brightness was and if changing it helped too... Regards, Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
