Bug 13368 - Problem with ACPI-Brightness and Hotkeys
Problem with ACPI-Brightness and Hotkeys
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Platform
All Linux
: P1 normal
Assigned To: Henrique de Moraes Holschuh
:
Depends on:
Blocks: 56331
  Show dependency treegraph
 
Reported: 2009-05-23 09:51 UTC by Conrad Kostecki
Modified: 2013-04-09 06:23 UTC (History)
5 users (show)

See Also:
Kernel Version:
Tree: Mainline
Regression: No


Attachments
dmesg output (39.16 KB, application/octet-stream)
2009-05-23 09:51 UTC, Conrad Kostecki
Details
hotkey_event (174 bytes, application/octet-stream)
2009-05-25 17:36 UTC, Conrad Kostecki
Details
"grep . /proc/acpi/video/*/*/brightness" (356 bytes, text/plain)
2009-05-25 17:37 UTC, Conrad Kostecki
Details
"grep . /sys/class/backlight/*/*" (194 bytes, text/plain)
2009-05-25 17:38 UTC, Conrad Kostecki
Details
acpidump (288.43 KB, application/octet-stream)
2009-05-25 17:40 UTC, Conrad Kostecki
Details
customized DSDT: with more debug info (466.97 KB, application/octet-stream)
2009-05-27 07:53 UTC, Zhang Rui
Details
messages1.log (303.57 KB, text/plain)
2009-05-27 16:59 UTC, Conrad Kostecki
Details
messages2.log (207.63 KB, application/octet-stream)
2009-05-27 16:59 UTC, Conrad Kostecki
Details
customized DSDT: don't invoke \UCMS (0x16) (466.75 KB, application/octet-stream)
2009-06-01 09:22 UTC, Zhang Rui
Details
customized DSDT: works exactly the same as before (466.75 KB, application/octet-stream)
2009-06-02 03:46 UTC, Zhang Rui
Details
customized DSDT: work correctly (466.75 KB, application/octet-stream)
2009-06-02 03:48 UTC, Zhang Rui
Details
dmesg.log (97.83 KB, application/octet-stream)
2009-06-02 11:40 UTC, Conrad Kostecki
Details
dmesg2.log (97.69 KB, application/octet-stream)
2009-06-02 11:40 UTC, Conrad Kostecki
Details
customized DSDT: dsdt that should work well (466.97 KB, application/octet-stream)
2009-06-04 02:30 UTC, Zhang Rui
Details
customized DSDT: remove two debug lines (466.81 KB, application/octet-stream)
2009-06-04 02:31 UTC, Zhang Rui
Details
dmesg.log (111.36 KB, application/octet-stream)
2009-06-04 16:45 UTC, Conrad Kostecki
Details
dmesg2.log (110.87 KB, application/octet-stream)
2009-06-04 16:45 UTC, Conrad Kostecki
Details
customized DSDT (466.52 KB, application/octet-stream)
2009-06-05 01:40 UTC, Zhang Rui
Details
customized DSDT (466.52 KB, application/octet-stream)
2009-06-08 02:48 UTC, Zhang Rui
Details

Description Conrad Kostecki 2009-05-23 09:51:00 UTC
Hello.
I've got an Thinkpad X200 Tablet. There seems to be a small problem with the acpi backlight.

When I press FN+POS1 (Brightness Up) the brightness is first time going one level down, after second pressing, the brightness is going up again.

This happans with FN+END (Brightness Down). After first time, brightness goes up, second time its normal and goes down as it should.

Seems to be a bug for me? Which infos do you need?

Kernel Version: 2.6.29-gentoo-r4 (problem happens with vanilla sources 2.6.29 too)
I am also attaching my dmesg.log
Comment 1 Conrad Kostecki 2009-05-23 09:51:50 UTC
Created attachment 21505 [details]
dmesg output
Comment 2 ykzhao 2009-05-25 00:42:00 UTC
Will you please attach the output of acpidump?
Will you please do the following test on your box?
    a. kill the process which is using /proc/acpi/event (using the command of "lsof /proc/acpi/event" to get the process ID)
    b. cat /proc/acpi/event >hotkey_event
    c. press the Brightness up/down hotkeys 
    d. press Ctr+C
    After the test, please attach the output of hotkey_event.

    Thanks.
