Bug 15054
|
Description
Philipp Überbacher
2010-01-13 10:03:30 UTC
Created attachment 24537 [details]
acpidump output of this machine
Created attachment 24538 [details]
lspci output of this machine
(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. Created attachment 24620 [details]
output of "grep . /sys/firmware/acpi/interrupts/*"
Created attachment 24621 [details]
output of "cat /proc/interrupts"
HTH, thanks for looking into it. 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 Created attachment 24737 [details]
dmesg before pressing Fn+brightness, with debug enabled in kernel and debug boot options
Created attachment 24738 [details]
dmesg after pressing Fn+brightness, with debug enabled in kernel and debug boot options
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. Created attachment 24742 [details]
/proc/acpi/video with default boot options
Created attachment 24743 [details]
/proc/acpi/video with nomodeset boot option
tty looked weird, low resolution, strange characters..
Created attachment 24744 [details]
dmesg with nomodeset boot option after pressing fn+brightness up/down
brightness keys did have effect
(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, 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. (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. As discussed in the irc, I'm going to generate a patch to initialize the DIDL field in ACPI device order. 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.
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? (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. (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. 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.
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.
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.
This patch also fixes the brightness keys on Dell Vostro 1320. Previously they only worked when booting with nomodeset. good news. I'll send it to the public mail list to see if this can be taken by upstream kernel. 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. (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. 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. 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. (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 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.
Created attachment 25729 [details]
output of "grep . /sys/class/input/input*/*"
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 :)
Felix, If the problem still exists, please file new bug report, together with the test result requested in comment #32. patch in comment #23 is sent to intel-gfx@lists.freedesktop.org. please refer to http://lists.freedesktop.org/archives/intel-gfx/2010-March/006405.html *** Bug 14506 has been marked as a duplicate of this bug. *** (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. 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 |