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.

Created attachment 18861 [details]
acpidump of samsung nc10

Created attachment 18862 [details]
cat /proc/interrupts

Created attachment 18863 [details]
cat /proc/interrupts after key press

Created attachment 18864 [details]
grep . /sys.... before

Created attachment 18866 [details]
grep . /sys.... after

sorry i pressed the brightness key more than one, if you want i do the upload again

Created attachment 18867 [details]
result from cat /proc/interrupts before

Created attachment 18868 [details]
result from cat /proc/interrupts after one press

Created attachment 18869 [details]
grep . /sys/firmware/acpi/interrupts/* before

Created attachment 18870 [details]
grep . /sys/firmware/acpi/interrupts/* after

now i pressed only one time the key between before and after of the grep and cat command

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

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

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.

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".

Created attachment 18886 [details]
the xrandr -verbose output

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 :(

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.

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

hi again, at Xorg they closed the bug report saying it was a kernel bug...
what should i do ?

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

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.

re-assign this bug to the keyboard experts :)

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...

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.

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

Created attachment 19285 [details]
Patch for atkbd to fix key repeat issue on NC10

(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,

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

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.

Created attachment 19300 [details]
Scancodes for the NC10

Scancodes for the NC10

Created attachment 19301 [details]
Patch for atkbd to fix key repeat issue on NC10 (take 2)

Okay, got the same results.

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.

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 :)

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

works in fedora with gnome, seems a bug in your kde then

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 !

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 ...

(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.

*** Bug 12237 has been marked as a duplicate of this bug. ***

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 ?

(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

I think we may close this bug then. Update to bios 04CA fixes the issue, no need for an extra patch to enter kernel.

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 ...

(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).

(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.

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

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?

Brightness keys restart to work if gnome session is restarted, so it has to be a gnome bug.

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 :)

Check your xorg.conf, option "DontZap". And please check with gnome-power-manager people.

for those interested i opened a bug report on gnome 
http://bugzilla.gnome.org/show_bug.cgi?id=569100

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

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.

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.

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.

sorry i did a mistake, i patched my kernel and forgot it
i confirm that the bios DON'T help

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 :)

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.

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.

(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.

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.