Bug 11939

Summary:	MSI WIND and brightness change works crappy
Product:	Drivers	Reporter:	Artur Szymczak (artur.szymczak)
Component:	Input Devices	Assignee:	Zhang Rui (rui.zhang)
Status:	CLOSED PATCH_ALREADY_AVAILABLE
Severity:	normal	CC:	acpi-bugzilla, artur.szymczak
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.27	Subsystem:
Regression:	---	Bisected commit-id:
Bug Depends on:
Bug Blocks:	56331
Attachments:	acpidump dmidecode 1. a single shot of the hotkey, which doesn't change the backlight. - BEFORE 1. a single shot of the hotkey, which doesn't change the backlight. - AFTER 2. hold the hotkeys 3-5 seconds which does change the backlight. - BEFORE 2. hold the hotkeys 3-5 seconds which does change the backlight. - AFTER 1. before single shot 1. after single shot 3. before brightness change 4. after brightness change

Description Artur Szymczak 2008-11-02 02:49:32 UTC

Latest working kernel version:
none known

Earliest failing kernel version:
Distribution:
Arch Linux

Hardware Environment:
MSI WIND U100

Software Environment:
Problem Description:

When I want change brightness using Fn+F4 (down) or Fn+F5 (up) it works crappy. It means that, I must hold this key combination 3-5 seconds to work, or hit it several times. This bug exist in vanilla 2.6.27 and Arch Linux 2.6.27, but in Ubuntu 8.10 kernel it works correctly, as expected.
When I use kernel from Ubuntu on Arch Linux it works.
I recompiled vanilla kernel with ubuntu config, but it doesn't work.

Changing brigtness using "echo xx > /proc/acpi/video/IGD/LCD/brightness" works correctly on all kernels (Vanilla, Arch, Ubuntu, Fedora)


Steps to reproduce:
- install/run distro: Arch Linux / Fedora 9
- try change brightness using Fn+F4/F5

Comment 1 ykzhao 2008-11-02 19:05:52 UTC

Will you please attach the output of acpidump, dmidecode?
Do you mean that the system can work well if using the proc interface to change the brightness but the system will crash when hotkey is used?

Thanks.

Comment 2 Zhang Rui 2008-11-02 19:36:57 UTC

hmmm, ACPI backlight I/F works well, that's good news.

please run "grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the hotkeys and attach the test result here.
Note that you may want to do this test twice,
1. a single shot of the hotkey, which doesn't change the backlight.
2. hold the hotkeys 3-5 seconds which does change the backlight.

And please kill acpid before pressing the hotkey and see if the backlight can be changed successfully.:)

Comment 3 Artur Szymczak 2008-11-02 22:26:28 UTC

Created attachment 18607 [details]
acpidump

Comment 4 Artur Szymczak 2008-11-02 22:27:11 UTC

Created attachment 18608 [details]
dmidecode

Comment 5 Artur Szymczak 2008-11-02 22:27:46 UTC

(In reply to comment #1)
> Will you please attach the output of acpidump, dmidecode?
> Do you mean that the system can work well if using the proc interface to
> change
> the brightness but the system will crash when hotkey is used?
> 

No. If I'm using proc all works correct. If I us hotkey, sometimes it works sometimes not. No crash :)

Comment 6 Artur Szymczak 2008-11-02 22:36:18 UTC

(In reply to comment #2)

Changing brightness without acpid running is same.

Comment 7 Artur Szymczak 2008-11-02 22:37:42 UTC

Created attachment 18609 [details]
1. a single shot of the hotkey, which doesn't change the backlight.  - BEFORE

Comment 8 Artur Szymczak 2008-11-02 22:38:05 UTC

Created attachment 18610 [details]
1. a single shot of the hotkey, which doesn't change the backlight.  - AFTER

Comment 9 Artur Szymczak 2008-11-02 22:38:42 UTC

Created attachment 18611 [details]
2. hold the hotkeys 3-5 seconds which does change the backlight. - BEFORE

Comment 10 Artur Szymczak 2008-11-02 22:39:02 UTC

Created attachment 18612 [details]
2. hold the hotkeys 3-5 seconds which does change the backlight. - AFTER

Comment 11 Zhang Rui 2008-11-03 00:12:32 UTC

weird, no ACPI events even the backlight is changed, which means that hotkey events are not handled by ACPI.
could you please re-do the test in comment #2, but run "cat /proc/interrupts" instead. :)

Comment 12 Artur Szymczak 2008-11-03 01:07:43 UTC

Created attachment 18613 [details]
1. before single shot

Comment 13 Artur Szymczak 2008-11-03 01:08:50 UTC

Created attachment 18614 [details]
1. after single shot

Comment 14 Artur Szymczak 2008-11-03 01:09:38 UTC

Created attachment 18615 [details]
3. before brightness change

Comment 15 Artur Szymczak 2008-11-03 01:10:02 UTC

Created attachment 18616 [details]
4. after brightness change

Comment 16 Artur Szymczak 2008-11-03 01:16:21 UTC

What I observed:
I watched /proc/interrupts using: watch -n0.1 cat /proc/interrupts
when hotkey doesnt change brightness, 1: (i8042) doesn't change counter, but when I succesfull change brightness using hotkeys this counter has been changed.

Comment 17 Zhang Rui 2008-11-03 16:51:22 UTC

well, I'm not sure, but I don't think this is an ACPI bug.
because the hotkey events are not sent to ACPI, but i8042 instead.

so the problem is that no i8042 interrupt when pressing the hotkey, right?

Comment 18 Artur Szymczak 2008-11-03 23:37:44 UTC

On Ubuntu kernel (where all works fine), when I use hotkeys in /proc/interrupts are changed:
1: (i8042)
9: (acpi)

So I dont know. Also in /sys/firmware/acpi/interrupts counters are changed when I press hotkeys.

Ubuntu or Debian changed something in kernel and it's works (hotkeys).

Comment 19 Zhang Rui 2008-11-04 00:20:42 UTC

so ACPI can receive hotkey events in Ubuntu/Debian kernel?
that's weird.
what's the kernel version of Ubuntu 8.0?
It would be great if you can try some earlier vanilla kernel to see if this is a regression

Comment 20 Artur Szymczak 2008-11-04 01:50:29 UTC

Ok,
I will try make a test in earlier kernels. Ubuntu has 2.6.27 kernel (2.6.27-7-generic).

Comment 21 Artur Szymczak 2008-11-05 03:27:06 UTC

Ok, I tested kernels from 2.6.10 to 2.6.27 and kernel 2.6.27-rc3.
10-17 works.
18-19 doesn't change brightness at all.
20-25 works same as in 10-17.
26 - same as 27 (here is _regression_)
BUT this bug is fixed in 2.6.28-rc3 :)))))