Bug 18590

I can confirm the same behavior. If you need any information please let me know.

This sounds like the keys are busted somehow. Please attach the xev log when you press the matching keys.If you can, also get a copy of evtest (e.g. http://people.freedesktop.org/~whot/evtest.c) and run it against the device and attach the log here (also press the brightness keys)

Created attachment 20662 [details]
the xev log after changing brightness

Created attachment 20663 [details]
evtest grab in console mode

in console (CTRL + ALT + F1) it give me these events

i did it with (as root)
./evtest /dev/input/event1


in X evtest did not work,my next attachement will be the output of X

Created attachment 20664 [details]
evtest grab in X

like promised, here is the output of evtest in X

> --- Comment #4 from Alain Tavan <alain57@gmail.com>  2008-11-28 06:26:46 PST ---
> Created an attachment (id=20663)
>  --> (http://bugs.freedesktop.org/attachment.cgi?id=20663)
> evtest grab in console mode

This looks a lot like https://bugzilla.redhat.com/show_bug.cgi?id=444440
If the keys don't send key release events properly, you the server will
autorepeat into oblivion. 

I'm not so sure about RedHat Bug 444440 because for that user "showkey -s" seems to show an endless sequence of key presses, which doesn't happen here. Maybe I'm missing a subtlety.

RedHat Bug 460237 however (which Peter links to in above bug report) has identical symptoms to this issue on the NC10. They had the same problem with the volume up/down keys on a Zepto 6615WD laptop.

Here is my output on the NC10 (Ubuntu Intrepid 2.6.27-9-generic), in text mode, of showkey -s.

Single press of brightness up (Fn + Up):
0xe0 0x54

Single press of brightness down (Fn + Down):
0xe0 0x4c

For comparison, a single press of the volume up key combo (Fn + Right), which works perfectly, produces:
0xe0 0x30 0xe0 0xb0

So I'd concur that a key release event is not being received for the brightness keys.

What is the solution? I'm having trouble seeing how they fixed it for the Zepto 6615 in that Fedora kernel update.

A link to that RedHat Bug 460237 with near identical symptoms:
https://bugzilla.redhat.com/show_bug.cgi?id=460237

(In reply to comment #7)
> I'm not so sure about RedHat Bug 444440 because for that user "showkey -s"
> seems to show an endless sequence of key presses, which doesn't happen here.
> Maybe I'm missing a subtlety.

nothing exciting, just if the device reports consecutive key presses the server will fake releases in between. If the device doesn't report a release the server starts autorepeating after a certain timeout.

> What is the solution? I'm having trouble seeing how they fixed it for the Zepto
> 6615 in that Fedora kernel update.

Sorry, the solution is to fix the kernel, this shouldn't be hacked around in X. 

(In reply to comment #9)
> Sorry, the solution is to fix the kernel, this shouldn't be hacked around in X. 
> 
hum okay,  but why does it work correctly outside of X ?
in console mode (CTRL + ALT + F1 for exemple) there is no endless brightness whereas in X there is :(

this is endless :(
i first opened a bug at kernel.org where i was told to try here...
and now i'm told to report it to kernel.org again ......
who is wrong ?!?

do you have a reference to the kernel.org bug?

so the problem is that endless key presses reported in X?

(In reply to comment #9)
> > What is the solution? I'm having trouble seeing how they fixed it for the Zepto
> > 6615 in that Fedora kernel update.
> 
> Sorry, the solution is to fix the kernel, this shouldn't be hacked around in X. 
> 
hmmm, which part should be fixed?
input layer? there is no ACPI event when the hotkey is pressed, and it's that it's the keyboard driver that can catch this event.

(In reply to comment #13)
> so the problem is that endless key presses reported in X?

the problem is that the hardware never reports a key release - resulting in autorepeats forever.


Alain: I just checked all attached files again, and this it what it looks like. There may be something we can do, depending on the reported event. However, I need to ask you to reproduce both logs again and attach the full log in both cases.

xev: make sure it is focused and the cursor is inside the window before you hit the brightness key.

evtest: do it without X running, and attach the full log after hitting each key once, with a key press of enter in between.

(In reply to comment #12)
> do you have a reference to the kernel.org bug?
> 

yes, the first post : http://bugzilla.kernel.org/show_bug.cgi?id=12021

(In reply to comment #13)
> so the problem is that endless key presses reported in X?
> 
> (In reply to comment #9)
> > > What is the solution? I'm having trouble seeing how they fixed it for the Zepto
> > > 6615 in that Fedora kernel update.
> > 
> > Sorry, the solution is to fix the kernel, this shouldn't be hacked around in X. 
> > 
> hmmm, which part should be fixed?
> input layer? there is no ACPI event when the hotkey is pressed, and it's that
> it's the keyboard driver that can catch this event.
> 

thank you for helping , i was afraid nobody will help us(the nc10 users) :)

(In reply to comment #14)
> (In reply to comment #13)
> > so the problem is that endless key presses reported in X?
> 
> the problem is that the hardware never reports a key release - resulting in
> autorepeats forever.
> 
> 
> Alain: I just checked all attached files again, and this it what it looks like.
> There may be something we can do, depending on the reported event. However, I
> need to ask you to reproduce both logs again and attach the full log in both
> cases.
> 
> xev: make sure it is focused and the cursor is inside the window before you hit
> the brightness key.
> 
> evtest: do it without X running, and attach the full log after hitting each key
> once, with a key press of enter in between.
> 
okay i will try what you asked as fast as possible
thank you for your help
all the samsung NC10 user are hopping this problem will be resolved soon :) 

Created attachment 20806 [details]
evtest without X

i kill X as root with the command "killall5"
then i run evtest and did a
brightness down
enter
brightness up

but i can not give a full log, because there seems to be a problem
when a do a "evtest /dev/input/event1 | tee logfile"

i have not a complet logfile... like the evtest software stop working... (see next attachment)

so i needed to copy/paste the last lines in a file :(

Created attachment 20807 [details]
the evtest logfile when trying to log the complete output using "tee" or ">"

Created attachment 20808 [details]
new xev log

this is the xev output
i move the mouse in
then pressed enter
then pressed brightness down
then pressed enter
then pressed brightness up
then pressed enter and closed the window

the funny thing is => it worked ?!?

maybe it's because of a full system update (new kernel and other stuffs)

i really don't know why it work...
i will reboot and do some other tests to be sure it was not just luck

Created attachment 20809 [details]
an other new xev log

like i throught it was luck..
after rebooting the laptop it bugs again,
here is an other xev output like before i entered the window
pressed enter
pressed brightness down (it go down until screen completely dark)
pressed enter
pressed brightness up (it go up to 100%)
pressed enter and closed window

Event: time 1228390664.788605, type 4 (Misc), code 4 (ScanCode), value 1c
Event: time 1228390664.788623, type 1 (Key), code 28 (Enter), value 1
Event: time 1228390664.788627, -------------- Report Sync ------------
Event: time 1228390664.870524, type 4 (Misc), code 4 (ScanCode), value 1c
Event: time 1228390664.870537, type 1 (Key), code 28 (Enter), value 0
Event: time 1228390664.870541, -------------- Report Sync ------------

This is how it should be. Value 1 for press, value 0 for release

Event: time 1228390665.945721, type 4 (Misc), code 4 (ScanCode), value 88
Event: time 1228390665.945737, type 1 (Key), code 225 (Brightness up), value 2

This is what the key generates in-kernel. It doesn't do press/release, it just creates a single "repeat" (2). So if that would ever get to the server, it would look like a button press without a release event following.

However, looking at the xev log (the broken one), xev doesn't even see the key presses so there can't really be an X application that controls brightness anyway. It wouldn't get the events. Run lshal -m and press the keys, what do you get there?

Created attachment 20827 [details]
lshal -m output

here is the lshal -m output from console mode (with X running in background)
in X there is no output
i just pressed once the brightness up and down button

sorry, you'll have to take this up with the kernel or with hal.

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