Bug 12021

Summary: Fn + brightness up/down keys doesn't work if ACPI enabled - Samsung NC10
Product: Drivers Reporter: Alain Tavan (alain57)
Component: Input DevicesAssignee: drivers_input-devices
Status: CLOSED CODE_FIX    
Severity: normal CC: andrea.cimitan, bugzilla, dmitry.torokhov, elkrammer, fedora, jan.skowron, nathanael.schaeffer, penny, remi, rockclimb, stuart, thoemy, vorione
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.27-8-generic Subsystem:
Regression: No Bisected commit-id:
Bug Depends on:    
Bug Blocks: 56331    
Attachments: acpidump of samsung nc10
cat /proc/interrupts
cat /proc/interrupts after key press
grep . /sys.... before
grep . /sys.... after
result from cat /proc/interrupts before
result from cat /proc/interrupts after one press
grep . /sys/firmware/acpi/interrupts/* before
grep . /sys/firmware/acpi/interrupts/* after
gnome-power-manager verbose
the xrandr -verbose output
Patch for atkbd to fix key repeat issue on NC10
Scancodes for the NC10
Patch for atkbd to fix key repeat issue on NC10 (take 2)

Description Alain Tavan 2008-11-13 10:35:15 UTC
Latest working kernel version: don't know i have the netbook since 1 week
Earliest failing kernel version: 2.6.27-8-generic
Distribution: Ubuntu 8.10
Hardware Environment:
Samsung NC10 netbook
lspci : 
00:00.0 Host bridge: Intel Corporation Mobile 945GME Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
02:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller (rev 13)


Software Environment:
Problem Description:
On this laptop some function keys are BIOS-controlled (they work before Linux
boots).

As soon as Linux boots they stop working. Trying some boot options I've found
that "acpi=off" makes them work
after checking dmesg and /usr/include/linux/input.h i fixed them with
setkeycodes e008 225
setkeycodes e009 224

BUT, in graphical mode it makes the keyboard freeze (i need to switch to CRTL + ALT + F1 and then CTRL + ALT +F7 to make it unfreeze)
AND it brings down the brightness at 0%
or brings up the brithness at 100%
it did not stop, even if i'm no more pressing the key



because it is a netbook i can't loose acpi (i can't see the batterie status) and the processor is at 100% speed not very good to spare batterie life


I killed acpid and try a "cat /proc/acpi/event" but it didn't show anything after pressing the brightness button

the directory /sys/class/backlight is empty
Comment 1 Zhang Rui 2008-11-13 17:22:56 UTC
please attach the acpidump output.

please attach the output of "grep . /sys/firmware/acpi/interrupts/*" and "cat /proc/interrupts" both before and after pressing the hotkey for ONE time.
Comment 2 Alain Tavan 2008-11-14 00:23:16 UTC
Created attachment 18861 [details]
acpidump of samsung nc10
Comment 3 Alain Tavan 2008-11-14 00:36:41 UTC
Created attachment 18862 [details]
cat /proc/interrupts
Comment 4 Alain Tavan 2008-11-14 00:37:36 UTC
Created attachment 18863 [details]
cat /proc/interrupts after key press
Comment 5 Alain Tavan 2008-11-14 00:38:30 UTC
Created attachment 18864 [details]
grep . /sys.... before
Comment 6 Alain Tavan 2008-11-14 00:39:14 UTC
Created attachment 18866 [details]
grep . /sys.... after
Comment 7 Alain Tavan 2008-11-14 00:40:55 UTC
sorry i pressed the brightness key more than one, if you want i do the upload again
Comment 8 Alain Tavan 2008-11-14 00:46:35 UTC
Created attachment 18867 [details]
result from cat /proc/interrupts before
Comment 9 Alain Tavan 2008-11-14 00:47:14 UTC
Created attachment 18868 [details]
result from cat /proc/interrupts after one press
Comment 10 Alain Tavan 2008-11-14 00:49:52 UTC
Created attachment 18869 [details]
grep . /sys/firmware/acpi/interrupts/* before
Comment 11 Alain Tavan 2008-11-14 00:50:17 UTC
Created attachment 18870 [details]
grep . /sys/firmware/acpi/interrupts/* after
Comment 12 Alain Tavan 2008-11-14 00:51:11 UTC
now i pressed only one time the key between before and after of the grep and cat command
Comment 13 Alain Tavan 2008-11-14 02:46:59 UTC
i forgot to say, the brightness work without problem on console mode (CTRL ALT F1 for exemple), it's only buggy on graphical interface.

i found something, don't know if its helpfull, when i increase or decrease the brightness and press the UP key just after, the level stop increasing or decreasing ... like the key release was not readed before, 
and now that i press UP it's readed ...
but the other problem with loosing the keyboard is still there
Comment 14 Alain Tavan 2008-11-14 02:54:22 UTC
Created attachment 18872 [details]
gnome-power-manager verbose

i killed gnome-power-manager and run it this way
gnome-power-manager --no-daemon --verbose
i pressed the decrease button ONCE and then the increase button ONCE (because the brightness was at 0%)
then i switch to console and back in graphic mode (because i loose the keyboard) and killed gnome-power-manager
maybe this verbose help, at least i hope so
Comment 15 ykzhao 2008-11-16 16:47:20 UTC
Hi, Alain
    From the acpidump it seems that there is no _BCM/_BCL object, which is required for the backlight interface(/sys/class/backlight/acpi_video*/*).
    From the interrupt info in comment #10 and #11 it seems that no ACPI interrupt is triggered after hotkey is pressed. Maybe the backlight is controlled by BIOS instead of OS.
    Thanks.
