Bug 15054 - Brightness doesn't work on Acer Extensa 5220 -- DIDL not set properly
Summary: Brightness doesn't work on Acer Extensa 5220 -- DIDL not set properly
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Video (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Zhang Rui
URL:
Keywords:
: 14506 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-01-13 10:03 UTC by Philipp Überbacher
Modified: 2016-01-23 10:58 UTC (History)
7 users (show)

See Also:
Kernel Version: 2.6.32.3
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpidump output of this machine (206.56 KB, text/plain)
2010-01-13 10:11 UTC, Philipp Überbacher
Details
lspci output of this machine (2.26 KB, text/plain)
2010-01-13 10:15 UTC, Philipp Überbacher
Details
output of "grep . /sys/firmware/acpi/interrupts/*" (4.49 KB, text/plain)
2010-01-18 14:52 UTC, Philipp Überbacher
Details
output of "cat /proc/interrupts" (2.63 KB, text/plain)
2010-01-18 14:53 UTC, Philipp Überbacher
Details
dmesg before pressing Fn+brightness, with debug enabled in kernel and debug boot options (11.00 KB, application/octet-stream)
2010-01-26 21:42 UTC, Philipp Überbacher
Details
dmesg after pressing Fn+brightness, with debug enabled in kernel and debug boot options (11.08 KB, application/octet-stream)
2010-01-26 21:44 UTC, Philipp Überbacher
Details
/proc/acpi/video with default boot options (1.82 KB, text/plain)
2010-01-27 08:51 UTC, Philipp Überbacher
Details
/proc/acpi/video with nomodeset boot option (1.81 KB, text/plain)
2010-01-27 08:53 UTC, Philipp Überbacher
Details
dmesg with nomodeset boot option after pressing fn+brightness up/down (34.62 KB, text/plain)
2010-01-27 08:55 UTC, Philipp Überbacher
Details
patch: set DIDL using ACPI video device _ADR value (2.83 KB, patch)
2010-03-18 08:28 UTC, Zhang Rui
Details | Diff
output of: grep . /proc/acpi/video/*/*/* (1.81 KB, text/plain)
2010-03-19 16:49 UTC, Philipp Überbacher
Details
refreshed patch (2.68 KB, patch)
2010-03-22 08:52 UTC, Zhang Rui
Details | Diff
refreshed patch, output of: grep . /proc/acpi/video/*/*/* (1.81 KB, text/plain)
2010-03-22 11:17 UTC, Philipp Überbacher
Details
code to get input event (1.20 KB, patch)
2010-03-24 07:25 UTC, Zhang Rui
Details | Diff
output of "grep . /sys/class/input/input*/*" (4.62 KB, text/plain)
2010-03-27 12:56 UTC, Philipp Überbacher
Details
/dev/input/event1 with all 'special' keys pressed (10.89 KB, text/plain)
2010-03-27 13:06 UTC, Philipp Überbacher
Details

Description Philipp Überbacher 2010-01-13 10:03:30 UTC
Distribution is Arch Linux.

The brightness keys work up to grub, others not tested at the bios/grub level.
The brightness keys also work with acpi=off.

The keys are as follows:
seven special keys on the left (mail, whatever) -> no effect

Fn Keys, response and label: 
Fn numpad - works
Fn F1 - nothing, label: ?
Fn F2 - nothing, label: cake with a pie cut out?
Fn F3 - nothing, label: circle-like with a check mark inside
Fn F4 - nothing, label: Z with superscript z
Fn F5 - nothing, label: empty rectangle | filled rectangle
Fn F6 - seems to turn backlight off
Fn F7 - turns touchpad off/on (on with delay of ~1-2 sec.)
Fn F8 - nothing visible in alsamixer, label: speaker / speaker emitting sound
Fn F11 - numlock, label: Num
Fn F12  - nothing, not sure how to test, label: Rol
Fn UpArrow - nothing visible in alsamixer, label: louder
Fn DownArrow - nothing visible in alsamixer, label: quieter
Fn LeftArrow - nothing, label: filled sun (brightness down)
Fn RightArrow - nothing, label: empty sun (brightness up)

ls /sys/class/backlight/acpi_video0/
actual_brightness  bl_power  brightness  device  max_brightness  power  subsystem  uevent

poking as user root (not sudo) works:    echo 5 > /sys/class/backlight/acpi_video0/brightness

Please tell me what else you need, and thanks in advance for your help.
Comment 1 Philipp Überbacher 2010-01-13 10:11:52 UTC
Created attachment 24537 [details]
acpidump output of this machine
Comment 2 Philipp Überbacher 2010-01-13 10:15:02 UTC
Created attachment 24538 [details]
lspci output of this machine
Comment 3 Zhang Rui 2010-01-18 03:19:25 UTC
(In reply to comment #0)
> Distribution is Arch Linux.
> 
> The brightness keys work up to grub, others not tested at the bios/grub
> level.
> The brightness keys also work with acpi=off.
> 

> Fn LeftArrow - nothing, label: filled sun (brightness down)
> Fn RightArrow - nothing, label: empty sun (brightness up)

the brightness keys are controlled via ACPI.
So we will only look at these two Fn keys in this bug report. 

> 
> ls /sys/class/backlight/acpi_video0/
> actual_brightness  bl_power  brightness  device  max_brightness  power 
> subsystem  uevent
> 
> poking as user root (not sudo) works:    echo 5 >
> /sys/class/backlight/acpi_video0/brightness
> 
good. The backlight sysfs I/F is working for you.

please attach the output of "cat /proc/interrupts" and "grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the Fn keys.
Comment 4 Philipp Überbacher 2010-01-18 14:52:20 UTC
Created attachment 24620 [details]
output of "grep . /sys/firmware/acpi/interrupts/*"
Comment 5 Philipp Überbacher 2010-01-18 14:53:58 UTC
Created attachment 24621 [details]
output of "cat /proc/interrupts"
Comment 6 Philipp Überbacher 2010-01-18 14:55:13 UTC
HTH, thanks for looking into it.
Comment 7 Zhang Rui 2010-01-26 07:50:48 UTC
please rebuild your kernel with CONFIG_ACPI_DEBUG set.
and boot with "acpi.debug_layer=0x04 acpi.debug_level=0x08000004",
and then attach the dmesg output after pressing the hotkey for several times and attach the dmesg output
Comment 8 Philipp Überbacher 2010-01-26 21:42:18 UTC
Created attachment 24737 [details]
dmesg before pressing Fn+brightness, with debug enabled in kernel and debug boot options
Comment 9 Philipp Überbacher 2010-01-26 21:44:05 UTC
Created attachment 24738 [details]
dmesg after pressing Fn+brightness, with debug enabled in kernel and debug boot options
Comment 10 Zhang Rui 2010-01-27 03:34:08 UTC
please try boot option "nomodeset" and
1. attach the output of "grep . /proc/acpi/video/*/*/*" both with and without this kernel paramter.
2. attach the dmesg output after pressing hotkeys.
Comment 11 Philipp Überbacher 2010-01-27 08:51:02 UTC
Created attachment 24742 [details]
/proc/acpi/video with default boot options
Comment 12 Philipp Überbacher 2010-01-27 08:53:27 UTC
Created attachment 24743 [details]
/proc/acpi/video with nomodeset boot option

tty looked weird, low resolution, strange characters..
Comment 13 Philipp Überbacher 2010-01-27 08:55:50 UTC
Created attachment 24744 [details]
dmesg with nomodeset boot option after pressing fn+brightness up/down

brightness keys did have effect
Comment 14 Zhang Rui 2010-02-25 05:42:35 UTC
(In reply to comment #13)
> Created an attachment (id=24744) [details]
> dmesg with nomodeset boot option after pressing fn+brightness up/down
> 
> brightness keys did have effect

I see.
On some HP laptops, DIDL is required to be initialized before _DOD is invoked, thus we add the code to initialize DIDL in i915_opregion.c.
And now, on this laptop, it seems that the AML code in _DOD method
1. check if DIDL is initialized or not
2. If yes, follow the initialized value
3. If no, initialize DIDL in the AML code.

The problem is that
1. the graphics driver initialized DIDL value can not work on this laptop.
2. According to the spec, SBIOS(AML code) should not write to the DIDL field at all. Only the graphics driver can set this field...

IMO, this is a firmware bug, not sure if we should workaround it in the Linux/kernel,
Comment 15 Zhang Rui 2010-02-26 02:41:59 UTC
A detailed description about how the AML code works on this laptop.

1. DIDL/DDL2/DDL3/... these are the DIDL field defined in IGD Opregion, and they should have been initialized before _DOD is invoked.

2. DID1/DID2/DID3/... these are defined in the ACPI NVS region, and I suspect these fields are initialized by BIOS, as an indicator of the ACPI video output device type.

Here is how _DOD works,

1. if DIDL have been initialized, check the value in DIDL. If it doesn't conflict with the value in DID1 (DIDL == And (DID1, 0x0F0F)), set a meaningful value to DID1 (new value equals Or(0x80000000, And (DID1, 0x0F0F))). Or else, clear DID1.
And the same for DID2/DID3...

2. If DIDL is cleared, go to step 3.

3. use the values in DID1/DID2/DID3... to set the _DOD return package.

So if we want to set DIDL before invoking _DOD and make everything work, we need to set the DIDL carefully, which means we should make clear the output type of every ACPI video output device (DD01/DD02/...) and set the correct DIDL value(not conflict with the value in DID1/DID2/...) in correct ORDER...

Or else, just leave the DIDL field uninitialized, at least before invoking _DOD.
Comment 16 Zhang Rui 2010-02-26 02:46:03 UTC
(In reply to comment #15)
> So if we want to set DIDL before invoking _DOD and make everything work, we
> need to set the DIDL carefully, which means we should make clear the output
> type of every ACPI video output device (DD01/DD02/...) and set the correct
> DIDL
> value(not conflict with the value in DID1/DID2/...) in correct ORDER...
> 
It seems that this can be done in this was:.
evaluating the _ADR of each output device, and set the DIDL value based on the device id got from _ADR.

Not sure if this is a reasonable solution.
Comment 17 Zhang Rui 2010-03-09 09:18:45 UTC
As discussed in the irc, I'm going to generate a patch to initialize the DIDL field in ACPI device order.
Comment 18 Zhang Rui 2010-03-18 08:28:20 UTC
Created attachment 25580 [details]
patch: set DIDL using ACPI video device _ADR value

please apply this patch and boot with KMS enabled and see if the problem still exists.
please attach the output of "grep . /proc/acpi/video/*/*/*" after boot.
Comment 19 Philipp Überbacher 2010-03-18 14:37:26 UTC
I applied the patch to kernel 2.6.33.1 with KMS enabled and also CONFIG_ACPI_DEBUG and some new acpi debug thing enabled and booted it normally. At the point where it switches to the native resolution I just got a blank screen, and it stayed that way.

2.6.33 works for me in general, I can use 2.6.33-rt7 with KMS without issues.

Is something wrong with the patch or could it be that the enabled debug options are interfering?
Comment 20 Zhang Rui 2010-03-19 01:42:19 UTC
(In reply to comment #19)
> I applied the patch to kernel 2.6.33.1 with KMS enabled and also
> CONFIG_ACPI_DEBUG and some new acpi debug thing enabled and booted it
> normally.
> At the point where it switches to the native resolution I just got a blank
> screen, and it stayed that way.
> 
what does "switches to the native resolution" mean?
does the system hang at this time, or there is just no output in the screen?

> 2.6.33 works for me in general, I can use 2.6.33-rt7 with KMS without issues.
> 
do you mean the hotkey also works?
If yes, please attach the output of "grep . /proc/acpi/video/*/*/*" in 2.6.33 kernel.
Comment 21 Philipp Überbacher 2010-03-19 11:40:40 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > I applied the patch to kernel 2.6.33.1 with KMS enabled and also
> > CONFIG_ACPI_DEBUG and some new acpi debug thing enabled and booted it
> normally.
> > At the point where it switches to the native resolution I just got a blank
> > screen, and it stayed that way.
> > 
> what does "switches to the native resolution" mean?

Usually when I boot the displayed font is big until I guess KMS kicks in, the fonts are smaller and it all looks a lot nicer.

> does the system hang at this time, or there is just no output in the screen?

It's hard to say.. there was some cpu activity but without seeing anything I don't know.

> > 2.6.33 works for me in general, I can use 2.6.33-rt7 with KMS without
> issues.
> > 
> do you mean the hotkey also works?
> If yes, please attach the output of "grep . /proc/acpi/video/*/*/*" in 2.6.33
> kernel.

It works there because I disable acpi when running rt kernels.

I'll rebuild .33.1 with those debug options disabled and try again.
Comment 22 Philipp Überbacher 2010-03-19 16:49:33 UTC
Created attachment 25615 [details]
output of: grep . /proc/acpi/video/*/*/*

This time I got more lucky (I disabled acpi debuggung and tracing).
The kernel booted normally, the buttons did not work. Attached is the requested output.
Comment 23 Zhang Rui 2010-03-22 08:52:51 UTC
Created attachment 25637 [details]
refreshed patch

please try this refreshed patch and see if it helps.
please attach the output of "grep . /proc/acpi/video/*/*/*" after applying this patch.
Comment 24 Philipp Überbacher 2010-03-22 11:17:46 UTC
Created attachment 25640 [details]
refreshed patch, output of: grep . /proc/acpi/video/*/*/*

I applied the refreshed patch to 2.6.33.1, the output of grep . /proc/acpi/video/*/*/* is attached. The brightness keys worked.
Thanks a lot for looking into this. Tell me if there's more I can assist with.
Comment 25 Felix Geyer 2010-03-22 21:02:05 UTC
This patch also fixes the brightness keys on Dell Vostro 1320.
Previously they only worked when booting with nomodeset.
Comment 26 Zhang Rui 2010-03-23 07:07:02 UTC
good news.
I'll send it to the public mail list to see if this can be taken by upstream kernel.
Comment 27 Philipp Überbacher 2010-03-23 08:54:30 UTC
Very nice that it helps others as well.

Does the patch affect other fancy buttons in some way? I didn't try yet.
Should I open new reports for those?

Again, thanks for your help.
Comment 28 Zhang Rui 2010-03-23 09:06:26 UTC
(In reply to comment #27)
> Very nice that it helps others as well.
> 
> Does the patch affect other fancy buttons in some way?

they should not affect the other hotkey.

> I didn't try yet.
> Should I open new reports for those?
> 
no, you don't. :)

> Again, thanks for your help.
Comment 29 Philipp Überbacher 2010-03-23 09:36:28 UTC
Well, if they don't do anything either I should, right? I only have to find a reliable way to figure out whether they do something or not since they may simply not be hooked up to anything.
Comment 30 Felix Geyer 2010-03-23 13:30:06 UTC
I just noticed that with this patch two XF86MonBrightnessDown / XF86MonBrightnessUp key events are emitted on the Dell Vostro 1320; the brightness is only changed by one step though.
Without the patch only one key event is emitted.
Comment 31 Zhang Rui 2010-03-24 07:19:21 UTC
(In reply to comment #29)
> Well, if they don't do anything either I should, right? 

Sorry, I misread your comment.
please open a new bug report for the other hotkey issues.
I'm not sure what category they should be but they're apparently not ACPI issues. :p
Comment 32 Zhang Rui 2010-03-24 07:25:40 UTC
Created attachment 25672 [details]
code to get input event

please first attach the output of "grep . /sys/class/input/input*/*".

and then, build do this test,
1. gcc read-input-event.c
2. sudo ./a.out /dev/input/eventX (X = {0, 1, ..., the maximum number in /dev/inpout })
3. press the hotkey
4. watch if there is any output when pressing the hotkey, if yes, please attach the output together with the value of X.
Comment 33 Philipp Überbacher 2010-03-27 12:56:51 UTC
Created attachment 25729 [details]
output of "grep . /sys/class/input/input*/*"
Comment 34 Philipp Überbacher 2010-03-27 13:06:19 UTC
Created attachment 25730 [details]
/dev/input/event1 with all 'special' keys pressed

Thanks a lot.
It seems everything is working, every key emitting some signal on /dev/input/event1 exclusively. Some are hooked up to something, others aren't, but that's all fine.

There's a single exception:
Fn+F6 doesn't emit a signal, but it turns off the backlight completely. This works even with the unpatched kernel and acpi on, so I guess it's something even lower level, similar to backlight off when the lid gets closed.

Thanks a lot for your help, and good luck with getting the patch upstream :)
Comment 35 Zhang Rui 2010-03-29 01:42:37 UTC
Felix,

If the problem still exists, please file new bug report, together with the test result requested in comment #32.
Comment 37 Radek Pilar 2010-03-29 08:21:30 UTC
*** Bug 14506 has been marked as a duplicate of this bug. ***
Comment 38 Felix Geyer 2010-03-31 21:11:54 UTC
(In reply to comment #35)
> Felix,
> 
> If the problem still exists, please file new bug report, together with the
> test
> result requested in comment #32.

I opened a new bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=15662

Please let me know if you need additional information.
Comment 39 Len Brown 2010-09-29 02:32:12 UTC
commit 3143751ff51a163b77f7efd389043e038f3e008e
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Mon Mar 29 15:12:16 2010 +0800

    drm/i915: set DIDL using the ACPI video output device _ADR method return.

shipped in v2.6.34-rc4-159-g3143751
closed

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