Comment 3 Zhang Rui 2009-05-25 02:59:22 UTC
please attach the output of both
"grep . /proc/acpi/video/*/*/brightness"
"grep . /sys/class/backlight/*/*"
Comment 4 Conrad Kostecki 2009-05-25 17:36:33 UTC
Hello Guys,
here are my results.

hotkey_event:
First time pressed 3 times FN+POS1 (Brightness Up):
1) Britness went one level down
2) Britness went one level up
3) Britness went one level up

Second time pressed 3 times FN+END (Brightness Down):
1) Britness went one level up
2) Britness went one level down
3) Britness went one level down

Attaching hotkey_event and the results of both grep's...
Comment 5 Conrad Kostecki 2009-05-25 17:36:55 UTC
Created attachment 21538 [details]
hotkey_event
Comment 6 Conrad Kostecki 2009-05-25 17:37:36 UTC
Created attachment 21539 [details]
"grep . /proc/acpi/video/*/*/brightness"
Comment 7 Conrad Kostecki 2009-05-25 17:38:16 UTC
Created attachment 21540 [details]
"grep . /sys/class/backlight/*/*"
Comment 8 Conrad Kostecki 2009-05-25 17:40:08 UTC
Created attachment 21541 [details]
acpidump
Comment 9 Zhang Rui 2009-05-26 01:01:29 UTC
what if you run
"echo 1 > /sys/class/backlight/acpi_video0/brightness"
"echo 2 > /sys/class/backlight/acpi_video0/brightness"
"echo 3 > /sys/class/backlight/acpi_video0/brightness"
...
does the brightness increases consistently?
Comment 10 Conrad Kostecki 2009-05-26 13:10:09 UTC
X200T ~ # echo 1 > /sys/class/backlight/acpi_video0/brightness
Brightness decreases

X200T ~ # echo 2 > /sys/class/backlight/acpi_video0/brightness
Brightness decreases

X200T ~ # echo 3 > /sys/class/backlight/acpi_video0/brightness
Brightness increases

X200T ~ # echo 4 > /sys/class/backlight/acpi_video0/brightness
Brightness increases

This are my results.
Comment 11 ykzhao 2009-05-27 04:43:42 UTC
HI, Conrad
    Will you please confirm whether the i915 driver is loaded?
    Will you please do the following test?
    a. set the lowest level brightness (echo 0 > /sys/class/backlight/acpi_video0/brightness)
    b. then you set the different level and see whether the brightness is increased. For example: echo 1 > /sys/class/backlight/acpi_video0/brightness, echo 5 > /sys/class/backlight/acpi_video0/brightness

    c. set the max level brightness (echo 15 > /sys/class/backlight/acpi_video0/brightness)
    d. then you set the different level and see whether the brightness is decreased. echo 12/10/5 > /sys/class/backlight/acpi_video0/brightness
    Thanks.
Comment 12 Zhang Rui 2009-05-27 07:53:24 UTC
Created attachment 21582 [details]
customized DSDT: with more debug info
Comment 13 Zhang Rui 2009-05-27 07:55:30 UTC
hi, Conrad,

please
1. apply the customized DSDT I attached
2. set CONFIG_ACPI_DEBUG
3. rebuild your kernel
4. boot with acpi.debug_layer=0xffffffff acpi.debug_level=0x07
5. redo the test in comment #9, or the test suggested by Yakui in comment #11
6. attach the dmesg output after the test.
Comment 14 Conrad Kostecki 2009-05-27 16:21:23 UTC
Hi!
This first test is WITHOUT any modified DSDT!

-> echo 0 > /sys/class/backlight/acpi_video0/brightness
brightness went only one level down

-> echo 0 > /sys/class/backlight/acpi_video0/brightness
used command second time, now brightness went to min level

-> echo 5 > /sys/class/backlight/acpi_video0/brightness
nothing happend (i guess, it tried to go one level down, which is impossible)

