Tk Source Code

View Ticket
Login
Ticket UUID: 481308
Title: Bug regarding numeric keypad on solaris
Type: Patch Version: None
Submitter: tfengler Created on: 2001-11-13 14:53:31
Subsystem: 32. Key Symbols Assigned To: aku
Priority: 8 Severity: Minor
Status: Closed Last Modified: 2026-10-10 17:15:07
Resolution: Fixed Closed By: nemethi
    Closed on: 2026-10-10 17:15:07
Description:
on Sun Solaris machines the numerals pad generates
problems when there is a bind on the arrow-keys.
In en entry-widget, the 4 and 6 numerals dont work, in
a text-widget the 4,6,2 and 8 numerals.
The problem is, that the "Numlock-Key" has the same
effect as the "Mode-Key", but affects only the keys of
the numerals pad. As a consequence, the third or fourth
slot of the keymap-vector must be used, not the first
and second. 
When the first two vectors are used, XKeycodeToKeysym
always produces the keysyms for the arrow key's and
then the binding of the arrow-keys is taken and not the
numeral istself.
When there is no bind on the arrow-keys, the keys of
the numerals pad work fine, because the function
XmbLookupString takes the keycode and the state of the
mode-switches.
I tested my patch on a sun solaris machine with solaris
2.7.
I hope it works also with linux.
I attach a patch for the following files
generic/tkInt.hVersion 1.40
unix/tkUnixKey.cVersion 1.5
User Comments: nemethi (claiming to be Csaba Nemethi) added on 2026-10-10 17:15:07:

Yet another very long-standing bug, many thanks for fixing it, Serhiy! Merged into main, core-9-0-branch, and core-8-6-branch by commits [79303131], [10e53d85], and [6bd670bf].


serhiy.storchaka added on 2026-09-19 09:21:09:

With input methods enabled (the default on X11) the keysym comes from XLookupString(), which handles Num Lock. With tk useinputmethods 0 Tk still reported KP_Left for keypad 4 with Num Lock on. Fix in branch [27ce67ba14]: TkpGetKeySym() selects the keypad keysym with Num Lock as XLookupString() does.


lvirden added on 2005-03-24 02:49:57:
Logged In: YES 
user_id=15949

Jeff, I just got a report from a staff member who is running
a PC with exceed connecting to a sparc.  In this
configuration, he says:

   When I execute the Tk 8.4.9 [modified with the patch
described in the current report] wish and view the results
on the PC with
Exceed, the numbers are correct when the NumLock is on, but
the cursor  movement does NOT happen when the NumLock is
off.  The Ins and Del associated with 0 and . DOES work
correctly, though.

lvirden added on 2005-03-23 20:13:04:
Logged In: YES 
user_id=15949

Okay, turns out that make wasn't remaking everything
necessary - after I did a make clean and make, the patch
seemed to work .

lvirden added on 2005-03-23 19:48:12:
Logged In: YES 
user_id=15949

I applied this patch to tk 8.4.9 and it still results in a
core dump

tfengler added on 2003-01-17 15:30:36:
Logged In: YES 
user_id=371805

Are you sure, that the module tkBind.c was compiled after
the changes.
My Change in tkInt.h is exactly one line above the
"modKeyCodes" array, where the program crashes in
Tk_BindEvent. It looks like the integer numlockModMask is
taken as an adress for the array of modKeyCodes and because
of that, the segmentation violation occurs.

When this is not the reason, then you could send me the two
changed files and I check them with your version of Tcl/Tk.
My email-adress is 
[email protected]

lvirden added on 2003-01-14 20:49:56:
Logged In: YES 
user_id=15949

I took your suggestion, applied the patch to the appropriate
place in the code, and get a Segmentation Violation from the
code.  Tcl and Tk were built with symbols and shared
libraries enabled, but nothing else.

 Here's the stack trace:

