From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 Description of problem: I am attempting to encode keypad keys using xmodmap I can switch keys around with no problems However if I use for example i.e. xmodmap -verbose -e "keycode 79=Undo" or xmodmap -verbose -e "keycode 79=0xff65" it should program the Keypad Key 7 with \e[26~ which is defined as Undo which for example I have programed emacs to understand as Undo. xev and xmodmap -pk says I have encoded Undo but when I press the key I get a null string. I get null string even reading the key input from a simple program. If I encode a keysym which I see in the xmodmap -pk listing on the Linux system then that switch works. However if the keysym is not in that small list such as Undo (F27) which xmodmap however does recognize as 0xff65 then it does not work. i.e. I can't program new escape sequences not on my linux keyboard, even those which have been associated with standard symbols. I am using RedHat 7.3 with Ximian Gnome 2.0 but I see the same error on RedHat 6.2 or 8.0 using standard Gnome Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. xmodmap -verbose -e "keycode 79=Undo" 2. press keypad 7 3. Actual Results: Null string returned Expected Results: generate the encoded escape sequence \esc[26~ Additional info: I have personalized my keyboard for emacs on a SunSPARC, and this works even via remote SSH login to this Linux PC from the SunSPARC. I am trying to get similer mapping working directly on linux PC
Your report is more of a technical support request than a bug report per se, however we do not provide technical support via bugzilla. My recommendation, is to post your above problem on the XFree86 mailing list at xfree86 and seek assistance there. More than likely someone will be able to assist you with your problem, or help correct any misconfigurations or misunderstandings that you might be having. It's unlikely IMHO to be a bug, however in the event that it does turn out to be a bug, it would have to be reproduced in Red Hat Linux 9 with XFree86 4.3.0 first, or alternatively by a custom built 4.3.0 in Red Hat Linux 7.3, after which a bug report should be filed directly to XFree86.org at: http://bugs.xfree86.org Closing as NOTABUG for the time being. If the XFree86 team determines that it is a bug after your posting to the mailing list, once you've filed a bug report at the above URL, feel free to reopen this bug report and paste the URL here of the upstream report and I will track it. Thanks.