Bug 25922

Created attachment 41922 [details]
dmesg

Created attachment 41932 [details]
lsmod

please attach the acpidump output of this laptop.

(In reply to comment #0)
> After increasing/decreasing brightness by "Fn+Up/Down" it changes by some
> value
> and after that keys are not responding (not making any change).
>
I'm not quite clear about the problem.
do you mean the hotkey works well at the beginning, but then it doesn't work any more.
question: when the keys are not responding, do you see the value change in /sys/class/backlight/acpi_video0/actual_brightness?
and do you see the value change when the keys are still working?

Oh, as this is a regression, could you please verify if reverting 39fe394d05be43481ceac8b3db19dfd5189097f6 helps?

Yes, the hotkey works only once. For example the value changes from initial "4" to "5" and then isn't changing anymore. 
Reverting drivers/acpi/video.c didn't helped, but reverting the file drivers/platform/x86/ideapad-laptop.c to the state from commit 2016e4a0a1c49b68c9d820e28dadab7080c45d1b (it was ideapad_acpi.c then) makes it working again.
I didn't tried later patches, so I don't know which commit brakes it.

seems this is a platform driver regression. :)

What does that mean? How will it be resolved?

Could you try it again after "rmmod ideapad_laptop"? In the mean time, I will see see if I miss anything when initial ideapad-laptop.

And the acpidump output will be helpful.

Removing module doesn't help. I must blacklist it to prevent loading at start, then keys are working again. Maybe this is related to https://bugzilla.kernel.org/show_bug.cgi?id=23402 . It's the same machine.

Created attachment 47112 [details]
acpidump

Created attachment 48542 [details]
ideapad-y530.patch

Hi,

I go through the DSDT but can not find anything interested me.

If you have to blacklist it to prevent this bug happened, it shall be something when module initial. There are only two kind of ACPI methods when initial, the _CFG and those probe for rfkill status methods.

Please try the attached patch. It will not run _CFG when initial and assume wifi and BT are present. It shall help me telling which part cause regression.

Thanks a lot.

This patch fixes it.

Patch: https://bugzilla.kernel.org/attachment.cgi?id=48542

That doesn't seem like an ideal solution. Exposing rfkill devices that don't exist in hardware will confuse userspace, so we do ideally need to figure out why _CFG is breaking brightness control and continue to call it.

Hi Matthew,

This is not a solution. Just help me figure out which DSDT method cause the problem.

Ok - in that case can you leave it as assigned rather than resolved? Thanks!

Ignore-Patch: https://bugzilla.kernel.org/attachment.cgi?id=48542

Created attachment 48702 [details]
0001-ideapad-read-brightness-setting-when-have-brightness.patch

Please take a try on this patch. This patch shall fix this issue and wont affect other ideapads. I have tried on ideapad B550 and S10-3, nothing different. Once the patch is confirmed working, I believe it is ok for upstream kernel.

Yes it's working.
Thanks.

https://patchwork.kernel.org/patch/584191/

Patch is sent to mailing list for reviewing

Patch : https://patchwork.kernel.org/patch/584191/
Handled-By : Ike Panhc <ikepanhc@gmail.com>

Ignore-Patch : https://patchwork.kernel.org/patch/584191/
Patch : https://bugzilla.kernel.org/attachment.cgi?id=48702

A patch referencing this bug report has been merged in v2.6.38-9043-gc585015:

commit 883ae7992c09435927dda642b61f1455fceb5b85
Author: Ike Panhc <ike.pan@canonical.com>
Date:   Wed Feb 23 21:39:59 2011 +0800

    ideapad: read brightness setting on brightness key notify

A patch referencing this bug report has been merged in v2.6.38-9043-gc585015:

commit 2165136585b5c7d6f118f1d90fbde550bb7de212
Author: Ike Panhc <ike.pan@canonical.com>
Date:   Wed Feb 23 21:39:59 2011 +0800

    ideapad: read brightness setting on brightness key notify