-> echo 5 > /sys/class/backlight/acpi_video0/brightness
used command second time, now brightness went a few level up

-> echo 15 > /sys/class/backlight/acpi_video0/brightness
nothing happend

-> echo 15 > /sys/class/backlight/acpi_video0/brightness
used command second time, now brightness went to max level

-> echo 10 > /sys/class/backlight/acpi_video0/brightness
nothing happend

-> echo 10 > /sys/class/backlight/acpi_video0/brightness
used command second time, now brightness went a few level down

---

Will now apply the modified DSDT and test again.
Comment 15 Conrad Kostecki 2009-05-27 16:58:42 UTC
Hi!
Now, I've tested with your new DSDT and Debug Options.
This new DSDT seems to fix my problem? Now the brightness keys works as they should! Now more wrong up and down?!

What I did:

1) Booted Kernel with modifed DSDT and Debug Options
2) Used few times FN+POS1 and FN+END
3) echo 1 > /sys/class/backlight/acpi_video0/brightness
4) echo 2 > /sys/class/backlight/acpi_video0/brightness
5) echo 3 > /sys/class/backlight/acpi_video0/brightness
6) Used few times FN+POS1 and FN+END

Booting without modified DSDT, the bug about the brightness accours again.
Attaching for this messages1.log

But there seems still be a small error using new dsdt. When I go via hotkeys to min level, I've to press twive, to get one level up. After this, it works normally.

What I did:
1) Booted Kernel with modifed DSDT and Debug Options
2) Via FN+END go to min brightness level
3) Press FN+POS1 to go one level up (nothing happend)
4) Press FN+POS1 to go one level up (one level up now)

Attaching for this messages2.logHi!
Now, I've tested with your new DSDT and Debug Options.
This new DSDT seems to fix my problem? Now the brightness keys works as they should! Now more wrong up and down?!

What I did:

1) Booted Kernel with modifed DSDT and Debug Options
2) Used few times FN+POS1 and FN+END
3) echo 1 > /sys/class/backlight/acpi_video0/brightness
4) echo 2 > /sys/class/backlight/acpi_video0/brightness
5) echo 3 > /sys/class/backlight/acpi_video0/brightness
6) Used few times FN+POS1 and FN+END

Booting without modified DSDT, the bug about the brightness accours again.
Attaching for this messages1.log

But there seems still be a small error using new dsdt. When I go via hotkeys to min level, I've to press twive, to get one level up. After this, it works normally.

What I did:
1) Booted Kernel with modifed DSDT and Debug Options
2) Via FN+END go to min brightness level
3) Press FN+POS1 to go one level up (nothing happend)
4) Press FN+POS1 to go one level up (one level up now)

Attaching for this messages2.log

P.S.: I don't have any xorg or i915 driver installed!
Comment 16 Conrad Kostecki 2009-05-27 16:59:29 UTC
Created attachment 21586 [details]
messages1.log
Comment 17 Conrad Kostecki 2009-05-27 16:59:49 UTC
Created attachment 21587 [details]
messages2.log
Comment 18 Conrad Kostecki 2009-05-27 17:00:08 UTC
I am sorry for my last post, copy & paste messed a litte bit up...
Comment 19 Zhang Rui 2009-06-01 09:08:25 UTC
that's weird, I didn't make any functional changes in the new DSDT.
I'll attach two DSDT files which has little difference, please try each of them and see if they make any difference.
Comment 20 Zhang Rui 2009-06-01 09:21:04 UTC
(In reply to comment #19)
> that's weird, I didn't make any functional changes in the new DSDT.

sorry, there is one difference.
In the old _BCM method,
                \_SB.PCI0.LPC.EC.BRNS (\UCMS (0x16))
In the new _BCM method,
                \UCMS (0x16)
                \_SB.PCI0.LPC.EC.BRNS ()

BRNS is a method with 0 parameters.
So I suspect the \UCMS is not invoked in the old _BCM method, while it is mandatory for a brightness change.

> I'll attach two DSDT files which has little difference, please try each of them
> and see if they make any difference.

I'll attach a new DSDT, which removes the \UCMS (0x16) call.
please give it a try and make sure it works exactly the same as before.
Comment 21 Zhang Rui 2009-06-01 09:22:02 UTC
Created attachment 21682 [details]
customized DSDT: don't invoke \UCMS (0x16)
Comment 22 Conrad Kostecki 2009-06-01 10:29:52 UTC
Hi!
I've now compiled a new kernel with your new modified dsdt.

Result: NONE of my Hotkeys for brightness are working now. Brightness control ist just dead. I can press them if I want, what brightness does not chance.

What I did:

1) Booted Kernel with: acpi.debug_layer=0xffffffff acpi.debug_level=0x07
2) Press PN+POS1 (nothing happend, just dead)
3) Press PN+END (nothing happend, just dead)
4) Press PN+POS1 (nothing happend, just dead)
5) Press PN+END (nothing happend, just dead)