Tests began at Tue Jan 14 08:44:47 EST 2003
bell.test
Bell should ring now ...
bgerror.test
bind.test
Segmentation Fault - core dumped
make: *** [test] Error 139
srv23s4d (213) $ file core
core:           ELF 32-bit MSB core file SPARC Version 1,
from 'tktest'
srv23s4d (214) $ dbx tktest core
Reading tktest
core file header read successfully
Reading ld.so.1
Reading libtk8.4g.so
Reading libtcl8.4g.so
Reading libsocket.so.1
Reading libnsl.so.1
Reading libX11.so.4
Reading libdl.so.1
Reading libm.so.1
Reading libc.so.1
Reading libmp.so.2
Reading libXext.so.0
Reading libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault
address)
Current function is Tk_BindEvent
 1523               if (dispPtr->modKeyCodes[i] ==
eventPtr->xkey.keycode) {
(dbx 1) where                                                  
=>[1] Tk_BindEvent(bindingTable = 0x4b158, eventPtr =
0xefffaf44, tkwin = 0x169678, numObjects = 4, objectPtr =
0xefffad80), line 1523 in "tkBind.c"
  [2] TkBindEventProc(winPtr = 0x169678, eventPtr =
0xefffaf44), line 288 in "tkCmds.c"
  [3] Tk_HandleEvent(eventPtr = 0xefffaf44), line 1017 in
"tkEvent.c"
  [4] HandleEventGenerate(interp = 0x2ce78, mainWin =
0x43a20, objc = 2, objv = 0xefffb178), line 3793 in "tkBind.c"
  [5] Tk_EventObjCmd(clientData = 0x43a20, interp = 0x2ce78,
objc = 4, objv = 0xefffb170), line 2786 in "tkBind.c"
  [6] TclEvalObjvInternal(interp = 0x2ce78, objc = 4, objv =
0xefffb170, command = 0x15c624 "    event gen .b.f <Key-b>\n
   event gen .b.f <Key-x>\n    set x\n", length = 27, flags
= 0), line 3048 in "tclBasic.c"
  [7] Tcl_EvalEx(interp = 0x2ce78, script = 0x15c5c0 "\n   
setup\n    bind .b.f a {lappend x "%W %K .b.f press a"}\n  
 set x {}\n    event gen .b.f <Key-a>\n    event gen .b.f
<Key-b>\n    event gen .b.f <Key-x>\n    set x\n", numBytes
= 164, flags = 262144), line 3647 in "tclBasic.c"
  [8] Tcl_EvalObjEx(interp = 0x2ce78, objPtr = 0x12a0f8,
flags = 262144), line 3932 in "tclBasic.c"
  [9] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x2ce78,
objc = 1, objv = 0x2db08), line 674 in "tclProc.c"
  [10] TclEvalObjvInternal(interp = 0x2ce78, objc = 3, objv
= 0x2db00, command = (nil), length = 0, flags = 0), line
3048 in "tclBasic.c"
  [11] TclExecuteByteCode(interp = 0x2ce78, codePtr =
0x1151b0), line 1431 in "tclExecute.c"
  [12] TclCompEvalObj(interp = 0x2ce78, objPtr = 0xcbfb0),
line 1008 in "tclExecute.c"
  [13] TclObjInterpProc(clientData = 0x73310, interp =
0x2ce78, objc = 3, objv = 0x11d6b8), line 1082 in "tclProc.c"
  [14] TclEvalObjvInternal(interp = 0x2ce78, objc = 3, objv
= 0x11d6b8, command = 0xef5d4c90 "", length = 0, flags =
262144), line 3048 in "tclBasic.c"
  [15] Tcl_EvalObjv(interp = 0x2ce78, objc = 3, objv =
0x11d6b8, flags = 262144), line 3162 in "tclBasic.c"
  [16] Tcl_EvalObjEx(interp = 0x2ce78, objPtr = 0x1264b8,
flags = 262144), line 3929 in "tclBasic.c"
  [17] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x2ce78,
objc = 1, objv = 0x2dafc), line 674 in "tclProc.c"
  [18] TclEvalObjvInternal(interp = 0x2ce78, objc = 3, objv
= 0x2daf4, command = (nil), length = 0, flags = 0), line
3048 in "tclBasic.c"
  [19] TclExecuteByteCode(interp = 0x2ce78, codePtr =
0x116610), line 1431 in "tclExecute.c"
  [20] TclCompEvalObj(interp = 0x2ce78, objPtr = 0x696a8),
