Hi all,

I just upgraded from 2.6.25.17 to 2.6.26.5 on my Thinkpad Z61t, and found
the brightness keys will cause the X server to die.  When using the
brightness up/down keys, the screen will go blank -- Control+Alt+F# will
still switch to a different virtual console, but switching back will not
restore the video state.

After killing the window manager, I was able to bring up X again without
a problem -- but using the brightness keys still causes it to go blank
again within X, while the brightness does get changed correctly on the
console.

There were no kernel messages, but this appeared in the Xorg log:

Backtrace:
0: X(xf86SigHandler+0x84) [0x80c43e4]
1: [0xffffe420]
2: /usr/lib/xorg/modules/extensions/libglx.so(__glXVendorPrivate+0x19c) [0xb7c9d
bec]
3: /usr/lib/xorg/modules/extensions/libglx.so [0xb7ca1f6a]
4: X(Dispatch+0x19b) [0x8086ccb]
5: X(main+0x489) [0x806e6b9]
6: /lib/tls/libc.so.6(__libc_start_main+0xc8) [0xb7de4ea8]
7: X(FontFileCompleteXLFD+0xa5) [0x806d9f1]


Fatal server error:
Caught signal 4.  Server aborting

(WW) I810(0): Successfully set original devices
(WW) I810(0): Setting the original video mode instead of restoring
        the saved state
(--) I810(0): A non-CRT device is attached to pipe B.
        No refresh rate overrides will be attempted.
(WW) I810(0): Extended BIOS function 0x5f05 failed.
(II) I810(0): BIOS call 0x5f05 not supported, setting refresh with VBE 3 method.
(II) I810(0): xf86UnbindGARTMemory: unbind key 12
(II) I810(0): xf86UnbindGARTMemory: unbind key 8
(II) I810(0): xf86UnbindGARTMemory: unbind key 9
(II) I810(0): xf86UnbindGARTMemory: unbind key 11
(II) I810(0): xf86UnbindGARTMemory: unbind key 10
(WW) I810(0): Successfully set original devices (2)

I'm currently running on a Debian/etch system with the following packages:
xserver-xorg                     7.1.0-19
xserver-xorg-video-i810          1.7.2-4

gcc 4.1.2 from Debian, Core Duo (T2500).

00:02.0 VGA compatible controller: Intel Corporation Mobile ...
[ message continues ]

(Subject changed to match the observed cause)

Figured out what the change was -- in 2.6.25.x, the brightness keys worked
without setting CONFIG_ACPI_VIDEO.  However, in 2.6.26.x, the brightness keys
do not work on the console without that enabled.

If 2.6.25.x has that config option enabled, I still get the same blank screen
symptoms -- with the following in the X logs:

(II) PM Event received: Capability Changed
I830PMEvent: Capability change
(II) I810(0): Next ACPI _DGS [0] 0x80000100
(II) I810(0): ACPI Toggle devices 0x1
(II) I810(0): ACPI Toggle to 0x1
(II) I810(0): Hotkey switch to 0x800.
(II) I810(0): Attachable device 0x80000100.
(II) I810(0): Attachable device 0x80000240.
(II) I810(0): Attachable device 0x80000410.
(II) I810(0): Requested display devices 0x800.
(II) I810(0): Toggle (1) 0x1
(II) I810(0): Detected duplicate devices. Toggling (0x1)
(II) I810(0): Detected display change operation (0x0, 0x800, 0x1).
(II) I810(0): Clearing Clone mode
(II) I810(0): Primary pipe is now A.
(--) I810(0): A non-CRT device is attached to pipe A.
        No refresh rate overrides will be attempted.
(II) I810(0): Display plane A is enabled and connected to Pipe A.
(II) I810(0): Display plane B is disabled and connected to Pipe B.
(II) I810(0): Enabling plane A.
(II) I810(0): Display plane A is now enabled and connected to Pipe A.
(II) I810(0): Display plane B is now disabled and connected to Pipe B.
(II) I810(0): PIPEACONF is 0x80000000
(II) I810(0): PIPEBCONF is 0x00000000
(II) I810(0): Mode bandwidth is 58 Mpixel/s
(II) I810(0): maxBandwidth is 1152 Mbyte/s, pipe bandwidths are 48 Mbyte/s, 0 Mb
yte/s
(WW) I810(0): Changing XVideo pipe (1 to 0).

Without CONFIG_ACPI_VIDEO, the above message don't appear.  From this point,
any pointers on figuring out why the ACPI features makes the screen go blank?

-- DN
Daniel
--

[ message continues ]

Yes. X assumed that any ACPI key press was a request to switch the video 
output. Upgrade X.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

Since CONFIG_ACPI_VIDEO wasn't required before 2.6.26.x to change the LCD
brightness, I'd rather the kernel go back to whatever it was doing for
2.6.25.x.  Upgrading X past what's currently packaged by the distribution
just to get a new kernel working is somewhat of a pain.

What change linked the brightness keys to CONFIG_ACPI_VIDEO?

-- DN
Daniel
--

[ message continues ]

Well, we do give you a way out: do not load ACPI video, and load
thinkpad-acpi with the proper parameters to enable its backlight control (if

Your X is broken, and in an extremely hideous way.  You could try to get it
to disable ACPI key support, or you can make sure nothing EVER sends ACPI
video events to it.  That means you must not use the ACPI video module in
your kernel until you install a fixed X.org.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--

[ message continues ]

Okay, I'll see what happens.

-- DN
Daniel
--

[ message continues ]

Yes, I had similar problems... for me it blanked screen on closing

For me CONFIG_ACPI_VIDEO never really worked...


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]

On my shiny new X200 running Fedora Rawhide, I'm finding that the 
brightness control keys work OK, but the backlight remains stuck off 
after a resume.  The machine is working fine but the backlight is just 
off; I can see the display under a bright light.  Switching consoles and 
poking about in /sys/class/backlight/acpi_video?/ didn't help.

    J
--

[ message continues ]

What are you using for s2ram? s2ram -f -a 3 normally works on thinkpads...
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]

Fedora doesn't use s2ram, and at this point passing any s2ram flags on 
Intel graphics is just covering up kernel bugs.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

Intel graphics, right? The DRM layer should handle full resume on modern 
Intel hardware, but there's the potential for bugs. This is entirely 
unrelated to ACPI, though.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

OK, that's a good clue.  I poke at acpi to change the brightness, so I'd 
assumed that acpi would also handle turning the backlight on/off.

I'm using the rawhide rather than standard kernel, but I'd thought they 
were fairly similar.

I'm also using the vesa X server; I haven't tried using the intel one yet.

    J
--

[ message continues ]

Ah. In that case, I suspect the DRM module is never binding and may not 
do its thing.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--

[ message continues ]

OK, great.  Simply loading the i915 module makes the backlight come back 
after resume, even using the vesa X server.

Thanks,
    J
--

[ message continues ]

I believe vanilla and rawhide kernels are _very_ different in this
area.

On your config, s2ram -f -a 3 may be the right thing after all ;-).

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]