Hope this helps you...
Comment 23 Zhang Rui 2009-06-02 03:46:04 UTC
Created attachment 21697 [details]
customized DSDT: works exactly the same as before

please try this one, which should work exactly the same as before.
Comment 24 Zhang Rui 2009-06-02 03:48:31 UTC
Created attachment 21698 [details]
customized DSDT: work correctly

please try this one and confirm that it works the same as the first one you have tried.
Comment 25 Conrad Kostecki 2009-06-02 11:40:02 UTC
Created attachment 21705 [details]
dmesg.log

I am here using now your first new dsdt attached.
The result is exactly the same as in comment #22

Attaching dmesg.log
Comment 26 Conrad Kostecki 2009-06-02 11:40:47 UTC
Created attachment 21706 [details]
dmesg2.log

I am here using now your second new dsdt attached.
The result is exactly the same as in comment #22

Attaching dmesg2.log
Comment 27 Zhang Rui 2009-06-03 05:55:22 UTC
well, that's really weird.
the DSDT in comment #23 is exactly the same as the one in comment #12, except removing some debug info...
could you please make a double check?
Comment 28 Conrad Kostecki 2009-06-03 20:12:25 UTC
Hi!
I've now tested again with fresh compiles sources.

DSDT from Comment #23 & #24 produce the same as mentioned in comment #22

I've also used DSDT from Comment #12, just to verfify, the new DSDT works. Here I've the same results as in my Comment #15

---

So yes, my results previous are correct.
Comment 29 Zhang Rui 2009-06-04 02:30:02 UTC
Created attachment 21741 [details]
customized DSDT: dsdt that should work well
Comment 30 Zhang Rui 2009-06-04 02:31:35 UTC
Created attachment 21742 [details]
customized DSDT: remove two debug lines

        Method (_BCM, 1, NotSerialized)
        {
            Store ("In _BCM", Debug)
            Store (Match (BCLP, MEQ, Arg0, MTR, 0x00, 0x00), Local0)
            Store ("Local0", Debug)
            Store (Local0, Debug)
            If (LNotEqual (Local0, Ones))
            {
                Store (DerefOf (Index (BCLL, Local0)), \BRLV)
                Store ("BRLV", Debug)
                Store (BRLV, Debug)
                \UCMS (0x16)
                \_SB.PCI0.LPC.EC.BRNS ()
            }
        }
Comment 31 Zhang Rui 2009-06-04 02:32:59 UTC
please try the above two DSDT tables.
The one in comment #29 should work for you, but I'm not sure about the one in comment #30.
Comment 32 Conrad Kostecki 2009-06-04 16:45:10 UTC
Hi!
I've now made new tests :)

The DSDT from Comment #29 gives me the same result as in Comment #15 !
-> Attaching for this dmesg.log

The DSDT from Comment #30 gives me also the same result as in Comment #15 !
-> Attaching for this dmesg2.log

But there seems still be a small error using new dsdt. When I go via hotkeys to
min brightness level, I've to press twive, to get one level up. After this, it works normally.

