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
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. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.