Comment 16 Zhang Rui 2008-11-16 18:34:15 UTC
please attach the result of "xrandr --verbose".
what can you see following the BACKLIGHT_CONTROL line?
There are four modes inall, and try some other modes and see if it helps.
e.g. you can set it to native mode by running "xrandr --output LVDS --set BACKLIGHT_CONTROL native".
Comment 17 Alain Tavan 2008-11-17 02:29:48 UTC
Created attachment 18886 [details]
the xrandr -verbose output
Comment 18 Alain Tavan 2008-11-17 02:33:54 UTC
i tried all 4 modes
with native its uglier because the screen blink 

with the 3 other, the problem is still the same, brightness decrease or increase at maximum and i loose the keyboard :(
Comment 19 Zhang Rui 2008-11-17 17:49:10 UTC
hmm, this seems like a graphics bug rather than Linux/ACPI problem.

because,
1. no ACPI interrupts when pressing the hotkey, nor ACPI backlight control methods. thus brightness control is not via ACPI.

2.(In comment #13) "i forgot to say, the brightness work without problem on console mode (CTRL ALT F1 for exemple), it's only buggy on graphical interface."

Alain, I can not help you on this problem, you may want to open a bug at bugs.freedesktop.org, reference this bug report there and cc me. :)

cc Jesse.
Comment 20 Alain Tavan 2008-11-18 01:40:41 UTC
ok i will try my luck there ^^
i just thought that is was an acpi bug because when i disable acpi with acpi=off on grub there where no bug
Comment 21 Alain Tavan 2008-12-03 06:18:42 UTC
hi again, at Xorg they closed the bug report saying it was a kernel bug...
what should i do ?
Comment 22 Riccardo Persichetti 2008-12-10 15:08:44 UTC
i'm also getting the problem described here. if anyone is interested this is bugs.freedesktop.org entry: https://bugs.freedesktop.org/show_bug.cgi?id=18590
Comment 23 Zhang Rui 2008-12-10 17:08:09 UTC
hah, I see,
first of all, the hotkey event is sent to i8042 controller.
second, the keyboard driver doesn't generate the correct input layer key event, i.e. it doesn't generate the key release event, which results in the malfunction of X.
Comment 24 Zhang Rui 2008-12-10 17:11:08 UTC
re-assign this bug to the keyboard experts :)
Comment 25 Alain Tavan 2008-12-11 00:12:26 UTC
Thank you for your support Zhang Rui

ps: i updated the bios, funilly now in X, only the brightness down work( like before ! with bug)
the brightess up doesn't do anything :(

so i recommand everyone not updating bios...
Comment 26 Andrew Ross 2008-12-13 14:43:01 UTC
Yeah, I'm pretty sure it's the lack of a release event. In /drivers/input/keyboard/atkbd.c there is already some support for dealing with this - I'm trying the same thing on the NC10 - it's compiling now, so I'll let you know how I get on and let you have my changes.
Comment 27 Stuart Hopkins 2008-12-13 17:36:51 UTC
Hi, i've emailed a patch to Dmitry that fixes the key repeat issue, so that they can now be used correctly. This now allows for ACPID scripts to be used to control things properly.

