I had more to add before i accidently pressed "commit" :-)

The reason for the keys not working is described as below.

1. In gdk_keymap_entries_for_keyval and update_keymaps() we are only 
looping for less than max_keycode. ie (keycode < max_keycode) rather 
than (keycode <= max_keycode).
  In the case of sun type-4 keyboard the keycode of KP_Add is the 
max_keycode value.

2. Secondly for some reason the following logic doesnt return the 
desired value for sun type-4 keyboards.

SYM (group, shift_level)

I guess its because the keysyms_per_keycode is 5 and not 4 which is 
the ideal case.
However XKeycodeToKeysym or XKeysymToKeycode works just fine.

Bugs which are duplicates of this are bug #75747, bug #75391 and bug 
#75746. Although the bugs have been reported for gnome-calculator, 
the actual fix must go in the gtk+ code.

Attaching a patch which fixes the problem.

Created attachment 7794 [details] [review]
Proposed patch

I'm not taking this change without an explanation of why
the current code doesn't work. Also, I'm not taking the
conditionalization on SUN_KB. As I've said elsewhere, 
X is a client-server operating system. You can't conditionalize
on the client operating system to deal with differences
on the server side.

+#ifdef SUN_KB
+              if (XKeycodeToKeysym (gdk_display, keycode, i) == keyval)
+#else
               if (syms[i] == keyval)
+#endif

I am not sure why the current code is not working. I feel its because 
the keysyms_per_keycode is 5 and not 4 as it usually is.

So what i did now is, in update_keymaps() i added the following piece 
of code.

while (keycode <= max_keycode)
    {
      KeySym *syms = keymap + (keycode - min_keycode) * 
keysyms_per_keycode;

      /* In US4.kt for sun type-4 keyboard XK_KP_Add SCANCODE is 127 
and
       * MINSCANCODE is 1. Thereby KEYCODE = 127 + (8 - 1) == 132
       */
       if (keycode == 132 ) {
            printf ("Keycode is XK_KP_Add\n");
            printf ("min_keycode %d, max_keycode %d, 
keysyms_per_keycode %d\n", min_keycode, max_keycode, 
keysyms_per_keycode);
            printf ("Keysym value from syms[0] is %x\n", syms[0]);
            printf ("Keysym value from XKeycodeToKeysym is %x\n", 
XKeycodeToKeysym( gdk_display, keycode, 0));
        }

And when i run gnome-terminal i get the following output.

Keycode is XK_KP_Add
min_keycode 8, max_keycode 132, keysyms_per_keycode 5
Keysym value from syms[0] is 2009
Keysym value from XKeycodeToKeysym is ffab

The keysym value returned from the XKeycodeToKeysym is correct.

Coming back to the #ifdef SUN_KB it is most definitely not required. 
But shouldnt we allow the XServer do the keycode to keysym and vice 
versa translation, rather than gtk doing it. We are working with 
different XServer implementations and a single gtk+ code.

I might be wrong here because in update_keymaps() we do modify the 
keysym table. Please correct me if so.

Any updates on this?

Hmmm, when Padraig dumped his keymap it looked a bit more
sane than this ... he got 'ffab' for the KP_Add key:

It would be very useful if someone could attach, for comparison:

 a) the output of 'xmodmap -pk' running xmodmap on a Sun
    box with DISPLAY pointing to that Sun box.

 b) the output of 'xmodmap -pk' running on a Linux box
    with DISPLAY pointing to the Sun box.

If they aren't showing the same key symbols, then we basically
have Sun XLib and utilities covering up for non-conformance
to the X protocol in the Sun X server, and there is very
little that GTK+ can do.

If they do show the same symbols, then there is some bug
in gdkkeys-x11.c that needs fixing.

Created attachment 8507 [details]
output of 'xmodmap -pk' on a Linux box with -display pointing to the Sun box

Created attachment 8508 [details]
output of 'xmodmap -pk' running on a Sun box with -display pointing to the Sun box

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

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

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

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

Owen, those two attachments are identical, so the bug would
appear to be in gdkkeys-x11.c. gcalctool is getting hit by the
same problem. any chance you can look at this please? Thanks.

I looked at for a while, and came away completely puzzled.

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

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

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

i'm just wondering if this bug is a gnome-calculator bug afterall -
I'm gonna check through the code tommorrow...because there is a lot of
voodoo going on with the various accelerators.

As I commented also in 75391 I comment here again (Thanx John for
pointing me for comments here )

