I can confirm this on KDE 4.5.4., OpenSuSE 11.3 packages, with a Microsoft Natural Ergonomic Keyboard 4000.

A workaround as posted at http://forum.kde.org/viewtopic.php?f=17&t=89602 works for me: In khotkeysrc and kglobalshortcutsrc I replaced the occurrences of "Launch (1)" with "Calculator" (while not logged into KDE). After that the calculator key starts the program assigned to it.

Bug 255329 is a duplicate of this one...

I would like to confirm this problem in both KDE 4.5.5 on Ubuntu and 4.6.3 on Arch.

If you do the config file hack to force it manually, the menu editor correctly displays "Calculator" as the hot key. If you then try to set it by pressing the calculator key it sets it to Launch(1). Launch(1) is actually a generic hot key sometimes found as Fn+F2/F3 on laptops.

I have tried this on Microsoft Digital Media keyboard 1.0a and Wireless desktop 1000. Until someone says otherwise I think it's safe to assume that it effects all MS keyboards with the calculator key.

Still effects KDE 4.7.1

Can this please be marked as confirmed? It should effect any user with a Microsoft keyboard.

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

in KDE 4.7.1 still, with Logitech Internet Keyboard

Absolutely confirmed
I'm on Gentoo, KDE 4.7.4
and the problem is still there:
khotkeys stubbornly thinks that the calculator key on all of my keyboards is the "Launch (1)" key
I used a Microsoft ComfortCurve2000, a Logitech k750 and a Logitech k710 all with the same result, so I'm pretty sure it's not hardware related
All other multimedia Keys work as expected

xev reports this:
KeyPress event, serial 35, synthetic NO, window 0x6e00001,
    root 0x15d, subw 0x6e00002, time 133413435, (63,62), root:(1801,93),
    state 0x10, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 35, synthetic NO, window 0x6e00001,
    root 0x15d, subw 0x6e00002, time 133413535, (63,62), root:(1801,93),
    state 0x10, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