Hopefully this can make it into the mainline soon
Comment 28 Stuart Hopkins 2008-12-13 17:37:58 UTC
Created attachment 19285 [details]
Patch for atkbd to fix key repeat issue on NC10
Comment 29 Thomas Wendt 2008-12-14 05:28:17 UTC
(In reply to comment #28)
>+      const unsigned int forced_release_keys[] = {
>+              0x82, 0x83, 0x84, 0x86, 0xb1, 0xb3, 0xf9,
>+      };

I'm sure you also want 0x88 and 0x89 for brightness up and down.
Also 0xb3 for Fn + F8. 
Fn + F10 produces 0xf9 if you turn the touchpad off and 0xf7 if you turn it back on.
Fn+F7 (0xb1) emits a key released event so it's not needed.

The complete list would then be: 0x82, 0x83, 0x84, 0x86, 0x88, 0x89, 0xb3, 0xf7, 0xf9,
Comment 30 Stuart Hopkins 2008-12-14 09:41:16 UTC
I'm wondering if the codes differ between mine and yours. I added the ones in the patch as those were the ones repeating to infinity (as some of them were not). 

0xb3 is already in the list of forced released keys, as are the brightness ones on mine. I now have my brightness working fine, using the patch and then
  scancodes e008 225
  scancodes e009 224
At least on Ubuntu this then gives the system control of the brightness and usability of the keys.

The trackpad button on mine doesn't seem to generate an event, it just works out of the box for the enable/disable. 

I will boot an unpatched kernel in a minute and double check the values that I have for the keys
Comment 31 Stuart Hopkins 2008-12-14 10:10:51 UTC
I've just checked again and noted down all of the keycodes and the results. I posted the wrong patch (sorry) which missed off the brightness scancodes. It worked on mine as I had them added. 

Should be two attachments below, one listing the scancodes, and a new patch.

You were right about 0xb1, it doesn't need to be there as it doesn't repeat.
Comment 32 Stuart Hopkins 2008-12-14 10:12:16 UTC
Created attachment 19300 [details]
Scancodes for the NC10

Scancodes for the NC10
Comment 33 Stuart Hopkins 2008-12-14 10:19:16 UTC
Created attachment 19301 [details]
Patch for atkbd to fix key repeat issue on NC10 (take 2)
Comment 34 Thomas Wendt 2008-12-14 10:22:52 UTC
Okay, got the same results.
Comment 35 Riccardo Persichetti 2008-12-16 03:51:17 UTC
it took me almost one month to come to the same conclusion as your. Only difference is you got it in a few minutes.. ;) anyway, patch does work on my Samsung NC10. Thanks a lot for your support.
Comment 36 Alain Tavan 2008-12-16 05:28:47 UTC
does someone know wenn this patch is going to be merged in kernel ?

i also search for a .config with all drivers in kernel an only a few modules (for usb devices for exemple) if anyone has it can you please be so kind to share it ?

and Thanks for resolving this bug :)
Comment 37 Adam Wilkosz 2008-12-22 14:05:56 UTC
I can't get brightness control to work.

Kpowersave says there is no brightness control. I tried debian kernel 2.6.26 vanilla 2.6.27.10 2.6.28-rc9.
lshal -m shows:
platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up

same with brightness-down. Kpowerdevil in kde4.2 beta2 has possibility to change brightness, but notghing happens.

Brighthess control works only when I disable acpi, but I'm wondering how people using ubuntu have possibility to conntrol brightness.

On 2.6.28-rc9-git1 
cat /proc/acpi/video/DD0*/brightness 
shows <not supported>

I have latest hal-info, but I think it doesn't metter. Just afer i start kernel i'm loosing ability to use fn keys brightness control.

I can send more debug info, but tell me what do you need.

Kind regards,
Adam
Comment 38 Andrea Cimitan 2008-12-28 04:51:17 UTC
works in fedora with gnome, seems a bug in your kde then
Comment 39 Nathanael Schaeffer 2008-12-28 06:27:35 UTC
Hi everybody,

The array of fixed scancodes that need forced release code do work BUT it is not as general as it could be.

What if we could add an option to "setkeycodes" say "-force-up" to inform the kernel that for this specific key, an release scancode should automatically be sent ?

This would allow everyone dealing with such an issue to handle non-standard keys.