Hope this helps...
Comment 33 Conrad Kostecki 2009-06-04 16:45:31 UTC
Created attachment 21749 [details]
dmesg.log
Comment 34 Conrad Kostecki 2009-06-04 16:45:55 UTC
Created attachment 21750 [details]
dmesg2.log
Comment 35 Zhang Rui 2009-06-05 01:40:50 UTC
Created attachment 21758 [details]
customized DSDT

        Method (_BCM, 1, NotSerialized)
        {
            Store ("In _BCM", Debug)
            Store (Match (BCLP, MEQ, Arg0, MTR, 0x00, 0x00), Local0)
            If (LNotEqual (Local0, Ones))
            {
                Store (DerefOf (Index (BCLL, Local0)), \BRLV)
                \UCMS (0x16)
                \_SB.PCI0.LPC.EC.BRNS ()
            }
        }
Comment 36 Zhang Rui 2009-06-05 01:45:13 UTC
the DSDT above is quite like the one in comment #21.
I hope it still works for you.
Comment 37 Conrad Kostecki 2009-06-05 13:07:37 UTC
Hi!
I've tested new DSDT from Comment #35.

Results are the same as in Comment #32.
Comment 38 Zhang Rui 2009-06-08 02:48:30 UTC
Created attachment 21803 [details]
customized DSDT

well, there is only one difference between the previous DSDT and the original one.

so please try this DSDT and see if it acts like the original one.

        Method (_BCM, 1, NotSerialized)
        {
            Store ("In _BCM", Debug)
            Store (Match (BCLP, MEQ, Arg0, MTR, 0x00, 0x00), Local0)
            If (LNotEqual (Local0, Ones))
            {
                Store (DerefOf (Index (BCLL, Local0)), \BRLV)
                \_SB.PCI0.LPC.EC.BRNS ()
                \UCMS (0x16)
            }
        }
_BCM methods in the current DSDT.
Comment 39 Zhang Rui 2009-06-08 02:53:19 UTC
the original DSDT:
        Method (_BCM, 1, NotSerialized)
        {
            ...
                \_SB.PCI0.LPC.EC.BRNS ()
                \UCMS (0x16)
            ...
        }
the DSDT in comment #35
        Method (_BCM, 1, NotSerialized)
        {
            ...
                \UCMS (0x16)
                \_SB.PCI0.LPC.EC.BRNS ()
            ...
        }
let's see if this is the root cause of the problem.
Comment 40 Conrad Kostecki 2009-06-08 11:24:05 UTC
Hi!
I've now used your new DSDT.
Results are as in Comment #14 ...
Comment 41 Conrad Kostecki 2009-06-08 11:24:40 UTC
Ups, i mean Comment #4 !!! NOT #14
Comment 42 Zhang Rui 2009-06-17 03:33:03 UTC
well, it seems that the SMI (\UCMS) must be invoked BEFORE \_SB.PCI0.LPC.EC.BRNS()...
is there any new BIOS released? If yes, can you give it a try?
do you have a windows partition? can you verify if the problem exist in windows vista as well.

please boot with "acpi_backlight=vendor" and see if the thinkpad backlight control works on your laptop.
Comment 43 Conrad Kostecki 2009-06-17 20:43:12 UTC
Hi!

1) Is there any new BIOS released?
No, I've already the newest one.

2) Do you have a windows partition? can you verify if the problem exist in windows vista as well.
Yes, I've Windows Vista Ultimate SP2 x64 installed. The ACPI Brightness via Hotkeys is working here correctly and without any problems!

3) please boot with "acpi_backlight=vendor"
It didn't help. ACPI Hotkeys seems now to be dead.
Comment 44 Zhang Rui 2009-06-18 09:08:23 UTC
(In reply to comment #43)
> Hi!
> 
> 1) Is there any new BIOS released?
> No, I've already the newest one.
> 
> 2) Do you have a windows partition? can you verify if the problem exist in
> windows vista as well.
> Yes, I've Windows Vista Ultimate SP2 x64 installed. The ACPI Brightness via
> Hotkeys is working here correctly and without any problems!
> 
hah, then this is a Linux problem rather than a BIOS bug.

