Summary: | xterm fails to start when eightBitInput resource is false | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander Meyer <ali> |
Component: | Current packages | Assignee: | Seemant Kulleen (RETIRED) <seemant> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ali, dickey |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | PPC | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alexander Meyer
2005-08-04 07:26:53 UTC
Please everyone, test xterm-204 that just went into this tree to see if it solves any of your issues. It works pretty nicely for me. Adding Thomas to cc. This sounds like the fix in #201 for Debian #298551. (In reply to comment #3) > This sounds like the fix in #201 for Debian #298551. exactly. but #201 isn't in my portage-tree and #202 (which was masked) didn't solve the issue. it just seemed to ignore the "eightBitInput" resource and thus didn't recognize the meta-keys regardless of the resource being set to true or false. i'll try #204 as suggested and report on the results as soon as i get home. Recognizing the meta-key and starting with eightBitInput are really two separate issues. For some cases, the meta-key won't be recognized, and I had added a metaSendsEscape resource to address that. Since it's been a while since I made changes to the handling of meta-keys, I'd need more information to see how to respond to that (whether it's an xterm bug, or X libraries, or configuration, et). i tried the 204 ebuild and it behaves the same way as the 202 ebuilds. they would start with the eightBitInput recource set to false but the resource had no effect. also trying all possible combinations of eightBitInput and metaSendsEscape did not help anything. Well bear in mind that I maintain xterm and am not running GenToo. So I'm not familiar with the details of the ebuild. But when I test xterm's eightBitInput option, it does what I expect it to. Here's what I have in xmodmap - the alt key is functioning as the meta key. Your configuration would probably be different. If I'm testing a bug, I compile xterm using the --enable-trace option of the configure script. That logs the information that it uses to decide which key is the meta key, etc: xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Alt_L (0x7d), Meta_L (0x9c) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x7f), Hyper_L (0x80) mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x7c) after tweaking my .xmodmap the alt-keys now send the proper escape-sequences and everything is working fine. the bug from versionn #200 is solved since xterm no longer crashes when the eightBitinput resource is set to false in version #204. so regarding to me this bug is solved (at least in version #204). it is still present in #200 though so i'll leave the bug-status untouched and leave the decision about what to do whith it to the maintainer. thanks for your help everyone! Arch teams -- xterm-204 is a candidate for stabling Stable on ppc Sorry, forgot to remove ppc@g.o Stable on x86 Stable on alpha Cheers Ferdy stable on ppc64 sparc stable. Stable on mips. thanks arch teams |