line 1008 in "tclExecute.c"
  [21] TclObjInterpProc(clientData = 0x73068, interp =
0x2ce78, objc = 3, objv = 0x11eb50), line 1082 in "tclProc.c"
  [22] TclEvalObjvInternal(interp = 0x2ce78, objc = 3, objv
= 0x11eb50, command = 0xef5d4c90 "", length = 0, flags =
262144), line 3048 in "tclBasic.c"
  [23] Tcl_EvalObjv(interp = 0x2ce78, objc = 3, objv =
0x11eb50, flags = 262144), line 3162 in "tclBasic.c"
  [24] Tcl_EvalObjEx(interp = 0x2ce78, objPtr = 0xd7d70,
flags = 262144), line 3929 in "tclBasic.c"
  [25] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x2ce78,
objc = 1, objv = 0x2daf0), line 674 in "tclProc.c"
  [26] TclEvalObjvInternal(interp = 0x2ce78, objc = 3, objv
= 0x2dae8, command = (nil), length = 0, flags = 0), line
3048 in "tclBasic.c"
  [27] TclExecuteByteCode(interp = 0x2ce78, codePtr =
0x118390), line 1431 in "tclExecute.c"
  [28] TclCompEvalObj(interp = 0x2ce78, objPtr = 0xcbf50),
line 1008 in "tclExecute.c"
  [29] TclObjInterpProc(clientData = 0x73270, interp =
0x2ce78, objc = 5, objv = 0xefffce88), line 1082 in "tclProc.c"
  [30] InvokeImportedCmd(clientData = 0xe10e8, interp =
0x2ce78, objc = 5, objv = 0xefffce88), line 1478 in
"tclNamesp.c"
  [31] TclEvalObjvInternal(interp = 0x2ce78, objc = 5, objv
= 0xefffce88, command = 0x134f48 "\ntest bind-13.1
{Tk_BindEvent procedure} {\n    setup\n    bind .b.f a
{lappend x "%W %K .b.f press a"}\n    set x {}\n    event
gen .b.f <Key-a>\n    event gen .b.f <Key-b>\n    event gen
.b.f <Key-x>\n    set x\n} {{.b.f a .b.f press a} {.b.f a
Test press a} {.b.f a all press any} {.b.f b Test press any}
{.b.f b all press any} {.b.f x Test press any} {.b.f x all
press x}}\n\nbind Test <KeyPress> {lappend x "%W %K Test
press any"; break}\nbind all <KeyPress> {continue; lappend x
"%W %K all press any"}\n\ntest bind-13.2" ..., length = 369,
flags = 0), line 3048 in "tclBasic.c"
  [32] Tcl_EvalEx(interp = 0x2ce78, script = 0x131be8 "#
This file is a Tcl script to test out Tk's "bind" and
"bindtags"\n# commands plus the procedures in tkBind.c.  It
is organized in the\n# standard fashion for Tcl tests.\n#\n#
Copyright (c) 1994 The Regents of the University of
California.\n# Copyright (c) 1994-1995 Sun Microsystems,
Inc.\n# Copyright (c) 1998-1999 by Scriptics Corporation.\n#
All rights reserved.\n#\n# RCS: @(#) $Id: bind.test,v 1.10
2002/07/14 05:48:45 dgp Exp $\n\npackage require tcltest
2.1\nnamespace import -force tcltest::configure\nnamespace
imp" ..., numBytes = 83776, flags = 0), line 3647 in
"tclBasic.c"
  [33] Tcl_FSEvalFile(interp = 0x2ce78, pathPtr = 0xd2d90),
line 1390 in "tclIOUtil.c"
  [34] Tcl_SourceObjCmd(dummy = (nil), interp = 0x2ce78,
objc = 2, objv = 0x7e3c0), line 1032 in "tclCmdMZ.c"
  [35] TclEvalObjvInternal(interp = 0x2ce78, objc = 2, objv
= 0x7e3c0, command = 0xef5d4c90 "", length = 0, flags =
262144), line 3048 in "tclBasic.c"
  [36] Tcl_EvalObjv(interp = 0x2ce78, objc = 2, objv =
0x7e3c0, flags = 262144), line 3162 in "tclBasic.c"
  [37] Tcl_EvalObjEx(interp = 0x2ce78, objPtr = 0xd7d10,
flags = 262144), line 3929 in "tclBasic.c"
  [38] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x2ce78,
objc = 1, objv = 0x2dae4), line 674 in "tclProc.c"
  [39] TclEvalObjvInternal(interp = 0x2ce78, objc = 3, objv
= 0x2dadc, command = (nil), length = 0, flags = 0), line
3048 in "tclBasic.c"
  [40] TclExecuteByteCode(interp = 0x2ce78, codePtr =
0xd4430), line 1431 in "tclExecute.c"
  [41] TclCompEvalObj(interp = 0x2ce78, objPtr = 0xcc130),
