Bug 18590 - Fn + brightness up/down keys doesn't work Samsung NC10
Fn + brightness up/down keys doesn't work Samsung NC10
Status: RESOLVED NOTOURBUG
Product: xorg
Classification: Unclassified
Component: Server/Input/Core
7.4 (2008.09)
x86 (IA32) Linux (All)
: medium normal
Assigned To: Jesse Barnes
Xorg Project Team
:
: 20862 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-18 02:00 UTC by Alain Tavan
Modified: 2009-03-26 21:11 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
the xev log after changing brightness (21.31 KB, text/x-log)
2008-11-28 06:18 UTC, Alain Tavan
no flags Details
evtest grab in console mode (381 bytes, text/x-log)
2008-11-28 06:26 UTC, Alain Tavan
no flags Details
evtest grab in X (4.23 KB, text/x-log)
2008-11-28 06:28 UTC, Alain Tavan
no flags Details
evtest without X (1.04 KB, text/x-log)
2008-12-04 04:22 UTC, Alain Tavan
no flags Details
the evtest logfile when trying to log the complete output using "tee" or ">" (4.00 KB, text/x-log)
2008-12-04 04:24 UTC, Alain Tavan
no flags Details
new xev log (10.71 KB, text/x-log)
2008-12-04 04:34 UTC, Alain Tavan
no flags Details
an other new xev log (28.89 KB, text/x-log)
2008-12-04 04:50 UTC, Alain Tavan
no flags Details
lshal -m output (290 bytes, text/plain)
2008-12-04 23:45 UTC, Alain Tavan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alain Tavan 2008-11-18 02:00:27 UTC
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

It work on non graphical mode, but when i go in Xorg it makes two problems:
first the keyboards key stop working (luckily the CTRL + ALT + F1-F6 continue working)
and it change the brightness but not like i want.
when i decrease the brightness it decrease but didn't stop and go to 0%
when i increase it's the same, id didn't stop until 100%

to gain keyboard access i need to switch to console mode (CTRL + ALT + F1) and come back again in graphical mode (ALT + F7)

i first trough it was an ACPI bug and open a bug report here : http://bugzilla.kernel.org/show_bug.cgi?id=12021
but because it work in console mode it may be a driver problem or and xorg problem

please help me, if you need attachement, i will make them 


the problem was on ubuntu 8.10 
i switch to linux mint 6 (still RC but based on ubuntu 8.10) and the problem is the same
Comment 1 riccardo 2008-11-27 02:23:23 UTC
I can confirm the same behavior. If you need any information please let me know.
Comment 2 Peter Hutterer 2008-11-27 16:03:27 UTC
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)
Comment 3 Alain Tavan 2008-11-28 06:18:32 UTC
Created attachment 20662 [details]
the xev log after changing brightness
Comment 4 Alain Tavan 2008-11-28 06:26:46 UTC
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
Comment 5 Alain Tavan 2008-11-28 06:28:13 UTC
Created attachment 20664 [details]
evtest grab in X

like promised, here is the output of evtest in X
Comment 6 Peter Hutterer 2008-11-30 16:42:17 UTC
> --- 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. 
Comment 7 Justyn Butler 2008-12-01 03:23:17 UTC
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.
Comment 8 Justyn Butler 2008-12-01 03:25:50 UTC
A link to that RedHat Bug 460237 with near identical symptoms:
https://bugzilla.redhat.com/show_bug.cgi?id=460237
Comment 9 Peter Hutterer 2008-12-02 17:25:26 UTC
(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. 

Comment 10 Alain Tavan 2008-12-03 06:13:51 UTC
(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 :(
Comment 11 Alain Tavan 2008-12-03 06:16:18 UTC
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 ?!?
Comment 12 Peter Hutterer 2008-12-03 17:00:11 UTC
do you have a reference to the kernel.org bug?
Comment 13 zhang rui 2008-12-03 18:06:48 UTC
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.
Comment 14 Peter Hutterer 2008-12-03 20:06:58 UTC
(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.
Comment 15 Alain Tavan 2008-12-04 03:04:18 UTC
(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 :) 
Comment 16 Alain Tavan 2008-12-04 04:22:56 UTC
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 :(
Comment 17 Alain Tavan 2008-12-04 04:24:02 UTC
Created attachment 20807 [details]
the evtest logfile when trying to log the complete output using "tee" or ">"
Comment 18 Alain Tavan 2008-12-04 04:34:00 UTC
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
Comment 19 Alain Tavan 2008-12-04 04:50:24 UTC
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
Comment 20 Peter Hutterer 2008-12-04 17:50:40 UTC
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?
Comment 21 Alain Tavan 2008-12-04 23:45:18 UTC
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
Comment 22 Peter Hutterer 2008-12-18 02:40:27 UTC
sorry, you'll have to take this up with the kernel or with hal.
Comment 23 Peter Hutterer 2009-03-26 21:11:53 UTC
*** Bug 20862 has been marked as a duplicate of this bug. ***