> 3) please boot with "acpi_backlight=vendor"
> It didn't help. ACPI Hotkeys seems now to be dead.

so /sys/class/backlight is empty?
please make sure CONFIG_THINKPAD_ACPI is set.
Comment 45 Conrad Kostecki 2009-06-18 16:42:55 UTC
(In reply to comment #44)
> hah, then this is a Linux problem rather than a BIOS bug.

So what now?

> so /sys/class/backlight is empty?
> please make sure CONFIG_THINKPAD_ACPI is set.

Kernel is compiled with CONFIG_THINKPAD_ACPI=y and booted with acpi_backlight=vendor. DMESG reports this also:

X200T / # dmesg |grep thinkpad_acpi
thinkpad_acpi: ThinkPad ACPI Extras v0.22
thinkpad_acpi: http://ibm-acpi.sf.net/
thinkpad_acpi: ThinkPad BIOS 7WET50WW (3.00 ), EC 7WHT15WW-1.02
thinkpad_acpi: Lenovo ThinkPad X200 Tablet, model 7450EQG
thinkpad_acpi: radio switch found; radios are enabled
thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode
thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
thinkpad_acpi: Standard ACPI backlight interface not available, thinkpad_acpi native brightness control enabled
thinkpad_acpi: detected a 16-level brightness capable ThinkPad

/sys/class/backlight is not empty according to ls:

X200T / # ls -la /sys/class/backlight/
total 0
drwxr-xr-x  2 root root 0 Jun 18  2009 .
drwxr-xr-x 36 root root 0 Jun 18  2009 ..
lrwxrwxrwx  1 root root 0 Jun 18  2009 thinkpad_screen -> ../../devices/virtual/backlight/thinkpad_screen

The Hotkeys for brightness seems to be dead. The only way now to use brightness is:

X200T / # echo up > /proc/acpi/ibm/brightness
X200T / # echo down > /proc/acpi/ibm/brightness
Comment 46 Zhang Rui 2009-06-19 03:43:10 UTC
well, the ACPI video control method behaves strangely in this laptop.
Henrique, can you verify if the thinkpad backlight and hotkeys work well on this laptop please?
Comment 47 Conrad Kostecki 2009-07-03 13:17:36 UTC
Hi!
Lenovo has released a new Bios 3.02. I flashed this, but it didn't helped...
Are any News on this?
Comment 48 Henrique de Moraes Holschuh 2009-07-06 13:41:22 UTC
Did /proc/acpi/ibm/brightness work perfectly, other than the fact that the hotkeys were dead?
Comment 49 Conrad Kostecki 2009-07-06 16:53:24 UTC
(In reply to comment #48)
> Did /proc/acpi/ibm/brightness work perfectly, other than the fact that the
> hotkeys were dead?

Yes :)
Comment 50 Henrique de Moraes Holschuh 2009-07-07 00:52:12 UTC
Argh. Ok, please attach dmidecode to this bug report (you already did the acpidump).  Remember to XXXX-out the UUID and serial numbers.

Also, in the future, please tag dmesg output as "text/plain", that makes my job a lot easier :)

How does the system behaves in *single user mode* (text console)?

Is anything messing with the thinkpad-acpi's hotkey_mask?  Please post the output of:

grep . /sys/bus/platform/devices/thinkpad_acpi/hotkey*

And also, a key point that is missing in the report:

What happens if you enable just the generic ACPI brightness control, WITHOUT thinkpad-acpi loaded?
Comment 51 Henrique de Moraes Holschuh 2009-07-08 02:18:29 UTC
Ok, I am looking at the DSDT, and the first thing I notice is that you have two new hotkeys in there I have never heard about, so please tell me if thinkpad-acpi has been complaining about unhandled HKEY events on the kernel log.

Now, back to this particular issue:

As usual with Lenovo DSDTs, when anyone first calls _BCL, it switches to ACPI-controlled brightness mode, by storing 1 to the \NBCF trapdoor.  Loading either thinkpad-acpi or ACPI video will do it.  After that, the brightness keys will _NOT_ do anything but cause ACPI events.