line 1008 in "tclExecute.c"
  [42] TclObjInterpProc(clientData = 0x73428, interp =
0x2ce78, objc = 1, objv = 0xefffdd40), line 1082 in "tclProc.c"
  [43] TclEvalObjvInternal(interp = 0x2ce78, objc = 1, objv
= 0xefffdd40, command = 0x6a119 "tcltest::runAllTests\n",
length = 21, flags = 0), line 3048 in "tclBasic.c"
  [44] Tcl_EvalEx(interp = 0x2ce78, script = 0x69eb8 "#
all.tcl --\n#\n# This file contains a top-level script to
run all of the Tk\n# tests.  Execute it by invoking "source
all.tcl" when running tktest\n# in this directory.\n#\n#
Copyright (c) 1998-1999 by Scriptics Corporation.\n#\n# See
the file "license.terms" for information on usage and
redistribution\n# of this file, and for a DISCLAIMER OF ALL
WARRANTIES.\n# \n# RCS: @(#) $Id: all.tcl,v 1.7 2002/07/14
05:48:45 dgp Exp $\n\npackage require Tcl 8.4\npackage
require tcltest 2.1\ntcltest::configure -testdir [file join
[p" ..., numBytes = 630, flags = 0), line 3647 in "tclBasic.c"
  [45] Tcl_FSEvalFile(interp = 0x2ce78, pathPtr = 0x56210),
line 1390 in "tclIOUtil.c"
  [46] Tcl_EvalFile(interp = 0x2ce78, fileName = 0x37530
"/vol/tclsrcsol/tcl84/tk/unix/../tests/all.tcl"), line 234
in "tclIOUtil.c"
  [47] Tk_MainEx(argc = 3, argv = 0xefffe3d8, appInitProc =
0x12cf0 = &Tcl_AppInit(Tcl_Interp *interp), interp =
0x2ce78), line 233 in "tkMain.c"
  [48] main(argc = 4, argv = 0xefffe3d4), line 68 in
"tkAppInit.c"
(dbx 2)

tfengler added on 2003-01-10 16:11:26:
Logged In: YES 
user_id=371805

The patch can only be applied to the version 1.5 of
tkUnixKey.c and version 1.40 of tkInt.h
Both files have changed since I made the patchfile, so the
line numbers doesn't fit anymore.
In  the new Version of tkUnixKey, my changes begin in line
244 instead of 184, in the new version of tkInt.h in line
157 instead of  132.
The patch is relatively simple, perhaps it can be applied
manually

lvirden added on 2003-01-10 01:12:33:
Logged In: YES 
user_id=15949

Note that with the very latest Tk 8.4.1 (today, Jan 9), when
I apply the patch to a completely fresh copy of the source,
configure the code and build it, the bind test suite code
crashes wish.  Without this patch applied, no crash occurs.
 Again, this is on SPARC Solaris 2.6 (with CDE desktop).

lvirden added on 2003-01-07 03:09:42:
Logged In: YES 
user_id=15949

yes, I tried both with and without the num lock on.

I used the script:

entry .e
pack .e

then clicked focus into the entry.  I started this two
times, once with the num lock on before I started and once
without it on.

hobbs added on 2003-01-07 03:06:43:
Logged In: YES 
user_id=72656

Did you have the numlock on?

lvirden added on 2003-01-07 02:55:20:
Logged In: YES 
user_id=15949

After applying this patch to Tk 8.4.1 CVS head, I did a make
clean and make.

The resulting wish, built on Solaris 2.6 and ran against a
CDE desktop, continues to display a problem getting the
numeric keys to be recognized with the num lock key on.  The
4 and 6 keys are treated by Tk as right and left arrows
instead of as the numbers 4 and 6.

tfengler added on 2002-01-05 02:14:01:
Logged In: YES 
user_id=371805

It's 220938, not 229038, sorry

hobbs added on 2001-12-28 02:09:46:
Logged In: YES 
user_id=72656

I can't find a 229038, but related bugs are:

[ #220018 ] Numeric Key Pad bindings do not work as expected

[ #220837 ] keypad 4 does not generates "left" keysym

tfengler added on 2001-11-13 21:53:35:

File Added - 13261: patch_tkUnixKey.c

Attachments: