Will you please attach the output of acpidump, lspci -vxxx on your box?

thanks.

Created attachment 25143 [details]
lspci -vxxx output

these logs aren't from a live running 2.6.33 as reported in the bug; they're from 2.6.31-20-generic (ubuntu)

Created attachment 25144 [details]
acpidump output

please attach the output of "grep . /sys/bus/acpi/drivers/*/*/path".

Created attachment 25165 [details]
grep . /sys/bus/acpi/drivers/*/*/path output

same as before, from 2.6.31-20-generic

this bug is marked as a regression.
please indicate the latest kernel version that worked properly
dmesg from that kernel may be helpful as well.

i started doing just that when i saw the metablock mail; 2.6.32.8 doesn't do it, 2.6.33-rc1 does

this regression is probably introduced by commit 1caab3c1a90be3aa4ec3599409d8fe044b077478
could you please verify if the problem still exists after this patch is reverted?

or you can just blacklist the wmi.ko driver and see if the problem still exists.

BTW: in order to blacklist the wmi.ko, you need to
1.open /etc/modprobe.d/blacklist.conf file
2.add this line in the file: blacklist wmi.ko
3.reboot.

yea; that was it, it didn't revert cleanly but acpi_wmi_init returning -ENODEV
did the trick

oof i only saw the last comment when i tried to post this reply; that sure would have been easier than what i did :> (but at least i know the process and have .33 oackages i can actually use now)

thanks for your time

It seems that it's this piece of AML code in _PSR method that changes the backlight.

                            If (Local1)
                            {
                                Store (0x03, ^^^^^WMID.EVID)
                                Store (Zero, ^^^^^WMID.EVDT)
                                Notify (^^^^^WMID, 0x80)
                                Store (One, ACST)
                            }
                            Else
                            {
                                Store (Zero, ACST)
                            }

Carlos,
do you know what it means?
As the notification 0x80 is not handled by ACPI wmi driver, do you think 
                                Store (0x03, ^^^^^WMID.EVID)
                                Store (Zero, ^^^^^WMID.EVDT)
changes the backlight?

do you think this is a AML code problem and a kernel bug?

This appears to be specific to when the wmi driver is loaded.
Indeed, I expect that it still happens when the ACPI "video"
driver is not present, is that true?

i couldn't remove the acpi video driver to test; as it was already in use, and the only module with wmi in the name on this computer is hp_wmi, and it indeed stops doing it when its removed (as if i had did what i did in comment #10)

as part of trying to re-enliven my card reader without a reboot; i modprobe'd hp_wmi on 2.6.31-20-generic (ubuntu) and it exhibited the same backlight behaviour as reported on .33

Carlos and Matthew,
any comments on this?

my touchpad disable key and brightness keys haven't worked since comment #14 :\

Can I get some clarification here, because I'm having trouble parsing the previous comments - does this bug happen when hp-wmi is unloaded but with wmi still loaded? Because blacklisting wmi also stops hp-wmi loading, so doesn't tell me anything useful.

I'd be more suspicious that it's a bug with hp-wmi doing the wrong thing with the event being triggered here - EVID and EVDT seem to be being used only for _WED (which is used to provide additional information for events).

Huh. Event 3 used to mean "Brightness down". Let me look into this some more.

Ah, Carlos is entirely correct - the use of the same table for two different purposes has caught me out. I'll work on a patch.

Created attachment 25461 [details]
Test patch

This ought to fix it...

do you mean the hp-wmi driver should not handle the brightness up/down events?

I know little about wmi/hp-wmi, is it possible that a platform doesn't follow ACPI video extension but routes the hotkey events via the wmi stuff?

Note that in this BIOS, the notification is sent from the _PSR method, which doesn't make sense to me.
We should send such events when AC is plugged/unplugged, but never when reading the AC status, right?

The brightness up/down events don't appear to be sent by any hardware I can find. I believe that it was specific to legacy machines that didn't expose the backlight via ACPI, but in that case we can't do anything with the events anyway. In this case, the hardware is actually sending event 0x4 with extended information of 0x3, which is separate but difficult to separate due to the way I implemented hp-wmi originally. I've no idea why the ahrdware is sending an event in that case, but we should be able to just ignore it.

okay, I see.

bugzillakernelorg@lez.ath.cx

please re-open this bug if the patch in comment #20 doesn't fix the problem for you.

i've tried the patch; but #16 is still happening, and it happens even with the "stable" kernel (2.6.31-20-generic) i normally use, after i modprobe'd hp_wmi on that same kernel, i literally loaded it once and it has not worked since

the other soft buttons that used to work correctly now are malfunctioning as well (like Fn+F4 sending Meta+L???), if anyone has any pointers on how to restore the original operation i would appreciate it, as it survives reboots and i have no idea where it could have kept record of this change

agh sorry for the noise but i forgot to put this in my last post; this is what dmesg says for my touchpad disable button since it broke

[  111.745759] atkbd serio0: Unknown key pressed (translated set 2, code 0xd8 on isa0060/serio0).
[  111.745765] atkbd serio0: Use 'setkeycodes e058 <keycode>' to make it known.
[  111.752206] atkbd serio0: Unknown key released (translated set 2, code 0xd8 on isa0060/serio0).
[  111.752211] atkbd serio0: Use 'setkeycodes e058 <keycode>' to make it known.

the other keys just seem dead or send weird stuff (as mentioned for Fn+F4)

i really miss my touchpad disable button; if anyone has any idea of what i can do to restore it, or where to look to do so, i'd appreciate it

ping Matthew...

Try the "reset to defaults" option in your BIOS.

thanks for the suggestion, i tried that to no avail; i'm on freenode and can be contacted at this email address if anyone wants to help troubleshoot; i can't rule out my distro but i have no idea where to even start looking

hope this isn't bad form; copied comment i made on another bug (https://bugzilla.kernel.org/show_bug.cgi?id=15895)

...

> further, my brightness keys have been broken for a while, sending wrong
> keysyms; and have been since:
> https://bugzilla.kernel.org/show_bug.cgi?id=15344, and as alluded to in the
> first post
> 
> i'd _really_ like to fix my keysyms, before the hp_wmi thing it was sending
> the
> right keysyms for all the extra keys, it hasn't since; is this sort of thing
> permanent? i also downgraded my bios checked functionality (was still broke)
> and then upgraded it again in the spirit of comment #28 on #15344 after that
> suggestion failed, and that also failed.
> 
> i'm glad to report and troubleshoot bugs but if its going to break my laptop
> i'll be sad :[

which was just yesterday; which means my laptop is still dinged

(In reply to comment #28)
> Try the "reset to defaults" option in your BIOS.

I got around to seeing what happens in windows wrt the now broken keys; they still work as expected.

this is a weird one; its doing it again with 2.6.35-6-generic (from kernel-ppa/ppa ppa for ubuntu)

my touchpad is still broke too :[

upgraded to ubuntu 10.10 beta which includes this kernel; problem still exists

> my touchpad is still broke too :[
I have a patch series pending which should fix that. Hopefully I can send the stuff soon, possibly the next days.

What is the ETA for these? 2.6.37-rc1 or 2.6.38?

Is this still an issue in 2.6.37?

Thomas, did your patch series land? Do you have a pointer to it?

Closing this now as unreproducible.