As you guys may have suspected, GPE _Q15 is hotkey brightness-down pressed, and _Q14 is the same for brightness-up.

Their handling is pretty normal, the same as it is done in all Lenovo Intel-based thinkpads, so I'd say you have a busted X.org or userspace if it is going weird on you.

Zhang-san, I suppose the ACPI brightness stuff in the DSDT was checked and it is sane?  If so, then we definately can blame userspace, X.org, or kernel DRI, or something in the OpRegion firmware.  Either that, or _ALL_ Lenovo thinkpads with Intel GPUs are broken, but I suppose we'd be getting a lot of reports if that was the case...

As for thinkpad-acpi, well, the DSDT will give me the events I need (HKEY 0x1010 and 0x1011), so I can send KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN to userspace.  Which is somewhat likely to screw up and not do what you want, but that's not something *I* can fix.

I will change the driver to report those input events when in vendor brightness mode on Lenovo thinkpads.
Comment 52 Henrique de Moraes Holschuh 2009-07-08 02:23:51 UTC
BTW, you can enable the KEY_BRIGHTNESS_<foo> reporting right now, just set the proper bits on the hotkey_mask AND remap scan codes 0x0F and 0x10 to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN on the thinkpad-acpi keymap using some userspace utility.  HAL can do that for you, and likely has already done so, since distros like to abuse that for on-screen-display.
Comment 53 Zhang Rui 2009-07-08 05:43:38 UTC
(In reply to comment #51)
> Now, back to this particular issue:
> 
> As usual with Lenovo DSDTs, when anyone first calls _BCL, it switches to
> ACPI-controlled brightness mode, by storing 1 to the \NBCF trapdoor.  Loading
> either thinkpad-acpi or ACPI video will do it.  After that, the brightness 
> keys will _NOT_ do anything but cause ACPI events.
> 
By reading the acpidump output, events are sent to both ACPI video device and Thinkpad hotkey devices HKEY, right?


> Zhang-san, I suppose the ACPI brightness stuff in the DSDT was checked and it
> is sane?

the customized DSDT works fine except one problem.
conrad, can you please make sure that, with customized DSDT
1. brightness switching always works fine when poking the sysfs I/F
2. the hotkey problem you described in comment #15 can always be reproduced
Comment 54 Henrique de Moraes Holschuh 2009-07-08 12:35:40 UTC
Yes, it sends events to both paths.

If you identify a bug in the DSDT, tell me about it and I will relay it to Lenovo.

But it looks like the problem is in the Linux stack for Intel GPU brightness control, here.  It could be the kernel (DRI), or userspace (X.org, HAL, udev, etc).  There is a minor chance of a bug in the BIOS, but since Windows works...
Comment 55 Zhang Rui 2009-07-09 01:17:31 UTC
(In reply to comment #54)
> Yes, it sends events to both paths.
> 
> If you identify a bug in the DSDT, tell me about it and I will relay it to
> Lenovo.
> 
Well, it's weird that backlight switching works much better in Linux if I exchange two AML lines. please refer to comment #39 and #42.
But as it works well in windows, I have no idea what the problem is.
Perhaps this bug has something to do with the difference between iasl and windows ASL compiler?
Comment 56 Conrad Kostecki 2009-07-15 20:48:27 UTC
Hi!
Sorry for delay, but i haven't got much time past the last days...
I've upgraded totay on Kernel 2.6.30 (gentoo-sources-2.6.30-r1)

It seems, that now Brightness Control works perfectly? No problems with hotkeys or brightness. o_O

I will do an test with 2.6.29 again for check.
Comment 57 Zhang Rui 2009-08-12 06:09:16 UTC
please re-open it if the problem still exists in the latest upstream kernel.
Comment 58 Len Brown 2009-09-24 21:39:07 UTC
commit de4c8cc7bddd9c43dc1b85517ab445ffa8163058
Author: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Date:   Sat Sep 12 15:22:18 2009 -0300

    thinkpad-acpi: report brightness events when required

shipped in Linux-2.6.31-git4 (pre 2.6.32-rc1)

Note You need to log in before you can comment on or make changes to this bug.