Bug 13368

Created attachment 21505 [details]
dmesg output

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.

please attach the output of both
"grep . /proc/acpi/video/*/*/brightness"
"grep . /sys/class/backlight/*/*"

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...

Created attachment 21538 [details]
hotkey_event

Created attachment 21539 [details]
"grep . /proc/acpi/video/*/*/brightness"

Created attachment 21540 [details]
"grep . /sys/class/backlight/*/*"

Created attachment 21541 [details]
acpidump

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?

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.

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.

Created attachment 21582 [details]
customized DSDT: with more debug info

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.

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.

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!

Created attachment 21586 [details]
messages1.log

Created attachment 21587 [details]
messages2.log

I am sorry for my last post, copy & paste messed a litte bit up...

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.

(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.

Created attachment 21682 [details]
customized DSDT: don't invoke \UCMS (0x16)

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...

Created attachment 21697 [details]
customized DSDT: works exactly the same as before

please try this one, which should work exactly the same as before.

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.

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

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

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?

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.

Created attachment 21741 [details]
customized DSDT: dsdt that should work well

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 ()
            }
        }

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.

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...

Created attachment 21749 [details]
dmesg.log

Created attachment 21750 [details]
dmesg2.log

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 ()
            }
        }

the DSDT above is quite like the one in comment #21.
I hope it still works for you.

Hi!
I've tested new DSDT from Comment #35.

Results are the same as in Comment #32.

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.

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.

Hi!
I've now used your new DSDT.
Results are as in Comment #14 ...

Ups, i mean Comment #4 !!! NOT #14

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.

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.

(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.

(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

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?

Hi!
Lenovo has released a new Bios 3.02. I flashed this, but it didn't helped...
Are any News on this?

Did /proc/acpi/ibm/brightness work perfectly, other than the fact that the hotkeys were dead?

(In reply to comment #48)
> Did /proc/acpi/ibm/brightness work perfectly, other than the fact that the
> hotkeys were dead?

Yes :)

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?

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.

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.

(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

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...

(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?

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.

please re-open it if the problem still exists in the latest upstream kernel.

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)