Also on Linux on x86 hardware and a Standard PC Keyboard the behavior
of gnome-calc is reversed. Means that you must set NumLOCK to OFF to
use it correctly and if you set NumLOCK to ON the functions of the
keypad are used (behavior as the NumLOCK is OFF in other applications,
that means the 2 is then the cursor down etc.)

It should be that either gnome-calc (or other apps as well) takes both
NUMLOCK ON and NUMLOCK OFF or NUMLOCK ON only.

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

adding cc

Created attachment 9470 [details]
Test case showing the . numpad key isn't working.

I've added a test case. Compile this, per the comment at the
beginning of the program. Run. You should see a small number
pad in a window. Clicking on the buttons or doing the main
keyboard equivalent of them works fine. Now try, turning the
NumLock key on, and using the number keypad. They all seem to
work except for ".". This is on an Ultra 60 running Solaris 9
and latest Gtk2 libraries.

Carsten: FYI - having num lock on or off makes no difference - the
"Del / ." key will always delete whatever is currently displayed in
calculator - i.e. you cannot add " . " to numbers using numpad.

Shane:

Yes, but despite of that the bevahior of the NUM PAD is simply inversed.
Also, I would like to remember (as everybody is talking of the Sun
Keyboard here) that I have this issues with a standard x86 PC-105
Keyboard.

Note that most of the dups on this bug are inappropriate. 
The bug is about a Sun keyboard problem that occurs wiht
any app.

There is a separate problem with gcalc where the keypad
work on any machine. It could be a GTK+ bug (I gave Gman
some things to try for a test case) or it could just be
a gcalc bug... gcalc is definitely doing strange stuff.

And I was directed here because all other bugs (like you mention) are
marked as dupes of this bug. I was first commenting on another bug
which has been marked as a dupe of this as well.

ALL:

based on owens comments (above) about this being a sun keyboard bug
can we re-open bug #85775 (gcalc "del" key not functioning correctly)?

I've reopened bug 85356 (which still occurs) in response to Owen's
comments about this bug (79184) being Solaris-specific. If I'm
confused, close it again.

Owen: The problem could now be traced to the value of the third 
argument (the keycount) passed to XGetKeyboardMapping().
We are passing keymap_x11->max_keycode - keymap_x11->min_keycode.
This should be keymap_x11->max_keycode - keymap_x11->min_keycode + 1. 
I verified this with the Xlib sources. It does the same.
On passing the new value and looping through (keycode <= 
keymap_x11->max_keycode) at places where we are looping (keycode < 
keymap_x11->max_keycode) fixes the problem.

Here is the output for the printf statements i had put earlier
Keycode is XK_KP_Add
min_keycode 8, max_keycode 132, keysyms_per_keycode 5
Keysym value from syms[0] is ffab
Keysym value from XKeycodeToKeysym is ffab

Attaching the modified patch.

Created attachment 10116 [details] [review]
Modified patch

So the bug was _only_ about KP_Add and not about any other
key symbol? I completely missed that...

Owen: Any comments on the modified patch?

I was actually hoping for a response to my last question... I
want to make sure I understand the problem  completely.

Truly sorry for having missed your last question.
Verified with the latest sources and without any of my patches.
Accels work fine. So essentially the bug is with the KP_Add button 
not working. I seem to have lost the fact i made a comment on accels 
like Ctrl Q.
The bug summary needs to be changed to "Keypad key '+' button doesnt 
work on sun keyboards".

The numpad works fine for me with Sun's beta2 build5 - Can I close
this bug?

Shane: Its because you have the modified patch in Sun's beta2 
build5 . This patch hasn't gone into CVS.

Owen: Any comments on the modified patch?
Changing the Summary of the bug to reflect the actual problem.

Owen : Could you review the modified patch please. 

Applied to both branches. Thanks for the patch, sorry for
the delay on this.

Fri Oct  4 14:49:04 2002  Owen Taylor  <otaylor@redhat.com>

        Patch from Shivram U <shivaram.upadhyayula@wipro.com>

        * gdk/x11/gdkkeys-x11.c (update_keymaps): Increased the
keycount to
        (max_keycode - min_keycode) + 1 from (max_keycode - min_keycode).
        (update_keymaps), (gdk_keymap_get_entries_for_keyval) looping
through
        less than or equal to max_keycode. (#79184)

verified fixed in sun's gnome build fcs-03.

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