Most recent kernel where this bug did not occur: don't know? Distribution: Fedora 7 Hardware Environment: Compaq Evo N620c (Laptop) Software Environment: KDE Desktop Problem Description: After unplugging the A/C from the Laptop, Display Brightness turns to 50% and is hardly readable. There seems no way to turn it on again. Likely because it isn't supported by acpi? This happens also with the most recent Fedora 7 update kernel 2.6.23.1-10.fc7. There is no way to configure it through BIOS. Steps to reproduce: $ for i in /proc/acpi/video/*/*/brightness; do cat $i;done <not supported> <not supported> <not supported> <not supported>
It seems that no brightness control is available on your laptop. Is there any chance that you can run Windows on this laptop to see if there is any difference? Please attach the acpidump output.
Created attachment 13413 [details] acpidump output Unfortunately there is no Microsoft Windows on the system, so it can't be checked. Though I presume brightness control should be possible with Microsoft Windows, as there is a Fn + F10 key with a small sun on the F10 key.
does the backlight up/down hotkey work on your laptop, if there is any? (the brightness can also be controlled by the bios instead of acpi) does this still happen if you kill acpid before unplugging the A/C? (user space may listen to this event and switch the brightness level via other tools, like xrandr, etc) is there any difference if you echo 5 > /proc/acpi/video/C0D1/DOS before unpluging the A/C? (although no brightness control available via acpi, D0S can be used to disable/enable the auto brightness switching when plugging/unplugging A/C according to the ACPI spec.)
The backlight hotkey (Fn +F10) doesn't produce any 'xev' output. Unfortunately there is no way inside the BIOS to change any settings concerning display brightness. I can only stop hald, which has a hald-addon-acpi which listens to /proc/acpi/event, though it makes no difference. "echo 5 > /proc/acpi/video/C0D1/DOS before unpluging the A/C?" makes no difference at all, unfortunately.
Please check if ACPI is responsible for the Fn+F10 hotkey events. Watch the number of ACPI interrupts shown in /proc/interrupts. Make sure it increases everytime you press the Fn+F10 key. You can also do this test: dmesg -c; echo 0x04 >/sys/module/acpi/parameters/debug_layer echo 0x8800001f > /sys/module/acpi/paramters/debug_level press the Fn+F10 hotkey for several times and attach the dmesg output. we should get some useful information if Fn+F10 hotkey events are routed to ACPI.
Created attachment 13434 [details] dmesg output Is see no raise in /proc/interrupts concerning acpi. Though the second test (dmesg output) seems to see something, even if "hald-addon-acpi" segfaults as seen in dmesg output attachment.
>I see no raise in /proc/interrupts concerning acpi. That's weird. From the dmesg you attached, some ACPI interrupts do occur when pressing Fn+F10. could you please set the same debug mask in comment #5, kill hald, cat /proc/acpi/event, and see what happened when you press Fn+F10 and plug/unplug the AC? Attaching the result of "cat /proc/acpi/event" and dmesg would be good. > There seems no way to turn it on again. xrandr may work for you in X. could you please give a try?
The following is from 'cat /proc/acpi/event' ac_adapter C1B5 00000080 00000000 processor CPU0 00000080 00000000 thermal_zone TZ1 00000081 00000000 ac_adapter C1B5 00000080 00000001 processor CPU0 00000080 00000000 thermal_zone TZ1 00000081 00000000 battery C1B3 00000080 00000001 ac_adapter C1B5 00000080 00000000 processor CPU0 00000080 00000000 thermal_zone TZ1 00000081 00000000 ac_adapter C1B5 00000080 00000001 processor CPU0 00000080 00000000 thermal_zone TZ1 00000081 00000000 battery C1B3 00000080 00000001 battery C1B3 00000080 00000001 It seems just plugging und unplugging the A/C is recorded, but not pressing Fn+F10 at all? This is from dmesg: evevent-0249 [00] ev_fixed_event_detect : Fixed Event Block: Enable 00000120 Status 00000011 evgpe-0444 [00] ev_gpe_detect : Read GPE Register at GPE0: Status=00, Enable=01 evgpe-0444 [00] ev_gpe_detect : Read GPE Register at GPE8: Status=00, Enable=00 evgpe-0444 [00] ev_gpe_detect : Read GPE Register at GPE10: Status=7D, Enable=83 evgpe-0444 [00] ev_gpe_detect : Read GPE Register at GPE18: Status=00, Enable=38 evmisc-0143 [00] ev_queue_notify_reques: Dispatching Notify(80) on node dfc50df8 evmisc-0151 [00] ev_queue_notify_reques: Notify value: 0x80 **Device Specific** evmisc-0143 [00] ev_queue_notify_reques: Dispatching Notify(80) on node dfc560d8 evmisc-0151 [00] ev_queue_notify_reques: Notify value: 0x80 **Device Specific** evmisc-0143 [00] ev_queue_notify_reques: Dispatching Notify(81) on node dfc4ea98 evmisc-0151 [00] ev_queue_notify_reques: Notify value: 0x81 **Device Specific** evevent-0249 [00] ev_fixed_event_detect : Fixed Event Block: Enable 00000120 Status 00000011 evgpe-0444 [00] ev_gpe_detect : Read GPE Register at GPE0: Status=00, Enable=01 evgpe-0444 [00] ev_gpe_detect : Read GPE Register at GPE8: Status=00, Enable=00 evgpe-0444 [00] ev_gpe_detect : Read GPE Register at GPE10: Status=7D, Enable=83 evgpe-0444 [00] ev_gpe_detect : Read GPE Register at GPE18: Status=00, Enable=38 Tried xrandr and xbacklight with both the radeon driver and the ati driver to no available. Strange enough as user it tells me: $ xbacklight -set 30 No outputs have backlight property While as root: # xbacklight -set 30 RandR version 1.1 too old # rpm -qf /usr/bin/xrandr xorg-x11-server-utils-7.2-1.fc7 # xrandr --version Server reports RandR version 1.1 So I might have a slight chance with a newer xrandr version? Unsure if this requires also a newer XServer?
In order to try a newer xrandr, you need to upgrade your Xserver. I'm not a X expert and I only know that xrandr 1.2 works well with intel graphics card driver, but I'm not sure if xrandr 1.2 can work for you. :( For the hotkey issue, comment #6 says no ACPI interrupts when pressing Fn+F10. But the dmesg attached indicates that GPE 0x11 keeps on firing. So could you please resend the dmesg output with debug mask after pressing Fn+F10 for 3 times? Please clear the dmesg log before the test.
Created attachment 13476 [details] new dsdt It's clear that the backlight can not be changed via ACPI video device. If it's not the users that change the backlight while unplugging AC. It's probably changed by the BIOS. Can you try to override the DSDT and see if there is any difference? I delete a piece of AML code that may call BIOS to change the backlight.
Did upgrade to Fedora 8, with new xrandr, but still no cigar no matter if ati or radeon X driver. The kernel compiled with your DSDT file loaded fine: "ACPI: Table DSDT replaced by host OS" Unfortunately no change in backlight switching to about 50% of brightness after A/C plug. ;( I got zero output from dmesg using the above method with pressing Fn+F10. Sadly I have to send the machine away tomorrow, kind of gift. So I have no more access for unknown time to the machine. Many thanks for all your help! Michael
There are two problems in all. 1. brightness is turned down to 50% when unplugging AC. 2. can't switch the brightness back, either via hotkey or user space tools. >Unfortunately no change in backlight switching to about 50% of brightness >>after A/C plug. ;( It's about the problem 1. I'm not sure which piece of code changes the backlight. :( Does this still happen in console mode? Any there any bios options related to backlight switch while unplugging AC? Is there any difference if you boot with acpi_os_name="Microsoft Windows"? >I got zero output from dmesg using the above method with pressing Fn+F10. Problem 2. This means the hotkey events are not routed to ACPI. So I can't help you on this problem any more. >So I have no more access for unknown time to the machine. Well, at least I can close this bug and mark it as UNREPRODUCIBLE so that the number of ACPI unresolved bugs can be reduced. :) Please confirm whether you can access the laptop or not. :)
Exactly. I do not have access to the hardware right now and it's unlikely I'll get one of those again. Thx again for your help! Michael
Hi, I do have 2 Compaq Evo N620c laptops and had the same issues. Because I just stumpled upon the solution to this problem, here's the solution: The brightness is controlled by the BIOS. You have to press Fn + F10 + <left> or <right> to control the brightness. Regards, Patrick
important info, patrick. I think we can close it now.