And thanks for the patch, I was about to write something myself, yous saved me time !
Comment 40 Alain Tavan 2009-01-10 06:02:56 UTC
there is still a little bug
indeed this patch correct the release event...
but if you press the brightness down buttom a long time ( 3 seconds) for turning brightness to 0, unfortunatly after that brightness up and brightness down don't work anymore ...
Comment 41 Thomas Wendt 2009-01-18 06:23:27 UTC
(In reply to comment #40)
> there is still a little bug
> indeed this patch correct the release event...
> but if you press the brightness down buttom a long time ( 3 seconds) for
> turning brightness to 0, unfortunatly after that brightness up and brightness
> down don't work anymore ...
> 
I don't experience this problem. This is on Fedora 10 with a Fedora 2.6.28-2 kernel.
Comment 42 Jiri Kosina 2009-01-19 02:12:46 UTC
*** Bug 12237 has been marked as a duplicate of this bug. ***
Comment 43 Grégory SCHMITT 2009-01-24 11:00:28 UTC
Addtional information:
- I don't experience this problem either. Everything works fine with me. Maybe a latency case ?

- Bios update 04CA seems to fix the issue of repeating keypress, making patch useless. Anyone to confirm ?
Comment 44 Andrea Cimitan 2009-01-24 11:26:18 UTC
(In reply to comment #43)
> Addtional information:
> - I don't experience this problem either. Everything works fine with me.
> Maybe
> a latency case ?
> 
> - Bios update 04CA seems to fix the issue of repeating keypress, making patch
> useless. Anyone to confirm ?
> 

I can confirm, updating the bios fixes the problem also on vanilla kernels without patches
Comment 45 Grégory SCHMITT 2009-01-24 11:47:07 UTC
I think we may close this bug then. Update to bios 04CA fixes the issue, no need for an extra patch to enter kernel.
Comment 46 Alain Tavan 2009-01-24 11:50:59 UTC
funny
# dmidecode -s bios-version
04CA.MP00.20081211.KTW

and still with doing only a 
setkeycode e009 224
setkeycode e008 225

and the bug is still there ...
Comment 47 Fortunato Ventre 2009-01-24 12:54:39 UTC
(In reply to comment #46)
> funny
> # dmidecode -s bios-version
> 04CA.MP00.20081211.KTW
> 
> and still with doing only a 
> setkeycode e009 224
> setkeycode e008 225
> 
> and the bug is still there ...
> 

Same here, on Ubuntu 8.10 with latest available kernel from proposed repository (2.6.27-11.25).
Comment 48 Fortunato Ventre 2009-01-24 13:01:24 UTC
(In reply to comment #40)
> there is still a little bug
> indeed this patch correct the release event...
> but if you press the brightness down buttom a long time ( 3 seconds) for
> turning brightness to 0, unfortunatly after that brightness up and brightness
> down don't work anymore ...
> 

I'm experiencing the same problem.
When brightness is to 0, pressing one more time fn-down makes both fn-up and fn-down stop working.
Instead, if brightness is to max level, pressing one more time fn-up causes no problem at all.
Comment 49 Alain Tavan 2009-01-24 13:20:32 UTC
hum ok with modifing the hal fdi (or adding the one gregory send me) no patch is needed whereas with setkeycode it still bugs ... 

ps : i don't think that an other fdi file is needed at least not for the brightness keys

indeed /usr/share/hal/fdi/information/10freedesktop/30-keymap-misc.fdi already has a samsung line
we only need to modify the line 103 and modify
SP55S;SQ45S70S;SX60P into SP55S;SQ45S70S;SX60P;NC10

now i saw only ONE difference for the e002 key
in the fdi gregory gave me it was switchvideomode whereas on original 30-keymap-misc it was displaytoggle


ok it worked, let just hope that no future bios make that worse

BUT, like i said in comment nr 40
when you pressed (and keep pressing) the brightness down for 5 seconds (or more) screen goes totaly black, but brightness up don't turn it on again :( so be carreful
Comment 50 Grégory SCHMITT 2009-01-24 14:09:49 UTC
Quick comments:

- I sent an email to a HAL developer to see if the keymap for the Samsung laptops needs to be adjusted with other keycodes, especially displaytoggle and switchvideomode.

- I am using Fedora 10 (without the GNOME power management daemon, but with another HAL manager called ivman), with bios 04CA and vanilla kernel 2.6.28.1 unpatched. Brightness keys don't bounce at all (key press and key release), and reaching minimum/maximum brightness with the keys don't block brightness, i.e I still can increase/decrease brightness. It might be another bug related to gnome. Do we have any KDE users here?
Comment 51 Fortunato Ventre 2009-01-25 03:44:03 UTC
Brightness keys restart to work if gnome session is restarted, so it has to be a gnome bug.
Comment 52 Alain Tavan 2009-01-25 07:31:16 UTC
i would say a gnome-power-manager bug
indeed i use xfce, and its default hal handler is gnome-power-manager

this is fun, because on jaunty (ok still alpha3) they had the stupid idea of disabling the control alt backspace function ...
how can i restart xfce easyly ?!?

ok i could do control alt f2
login
sudo
...
kill x

all with a dark screen hum well its a bit much ...
but well ok, his not your problem here :)
Comment 53 Grégory SCHMITT 2009-01-25 08:15:25 UTC
Check your xorg.conf, option "DontZap". And please check with gnome-power-manager people.
Comment 54 Alain Tavan 2009-01-25 09:36:25 UTC
for those interested i opened a bug report on gnome 
http://bugzilla.gnome.org/show_bug.cgi?id=569100
Comment 55 Andrea Cimitan 2009-01-28 07:12:40 UTC
I was wrong.
I still have the issue with an updated bios. I was just using the 2.6.29rc2 from fedora, which seems ok (but suspend doesn't work...).
I'm just wondering what's wrong now, since all we said about the bios upgrade was wrong.

Please REOPEN
Comment 56 Fortunato Ventre 2009-01-28 08:04:37 UTC
On Ubuntu 8.10, even with latest bios update and fixed .fdi file for hal, I
still have to patch the kernel to fix the issue.

Because of the latest comments here, I thought that the issue had been
addressed with a newer hal.
Comment 57 Andrea Cimitan 2009-01-28 08:24:20 UTC
I've tested with kernel 2.6.28.1 by fedora.
The keys doesn't reproduce but then the keyboard becomes unresponsive.
It is fixed with 2.6.29rc2 from fedora rawhide, I don't think they used patches.
Comment 58 Fortunato Ventre 2009-01-28 10:14:15 UTC
Just tested latest ubuntu jaunty kernel (based on 2.6.28.2) on my intrepid installation and the issue is here yet. Keys repeat and keyboard hangs.

Comment #49 reported that the issue was fixed in jaunty with just a modified hal .fdi file. Can this be confirmed?

If so, I can only think that a newer hal version fixes the issue, but I'm unable to test it right now.
Comment 59 Alain Tavan 2009-01-28 12:03:18 UTC
sorry i did a mistake, i patched my kernel and forgot it
i confirm that the bios DON'T help
Comment 60 Fortunato Ventre 2009-01-30 18:24:00 UTC
Ok, just checked latest vanilla kernel sources (2.6.29-rc3) and the patch has been merged, so... mistery solved. :P

I think this bug can be closed now, there is not too much to discuss here yet :)
Comment 61 Andrea Cimitan 2009-01-30 18:34:34 UTC
but that is not an elegant way to fix those issues... do we really need to add that custom code for every single laptop that has this bug? it's quite sad imho.
Comment 62 Fortunato Ventre 2009-01-30 18:50:20 UTC
I admit it, I was wrong, there would be a LOT to discuss here actually :)

In my opinion what was proposed in Comment #39 would be a nice and definitive solution to the problem. However, I really don't know how much work and how many changes that would imply.
Comment 63 JanS 2009-08-29 18:27:48 UTC
(In reply to comment #61)
> but that is not an elegant way to fix those issues... do we really need to
> add
> that custom code for every single laptop that has this bug? it's quite sad
> imho.

It is not elegant at all. Mayby slightly more elegant will be to add one fix for all Samsung laptops, as it seems MANY of their models, if not all, have this issue with not sending key-release events (from the lecture of Fedora and Ubuntu bugzillas). And, in case one or two laptops do sent key-release in a proper way, I think that sending additional key-release should not be an issue..?

Solution presented in Comment #39 is very nice and elegant. I vote for it!

In fact, there is a Bug 14052 which tries to summarize this general issue with Samsung laptops and tries to advertise this "--force-up" option solution.

I hope someone will be working on this.
Comment 64 Dmitry Torokhov 2009-09-01 17:20:21 UTC
This bug concerns NC10 only and since the code is in the kernel I am closing it. Please try the patch in 14052 for the more general solution.