Version: (using Devel) OS: Linux Installed from: Compiled sources On my Dell XPS M1330 my multimedia keys work as its are pressed twice. e.g. if I pressed volume up, the volume raise of two values. If I pressed mute, the volume mute and the unmute. Sorry again for my english
Which revision are you using?
I use Kubuntu 8.10 updated via "official" KDE's repo. So it's the version included KDE 4.1.85.
I must say I've been seeing this since I use KDE 4(.0) on my current laptop, and that it still does this in 4.2 beta. I never reported this because I tought of a hardware support problem (you know, the ACPI mess... ). I am using OpenSuse packages for my part and my laptop is a Dell XPS M1330 too. … and well, volume keys are detected as pressed, not only twice, but three times! Sorry for this "me too" report, but I hope this will help finding the cause (I believe it is lower level than KDE, though… ).
You could try to use "xev" to see how many keys are pressed. But make sur you quit KMix before running xev, because otherwise KMix might steal the KeyPress- and KeyRelase-Event of the volume keys.
I tried, and in effect it works like pressed 4 times!! There's not a "rule". Sometimes, it works like pressed twice, 3 times or 4 times. Xev output: KeyPress event, serial 31, synthetic NO, window 0xa00001, root 0x13b, subw 0x0, time 770563, (729,598), root:(734,623), state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 34, synthetic NO, window 0xa00001, root 0x13b, subw 0x0, time 770816, (729,598), root:(734,623), state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 34, synthetic NO, window 0xa00001, root 0x13b, subw 0x0, time 770816, (729,598), root:(734,623), state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 34, synthetic NO, window 0xa00001, root 0x13b, subw 0x0, time 770867, (729,598), root:(734,623), state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 34, synthetic NO, window 0xa00001, root 0x13b, subw 0x0, time 770867, (729,598), root:(734,623), state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 34, synthetic NO, window 0xa00001, root 0x13b, subw 0x0, time 770868, (729,598), root:(734,623), state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False
I noticed that this happens also for multimedia keys.
Well, if it is like this, I can't do anything. 2,3,4 events simply mean 2,3 or 4 key presses. I will close bug report, as it has nothing to do with KMix - it affects any other application which use those keys. Here is a proposal for your further investigations: This is either a hardware issue, or a driver/OS issue. You can check the former using a completely different OS. If it is not a hardware issue, please open a bag report either at your Linux distributor, or to someone else who might be applicable (Xorg?!?).
Another proposal: this laptop is also sold by Dell with a preinstalled Ubuntu. This would be interesting to know if their ubuntu also hat this issue, and if not (and I it would surprise me if it did!), to inquire what they had to patch for it to work. Emanuele, is your OS the preinstalled one?
No it's not a preinstalled one, but if I install Ubuntu instead of Kubuntu everything works fine. So where do you think I have to open this bug?
Not 100% sure, but as Kubuntu sounds like a good idea.
We just verified this here today at the Ubuntu Global Bug Jam. Xev is reporting the key press correctly and KMix is reporting it as a double/triple tap. Talked about it on IRC with a few people and it seems they can also confirm it is KMix. Could you please review this and provide any more information that makes you think that it isn't KMix?
I tried to do the test above (with xev) but this time with Kmix opened, and the output is doubled! So I was wrong, and I think too that Kmix has something to do with this.
Created attachment 33069 [details] xev output _outside_ KDE session How to reproduce this output (on Kubuntu Jaunty 9.04 Final Release, upgraded from Intrepid): (type CTRL-ALT-F1) $ sudo Xorg :1 & $ DISPLAY=:1 xterm (type CTRL-ALT-F9) (mouse over xterm) $ xev (hit Mute key only once) (hit VolumeDown key only once)
Created attachment 33070 [details] xev output in a KDE session without KMix (right click on Kmix systray icon > Quit) (open a konsole window) $ xev (hit Mute key only once) (hit VolumeDown key only once)
Created attachment 33071 [details] xev output in a KDE session with KMix How to reproduce this output (on Kubuntu Jaunty 9.04 Final Release, upgraded from Intrepid): (open a konsole window) $ xev (hit Mute key only once) (hit VolumeDown key only once)
I confirm this bug on Kubuntu Jaunty 9.04 (freshly upgraded from Intrepid) on a Dell XPS M1330. All multimedia keys worked fine for me in KDE 3.5 and I see this wrong behavior since KDE 4.1 (the first version I tried on Kubuntu 8.10). I have attached three different tests I just perfomed using xev and hitting two different buttons (Mute and VolumeDown) _just one time_. The first test is done outside KDE (I opened a second X server and launched xev from a xterm there, see attachment comments). You can see that only two key presses/releases are correctly detected. The second test is done in a KDE 4.2 session, after closing KMix. You can see that multiple key presses/releases are wrongly detected. The third test is done in a KDE 4.2 session, with KMix running. You can see that only multiple releases are detected (here also some focus changes are visible). KMix seems to "steal" key presses, but not key releases. My conclusions from these tests are the following: - It is not an hardware problem. - It is not a kernel/driver problem. - It is not a Xorg bug (at least not Xorg taken alone). - It is related to KDE (outside a KDE session keys presses/releases are detected correctly). - It is not a KMix bug, multiple key presses/releases are detected also after closing KMix, but I don't know if it's normal that KMix is stealing key presses, but not key releases from xev output. So the question remains: what is the best place to report this bug? I conclude saying that sometimes, but rarely, something "magic" happens when I play with xev and suddendly all buttons begin to work correctly inside KDE and with KMix running. Today it happened just one time, but after a reboot the multiple key presses/releases came back. :( I don't know what triggered the correct behavior; if I will discover it, I will write here a follow up. I copy this comment also on the Ubuntu bug tracker. Thank you for your attention! Augu
I have new info. I'm using synergy at work to control both my workstation and my XPS1330 from a single keyboard and mouse. synsergy server is launched on the workstation, and synergy client is running on the XPS1330. I noticed that in this situation (synergys and synergyc running), if I move the mouse on the XPS1330 screen (to control the XPS1330 via synergy) the laptop multimedia keys work correctly inside KDE session and with KMix running. Just one keypress at a time is detected. If I move the mouse outside XPS1330 screen (I move back the mouse on the workstation), the multimedia keys return to the bad behavior, and multiple key presses are detected upon a single real key press. So new info here: - It's something related to Xorg (synergy uses Xorg to control multiple PCs over the network with a single keyboard and mouse) - It's related to KDE, because outside KDE (see my previous comments) the multimedia keys work correctly. I see no activity on this bug, maybe because the issue is not related directly to Kmix. Can you please point me to the right place to report this issue? XPS1330 is very well supported on Linux, and this issue on multimedia keys is very annoying to me. Thank you very much!
Augusto, thanks for your lengthy investigations. Looks really like a X11 issue. So X.org would be a good place to report this, please see http://www.x.org/wiki/ , it states: "Use the xorg product in the freedesktop bugzilla to report bugs against X." Closing bug
I recently SOLVED this issue, sorry if I didn't wrote an update here. The trick (I'm not completely sure) was going to KDE System Settings > "Keyboard and mouse", and playing a bit with "Enable keyboard repeat" in the Keyboard page. Maybe I just activated then deactivated it, then my problems with multimedia keys are gone. As I told you, I'm not completely sure on what resolved the multiple key presses issue, but I was playing with settings in that page and suddendly the issue is gone (also after rebooting the system). IMHO this strange issue is not (only) in Xorg as you suggested, because playing with a KDE configuration solved it.
This is not fixed, and it may be fixable in KDE. The underlying issue is that the key-press events generated by the Dell XPS M1330's touch-sensitive media keys always last slightly less than 700 milliseconds, even if you touch the buttons for less time than that. If your typematic rate is set with an initial delay of less than 700 ms, you will generate multiple key presses, just as if you were holding down the button. As such, a work-around is to increase your typematic rate initial delay to 700 ms or greater. However, slowing your typematic rate may also drive you insane, so a real fix would be nice. These buttons work correctly in GNOME, and I they do it by letting the keys generate DBus events and then catching the DBus events, or something. In any case, if KDE did it the same way, it might improve interoperability and fix this bug at the same time.
This is not an X11 bug. It is a hardware flaw in the Dell M1330's touch-sensitive multimedia buttons. Regardless of how long you press the buttons, they always generate a keypress event with a duration of about 680 milliseconds. This is long enough to trigger the typematic repeat with the default settings. You can work around this problem by setting the typematic delay to 700 milliseconds or longer, but that is a workaround, not a solution. I know that GNOME handles these keys correctly, so it would probably be worthwhile to ask the person in charge of GNOME's media key support how they do things.
Well, i have new information about this bug. I doubt this problem is in hardware. I have the same laptop, but connected to an *external* keyboard. And external multimedia keys have the same bug! The keyboard is Microsoft Comfort Curve. And the most strangest thing is that just deactivating/activating "keyboard repeat" in KDE configuration dialog fixes it. Delay is set to default and doesn't change during experiment - 660ms.
Apparently the KDE keyboard repeat settings are not applied when you first log in. So when you go into system settings and you deactivate and then reactivate the keyboard repeat settings, you are actually *changing* the delay, because the KDE settings are overriding the system default, which is a much shorter delay than 660 ms. You can try this yourself. Open a terminal or text editor right after logging in, and hold down a key to test the autorepeat rate. Then go into system settings and twiddle the check box for autorepeat. Then go back to your text editor and test the autorepeat again. It will be slower. The point is that Dmitry's proposed fix is really just the same workaround in disguise: slow down the autorepeat settings. Anyway, I'd like to stress that this is a solvable problem, because GNOME solves it somehow. I wish I knew where to look in the GNOME source code for the solution, but I don't. Furthermore, I'm not convinced that media keys should work in the same way as regular keys. For example, having any autorepeat on the mute button is ridiculous. There's no case where you would want a toggle button to autorepeat. It would be like having autorepeat on Caps Lock.
Moving bug to "kdelibs".
Is the M1330 the only laptop that suffers from this problem? Surely not. It seems to me like all we need is a way to disable autorepeat on the media keys...or for the software to ignore repeat keystrokes on those keys. It's really frustrating when the play/pause button pauses and unpauses with a single touch...same for mute, skip back/forward, volume up/down, etc. Makes them nearly useless. :(
Actually, the problem seems to be gone on 4.6 on my laptop. But I also upgraded from Lucid to Maverick around the same time, which includes a kernel major version upgrade, so I'm not sure what fixed it.
I'm running 4.6 on Maverick but the problem is still as bad as ever.
This bug is still there in my M1330 running Plasma 5.3-1 on Archlinux (everthing updated).
Created attachment 94133 [details] xev output of two taps on raise and low volume.
Created attachment 94135 [details] Workaround for this bug. Disable autorepat in certain keys. Please attention!! You have to check the script to set your keycodes before executing it. It disables autorepeat on multimediakeys (and bright keys which also had this problem in my laptop). My keycodes are in the script but yours could be different. I hope this help.
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!