(In reply to comment #7)
> Absolutely confirmed
> I'm on Gentoo, KDE 4.7.4
> and the problem is still there:
> khotkeys stubbornly thinks that the calculator key on all of my keyboards is
> the "Launch (1)" key
cut ...

Forgot to mention that for me too manually changing "Launch (1)" with "Calculator" in both .kde4/share/config/khotkeysrc and .kde4/share/config/kglobalshortcutsrc fixes the problem

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

Created attachment 69094 [details]
This patch fix the bug

This patch fix the bug

Comment on attachment 69094 [details]
This patch fix the bug

>--- kdelibs-4.8.0/kdeui/util/kkeyserver_x11.cpp	2012-02-25 18:53:49.480771132 -0200
>+++ kkeyserver_x11.cpp	2012-02-25 18:20:38.912403430 -0200
>@@ -355,7 +355,7 @@
>     { Qt::Key_MediaRecord, XF86XK_AudioRecord },
>     { Qt::Key_LaunchMail, XF86XK_Mail },
>     { Qt::Key_Launch0,    XF86XK_MyComputer },
>-    { Qt::Key_Calculator,    XF86XK_Calculator },
>+    { Qt::Key_Launch1,    XF86XK_Calculator },
>     { Qt::Key_Memo,    XF86XK_Memo },
>     { Qt::Key_ToDoList,    XF86XK_ToDoList },
>     { Qt::Key_Calendar,    XF86XK_Calendar },

KDE 4.9, the bug is still there. It's boring to patch every new version to get the calc key working.

This looks like a workaround to me. Does this mean Qt handles Qt::Key_Calculator badly?

I grepped qt4 src/gui and I see no difference between Key_Calculator and Key_Launch1, on X11. They are both in qkeymapper_x11.cpp and in qkeysequence.cpp

Ah, but qkeymapper_x11.cpp maps XF86XK_Calculator to both!

Isn't the right fix to remove the line 1066, which says
  XF86XK_Calculator,          Qt::Key_Launch1,
?

(In reply to comment #13)
> This looks like a workaround to me. Does this mean Qt handles
> Qt::Key_Calculator badly?
> 
> I grepped qt4 src/gui and I see no difference between Key_Calculator and
> Key_Launch1, on X11. They are both in qkeymapper_x11.cpp and in
> qkeysequence.cpp
> 
> Ah, but qkeymapper_x11.cpp maps XF86XK_Calculator to both!
> 
> Isn't the right fix to remove the line 1066, which says
>   XF86XK_Calculator,          Qt::Key_Launch1,
> ?

I looked at the source as well for qt-gui.  I saw the two mappings but did you also notice that the second one has calculator misspelled as calculater?  It might be better to shift a few lines around instead of deleting the properly spelled one so the properly spelled one is maintained and the misspelled one is deleted -- XF86XK_Calculator being the proper spelling and not XF86XK_Calculater.  I'll try testing it to see if that would work.

Created attachment 73062 [details]
qt-gui-4.8.2-calculator-key.patch

I just confirmed that patching qt-gui works without needing to patch kdelibs.  It seems like the qt guys even know that some of the key shortcuts are screwed up as well? (// ### Qt 5: remap properly)  I wonder if this calculator key bug has also been fixed in qt 5.

Although this qt patch fixes the problem, I wonder what the purpose of the misspelled calculator constant is for.  These constants in qt were pulled from XF86keysym.h from the x11proto package.  The misspelled "XF86XK_Calculater" constant which has a different hex value from "XF86XK_Calculator" originated in xfree86 XF86keysym.h revision 1.13 on 11/22/2002:  

522. Added support for special keys found on many ACPI control, Easy Access
      Keyboards, Internet keyboards, laptops, notebooks and PDA (via
      xkb/symbols/inet). Added new key symbols for these keyboards
      (Stanislav Brabec).

Before that commit, XF86XK_Calculator was the only one that existed.  

In revision 1.12, the keysym for XF86XK_Calculator was 0x1008FF1D.  This is the same symbol that my keyword uses (Microsoft Natural Keyboard 4000).  In revision 1.13 that keysym did not change while XF86XK_Calculater was added with a keysym of 0x1008FF54.  Strangely enough, the comments for XF86XK_Calculator note that the developer thinks they only apply to PDAs like Pocket PC and Palm while the other keysym 0x1008FF54 applies to "internet keyboards" which is what I guess my keyboard is.  I wonder if there are keyboards out there that register the calculator key as 0x1008FF54 instead of 0x1008FF1D as my keyboard does (you can test this with the xev program and looking at the keysym your calculator key emits).   In that case, my patch for qt-gui would not work for everyone.  I'm thinking that maybe Qt::Key_Calculator should be applied to both the misspelled constant and the correctly spelled one instead.

Created attachment 73065 [details]
qt-gui-4.8.2-calculator-key.patch

I just tested my theory and that appears to work.  This patch would work for both types of keyboards that register the calculator key as 0x1008FF1D or 0x1008FF54.

I just examined qt 5 alpha and unfortunately, it appears as though nothing as changed in qt 5 alpha in regards to this bug or any changes to the mapping of keys (file changed to qxcbkeyboard.cpp in qt 5) as indicated in that qt comment.  Perhaps this patch can be pushed to the qt developers so they can patch qt 4 and 5.

I created a ticket on the qt tracker as well if anyone is interested: https://bugreports.qt-project.org/browse/QTBUG-26812

Thanks for your work on this. Unfortunately, for legal reasons, *you* have to be the one to push the patch to Qt5, and then to Qt4, via gerrit (http://codereview.qt-project.org).
Well, ok it's a one-liner, I guess it could be considered trivial enough for anyone to apply it.
But since I can't even test it, I'd rather not do that myself :-)
In any case, the first step is to make a Qt5 patch (Qt contribution rules require a Qt5 fix before a Qt4 fix, so that no fix for 4 is forgotten in 5)

(In reply to comment #20)
> Thanks for your work on this. Unfortunately, for legal reasons, *you* have
> to be the one to push the patch to Qt5, and then to Qt4, via gerrit
> (http://codereview.qt-project.org).
> Well, ok it's a one-liner, I guess it could be considered trivial enough for
> anyone to apply it.
> But since I can't even test it, I'd rather not do that myself :-)
> In any case, the first step is to make a Qt5 patch (Qt contribution rules
> require a Qt5 fix before a Qt4 fix, so that no fix for 4 is forgotten in 5)

I don't mind submitting the patch myself but I'm not sure how to sign up for an account and post to https://codereview.qt-project.org

(In reply to comment #21)
> (In reply to comment #20)
> > Thanks for your work on this. Unfortunately, for legal reasons, *you* have
> > to be the one to push the patch to Qt5, and then to Qt4, via gerrit
> > (http://codereview.qt-project.org).
> > Well, ok it's a one-liner, I guess it could be considered trivial enough for
> > anyone to apply it.
> > But since I can't even test it, I'd rather not do that myself :-)
> > In any case, the first step is to make a Qt5 patch (Qt contribution rules
> > require a Qt5 fix before a Qt4 fix, so that no fix for 4 is forgotten in 5)
> 
> I don't mind submitting the patch myself but I'm not sure how to sign up for
> an account and post to https://codereview.qt-project.org

nm, I found the wiki on how to do it.

Well, I think that patching the kdelibs is the most correct approach, because, according to http://qt-project.org/doc/qt-4.8/qt.html, Qt::Key_Calculator is not mapped on X11 and Qt::Key_Launch1 must be used instead. Anyway, even if the problem is with Qt, your path probably will not be accept, because, as stated in https://bugreports.qt-project.org/browse/QTBUG-25118 Qt5 is meant to have minimum source incompatibility. Therefore, I think this patch must be accept in kdelibs as soon as possible, because, as said before, is indeed annoying have to patch every new version to have the calculator key working.

Leonardo is right.  It would likely take a while for Qt to apply this patch, it's better to patch kdelibs now than to wait for the change to come through Qt assuming they agree to change it.

What a mess, between the typo in the X headers and the full documentation of these quirks in the Qt API docs -- I had no idea the use of Launch1 was fully documented in Qt :-)

OK then, I'll apply the kdelibs fix.

Thanks for all the investigations.

Git commit 1c7ae18ef5d1b7adbb271c1164d0d899eb6d4ed8 by David Faure.
Committed on 17/08/2012 at 19:41.
Pushed by dfaure into branch 'KDE/4.9'.

Fix handling of XF86Calculator, patch by "Leonardo".

Full investigation details in the bug report.
FIXED-IN: 4.9.1

M  +3    -1    kdeui/util/kkeyserver_x11.cpp

http://commits.kde.org/kdelibs/1c7ae18ef5d1b7adbb271c1164d0d899eb6d4ed8

I'm actually still seeing this issue in 4.9.2.

It's working for me since 4.9.1 Ian.

Looks like I did not have the shortcut key set. Following Stephen's steps in the bug description, I see that the calculator key now works.

Bug still present in 4.9.90. Is this a regression?
I did not re-check in 4.9.1 since I already applied the workaround from the forums several versions ago.
From my perspective I would say this was never fixed, but if it actually was in 4.9.1, then it seems to be back in 4.10.

xev correctly outputs:

KeyRelease event, serial 36, synthetic NO, window 0x4000001,
    root 0x135, subw 0x0, time 10647210, (561,-616), root:(563,226),
    state 0x10, keycode 148 (keysym 0x1008ff1d, XF86Calculator), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

but when setting a shortcut I still get "Launch (1)" instead of "Calculator".

This WORKSFORME using KDE 4.9.2 on Ubuntu 12.04.1, however it requests root privileges for kcalc (I guess that's a different issue...)

Still works for me in 4.9.5 and 4.10 on ArchLinux.  The shortcut trigger still says Launch(1), however the fix made pressing the calculator key work to trigger the event anyway.

That's right, but it's still confusing that it says "Launch (1)". It should really display "Calculator". I wouldn't consider this issue fully fixed until then.

No, "Launch (1)" is how Qt handle this key. If you check the link that I posted before you'll see that       Qt::Key_Calculator is not mapped in X11 and you must use Qt::Key_Launch1 instead. If you still want it to display "Calculator" please open a ticket on Qt tracker since I don't think that this is a job to KDE do.

Tested on Qt5. Things seem to work for me.