Bug#448467: xserver-xorg-video-intel: Thinkpad brightness keys don't work
Marcus Better
Version: 2:2.1.1-4
Severity: normal
The brightness control keys on my Thinkpad R60 stopped working in X
some time ago. I have probably upgraded both kernel and X.org since
then, and don't know exactly when it broke.
Pressing the keys in an X session now only causes a short flicker, but
does not affect the brightness. However the KDE on-screen display
seems to think everything is fine since I can control the level it
reports.
The brightness keys still work in a virtual console, just not in X.
"xbacklight -set" changes the brightness in a totally random way. For
example p=98 is barely visible, and most other settings give a
constant medium-bright level.
I can control the brightness at least reasonably well with
echo 50 > /sys/devices/virtual/backlight/acpi_video1/brightness
except that levels below 30 don't seem to have any effect.
Also I can do
echo up > /proc/acpi/ibm/brightness
or
echo down > /proc/acpi/ibm/brightness
I have an unpatched kernel 2.6.23 (Linus' git tree) with thinkpad-acpi
0.16, hal 0.5.9.1-6, acpid 1.0.4-7.1.
The problem matches this description [1] which points to a fix in Ubuntu.
[1] http://permalink.gmane.org/gmane.linux.hardware.thinkpad/32463
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.23-melech (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages xserver-xorg-video-intel depends on:
ii libc6 2.6.1-1 GNU C Library: Shared libraries
ii libdrm2 2.3.0-4 Userspace interface to kernel DRM
ii xserver-xorg-core 2:1.4-3 Xorg X server - core server
xserver-xorg-video-intel recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Henrique de Moraes Holschuh
> The brightness control keys on my Thinkpad R60 stopped working in X
> some time ago. I have probably upgraded both kernel and X.org since
> then, and don't know exactly when it broke.
The *60 and *61 series of ThinkPads require proper brightness support using
the ACPI specification. Unfortunately, the kernel ACPI video driver is not
quite there yet, and you need at the very least the 2.6.22 version of ACPI
video to have any chance of it working most of the time.
They can also operate using thinkpad-acpi 0.18 (not merged into mainline
yet), although that requires a module parameter, as thinkpad-acpi 0.18
disables its brightness driver by default when it detects there is standard
ACPI brightness control in the BIOS.
thinkpad-acpi patches are at http://ibm-acpi.sf.net.
> Pressing the keys in an X session now only causes a short flicker, but
> does not affect the brightness. However the KDE on-screen display
> seems to think everything is fine since I can control the level it
> reports.
That's because the KDE on-screen displays does something Not Nice and
accesses the thinkpad NVRAM directly.
> I can control the brightness at least reasonably well with
> echo 50 > /sys/devices/virtual/backlight/acpi_video1/brightness
> except that levels below 30 don't seem to have any effect.
That might be the correct behaviour. The BIOS has some non-linear mapping
tables to translate from 0-100 to 0-7/0-15 (depending on thinkpad model).
It could be that anything from 0 to 30 maps to the first brightness level in
the hardware.
--
"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
Brice Goglin
thank you
Marcus Better wrote:
> The brightness control keys on my Thinkpad R60 stopped working in X
> some time ago. I have probably upgraded both kernel and X.org since
> then, and don't know exactly when it broke.
>
> Pressing the keys in an X session now only causes a short flicker, but
> does not affect the brightness. However the KDE on-screen display
> seems to think everything is fine since I can control the level it
> reports.
>
It might not be a good idea to use these keys since they modify the
hardware state in the back of the X driver. Using xbacklight is probably
a better idea in the end. But xbacklight has some other bugs on some
Intel boards unfortunately (see below).
> "xbacklight -set" changes the brightness in a totally random way. For
> example p=98 is barely visible, and most other settings give a
> constant medium-bright level.
>
We have a couple bugs about this. For instance #438969 and #439744. You
should try the latest upstream git of the Intel driver without and with
the patch from https://bugs.freedesktop.org/show_bug.cgi?id=11527 and
let us know whether it helps.
Brice
Marcus Better
> forcemerge 443111 448467
Umerging and reopening since I still have this problem. Not sure if it's
a kernel or X.org problem though!
> Marcus Better wrote:
>> The brightness control keys on my Thinkpad R60 stopped working in X
>> some time ago. I have probably upgraded both kernel and X.org since
>> then, and don't know exactly when it broke.
>>
>> Pressing the keys in an X session now only causes a short flicker, but
>> does not affect the brightness. However the KDE on-screen display
>> seems to think everything is fine since I can control the level it
>> reports.
Update: the on-screen display is now stuck at 42%.
I am now running kernel 2.6.24-rc4 with xserver-xorg-core
2:1.4.1~git20071119-1, xserver-xorg-video-intel 2:2.2.0-1 and
thinkpad-acpi 0.18-20071203 (from patch):
thinkpad_acpi: ThinkPad ACPI Extras v0.18-20071203
thinkpad_acpi: http://ibm-acpi.sf.net/
thinkpad_acpi: ThinkPad BIOS 7CETC7WW (2.17 ), EC 7CHT21WW-1.09
thinkpad_acpi: Lenovo ThinkPad R60
thinkpad_acpi: radio switch found; radios are enabled
thinkpad_acpi: standard ACPI backlight interface available, not loading
native one...
It doesn't matter if I set the brightness_enable=1 option to thinkpad-acpi.
Marcus
Brice Goglin
> Update: the on-screen display is now stuck at 42%.
>
> I am now running kernel 2.6.24-rc4 with xserver-xorg-core
> 2:1.4.1~git20071119-1, xserver-xorg-video-intel 2:2.2.0-1 and
> thinkpad-acpi 0.18-20071203 (from patch):
>
> thinkpad_acpi: ThinkPad ACPI Extras v0.18-20071203
> thinkpad_acpi: http://ibm-acpi.sf.net/
> thinkpad_acpi: ThinkPad BIOS 7CETC7WW (2.17 ), EC 7CHT21WW-1.09
> thinkpad_acpi: Lenovo ThinkPad R60
> thinkpad_acpi: radio switch found; radios are enabled
> thinkpad_acpi: standard ACPI backlight interface available, not
> loading native one...
>
> It doesn't matter if I set the brightness_enable=1 option to
> thinkpad-acpi.
Can you try the latest upstream git of the driver ? It contains some
backlight fixes.
Also, there is now 4 strategies to manipulate the backlight: kernel,
native, legacy or combination. The driver selects one by default
depending on the hardware. Which one do you get at startup? (look in the
output of xrandr --prop). Does it help if you change to another one,
with for instance xrandr --output LVDS --set BACKLIGHT_CONTROL legacy ?
Also, if you think the kernel version matters, can you downgrade to
2.6.23 or 2.6.22?
Brice
Marcus Better
> Also, there is now 4 strategies to manipulate the backlight: kernel,
> native, legacy or combination. The driver selects one by default
> depending on the hardware. Which one do you get at startup?
~$ xrandr --prop
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1024 x 1024
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis)
304mm x 228mm
EDID_DATA:
00ffffffffffff0030ae404000000000
010f0103801e1778ea87f594574f8c27
27505421080001010101010101010101
01010101010164190040410026301888
360030e4100000182815004041002630
1888360030e4100000180000000f0061
43326143280f010006af5125000000fe
0041554f423135305847303256350051
BACKLIGHT_CONTROL: kernel
supported: native legacy combination kernel
BACKLIGHT: 60 (0x0000003c) range: (0,100)
1024x768 60.0*+ 50.0
800x600 60.3
640x480 60.0 59.9
> Does it help if you change to another one,
> with for instance xrandr --output LVDS --set BACKLIGHT_CONTROL legacy ?
Yes, it works when set to "native" or "combination"!
With "kernel", the on-screen display does not show up at every press of
the brightness key, and it quickly gets stuck at 42%.
With "legacy" the on-screen display goes up and down but the brightness
is not changed.
This is so far with the current packaged video driver.
Marcus
Julien Cristau
> (II) LoadModule: "intel"
> (II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so
> (II) Module intel: vendor="X.Org Foundation"
> compiled for 1.3.0, module version = 2.2.0
> Module class: X.Org Video Driver
> ABI class: X.Org Video Driver, version 1.2
> (EE) module ABI major version (1) doesn't match the server's version (2)
> (II) UnloadModule: "intel"
> (II) Unloading /usr/lib/xorg/modules/drivers//intel_drv.so
> (EE) Failed to load module "intel" (module requirement mismatch, 0)
Looks like you built it against an old version of xserver-xorg-dev?
Cheers,
Julien
Brice Goglin
> On Sun, Dec 9, 2007 at 19:25:20 +0100, Marcus Better wrote:
>
> > Brice Goglin wrote:
> >> Can you try the latest upstream git of the driver ?
> >
> > That didn't go too well, X refused to start. Log attached.
> >
> > (II) LoadModule: "intel"
> > (II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so
> > (II) Module intel: vendor="X.Org Foundation"
> > compiled for 1.3.0, module version = 2.2.0
> > Module class: X.Org Video Driver
> > ABI class: X.Org Video Driver, version 1.2
> > (EE) module ABI major version (1) doesn't match the server's version (2)
> > (II) UnloadModule: "intel"
> > (II) Unloading /usr/lib/xorg/modules/drivers//intel_drv.so
> > (EE) Failed to load module "intel" (module requirement mismatch, 0)
>
> Looks like you built it against an old version of xserver-xorg-dev?
Right, you need to upgrade xserver-xorg-dev to unstable and rebuild again.
Brice
Marcus Better
> Looks like you built it against an old version of xserver-xorg-dev?
Ok, I just tried with a new one, but the brightness is still broken. It
requires "native" or "combination" mode.
Marcus
Henrique de Moraes Holschuh
> Julien Cristau wrote:
>> Looks like you built it against an old version of xserver-xorg-dev?
>
> Ok, I just tried with a new one, but the brightness is still broken. It
> requires "native" or "combination" mode.
I'd like to see X.org talking to the kernel to find out and coordinate which
mode should be used...
--
"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
--
Brice Goglin
> On Sat, 15 Dec 2007, Marcus Better wrote:
>
>> I just tried with a new one, but the brightness is still broken. It
>> requires "native" or "combination" mode.
>>
>
> I'd like to see X.org talking to the kernel to find out and coordinate which
> mode should be used...
>
Jesse,
Could you please have a look at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448467
and see if you can find a solution with the thinkpad guys for correct
backlight handling? Marcus tried with intel git about a week ago, it
didn't go very well.
Thanks,
Brice
Jesse Barnes
> Henrique de Moraes Holschuh wrote:
> > On Sat, 15 Dec 2007, Marcus Better wrote:
> >> I just tried with a new one, but the brightness is still broken.
> >> It requires "native" or "combination" mode.
> >
> > I'd like to see X.org talking to the kernel to find out and
> > coordinate which mode should be used...
>
> Jesse,
>
> Could you please have a look at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448467
> and see if you can find a solution with the thinkpad guys for correct
> backlight handling? Marcus tried with intel git about a week ago, it
> didn't go very well.
The backlight situation is rather unfortunate. As you've already
discovered, there are several different ways backlights are controlled
on various platforms, and some of them are incompatible.
The Intel X driver now tries to talk to the kernel drivers directly (via
the /sys/class/backlight interface) starting with the thinkpad_screen
driver, followed by acpi_video1 and acpi_video0. Depending on how your
kernel is configured, this may work perfectly or result in the drivers
fighting one another for backlight adjustments.
Since on Thinkpads, the kernel method is available (either via the
kernel thinkpad driver or ACPI) you should try to use that, but it may
be that the acpi_video1 method is your best choice. You can try that
interface by changing the order of the string array in i830_lvds.c
around line 67.
If you want to use one of the other methods (which may provide you with
more possible backlight levels) you should unload all kernel backlight
drivers prior to loading X (or disabling their backlight interfaces as
in the case of the thinkpad driver); that may give you a good user
experience too...
Sorry if I missed anything in the initial bug report, I'm on vacation at
my mother-in-law's right now, with a free wireless connection kindly
provided by someone called 'jazzman' (at least according to his
ESSD :).
Jesse
Henrique de Moraes Holschuh
> The Intel X driver now tries to talk to the kernel drivers directly (via
> the /sys/class/backlight interface) starting with the thinkpad_screen
> driver, followed by acpi_video1 and acpi_video0. Depending on how your
> kernel is configured, this may work perfectly or result in the drivers
> fighting one another for backlight adjustments.
You are *required* to use the latest devel version 0.18 of thinkpad-acpi
(available in kernel 2.6.24, OR through patches from ibm-acpi.sf.net for
kernels 2.6.20 and above) if you want to use thinkpad_screen in a Lenovo
Thinkpad *61 laptop.
Also, by default, a new enough thinkpad-acpi (0.17? I forget) will refrain
from registering the backlight subdriver if it detects ACPI support is
available (*60 models with very new BIOS, and all *61 models).
> Since on Thinkpads, the kernel method is available (either via the
> kernel thinkpad driver or ACPI) you should try to use that, but it may
> be that the acpi_video1 method is your best choice. You can try that
> interface by changing the order of the string array in i830_lvds.c
> around line 67.
Patches to fix the kernel to not export a backlight entry for inactive ACPI
nodes are queued, but really, it is *an extremely bad idea* to hardcode
*anything* of the sort inside X.org. It needs to be made a configurable
*list* of backlight devices, please.
> If you want to use one of the other methods (which may provide you with
> more possible backlight levels) you should unload all kernel backlight
> drivers prior to loading X (or disabling their backlight interfaces as
> in the case of the thinkpad driver); that may give you a good user
> experience too...
Agreed.
--
"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
--
Jesse Barnes
> > Since on Thinkpads, the kernel method is available (either via the
> > kernel thinkpad driver or ACPI) you should try to use that, but it
> > may be that the acpi_video1 method is your best choice. You can
> > try that interface by changing the order of the string array in
> > i830_lvds.c around line 67.
>
> Patches to fix the kernel to not export a backlight entry for
> inactive ACPI nodes are queued, but really, it is *an extremely bad
> idea* to hardcode *anything* of the sort inside X.org. It needs to
> be made a configurable *list* of backlight devices, please.
That's good, but there has to be a list somewhere since the kernel
backlight interface was so poorly designed. I don't care if it's in
the driver with an override list in xorg.conf or what, but it has to be
somewhere.
Jesse
Henrique de Moraes Holschuh
> That's good, but there has to be a list somewhere since the kernel
> backlight interface was so poorly designed. I don't care if it's in
> the driver with an override list in xorg.conf or what, but it has to be
> somewhere.
As long as one can override it with a *list* (which must include the empty
list to disable the feature) in xorg.conf, there is not a problem to have a
hardcoded default.
--
"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
--
Brice Goglin
> On Thu, 27 Dec 2007, Jesse Barnes wrote:
> > That's good, but there has to be a list somewhere since the kernel
> > backlight interface was so poorly designed. I don't care if it's in
> > the driver with an override list in xorg.conf or what, but it has to be
> > somewhere.
>
> As long as one can override it with a *list* (which must include the empty
> list to disable the feature) in xorg.conf, there is not a problem to have a
> hardcoded default.
Thanks a lot for discussing this, guys.
Unfortunately, since Marcus still had problems with 2.6.24-rc4 and a
recent snapshot of thinkpad-acpi, what do we have to wait for before
this could work?
Is anybody actually implementing something to handle the above list
of backlight devices?
thanks,
Brice
Jesse Barnes
> On Fri, Dec 28, 2007 at 03:42:09PM -0200, Henrique de Moraes Holschuh wrote:
> > On Thu, 27 Dec 2007, Jesse Barnes wrote:
> > > That's good, but there has to be a list somewhere since the kernel
> > > backlight interface was so poorly designed. I don't care if it's in
> > > the driver with an override list in xorg.conf or what, but it has to be
> > > somewhere.
> >
> > As long as one can override it with a *list* (which must include the
> > empty list to disable the feature) in xorg.conf, there is not a problem
> > to have a hardcoded default.
>
> Thanks a lot for discussing this, guys.
>
> Unfortunately, since Marcus still had problems with 2.6.24-rc4 and a
> recent snapshot of thinkpad-acpi, what do we have to wait for before
> this could work?
>
> Is anybody actually implementing something to handle the above list
> of backlight devices?
Sounds like Marcus' config will use the ACPI /sys/class/backlight interface by
default. I think this is a good thing, since it's the preferred method on
thinkpads. However, existing ACPI video drivers don't provide a nice,
sequential set of backlight values, so it's easy to get "stuck" at a given
backlight level if you just try to use the up/down controls. See the lkml
discussion with the subject "[PATCH] Rationalise ACPI backlight
implementation" for details on that, it may be that the patch in that thread
will work for Marcus.
Jesse