| 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:
- patch_tkUnixKey.c [download] added by tfengler on 2001-11-13 21:53:34. [details]
