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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
