xlibs: modifier madness breaks XTerm*metaSendsEscape
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xorg (Debian) |
Fix Released
|
Unknown
|
|||
xorg (Ubuntu) |
Invalid
|
High
|
Fabio Massimo Di Nitto |
Debian Bug Importer (debzilla) wrote : | #1 |
Debian Bug Importer (debzilla) wrote : | #2 |
Message-ID: <email address hidden>
Date: Mon, 19 Jul 2004 14:58:34 -0400
From: Thomas Dickey <email address hidden>
To: <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Mon, Jul 19, 2004 at 04:30:13PM +0200, Guido Guenther wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-6
> Severity: normal
>=20
> Hi,
> the above is no longer working after an upgrade to the versions below.
> Before that I could use: Alt-f, Alt-b to jump whole words forward or
> backward in a bash running within xterm. This doesn't work anymore,
> ESC-f, ESC-b still works though. Any ideas where to start digging?
man xterm
metaSendsEscape
--=20
Thomas E. Dickey
http://
ftp://invisible
--r5Pyd7+fXNt84Ff3
Content-Type: application/
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://
iD8DBQFA/
YWaB+EJZc3lOonA
=ko52
-----END PGP SIGNATURE-----
--r5Pyd7+
Debian Bug Importer (debzilla) wrote : | #3 |
Message-ID: <email address hidden>
Date: Mon, 19 Jul 2004 16:24:08 -0400
From: Thomas Dickey <email address hidden>
To: <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--UugvWAfsgieZRqgk
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Mon, Jul 19, 2004 at 04:30:13PM +0200, Guido Guenther wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-6
> Severity: normal
>=20
> Hi,
> the above is no longer working after an upgrade to the versions below.
> Before that I could use: Alt-f, Alt-b to jump whole words forward or
> backward in a bash running within xterm. This doesn't work anymore,
> ESC-f, ESC-b still works though. Any ideas where to start digging?
I don't think the problem is within xterm (it's been a while since I tweaked
the logic for this). More likely something in the keyboard configuration
has separated the definitions that you were relying upon. What I do to
debug this is to use xev and ensure that it's reporting "Meta_L" for the
key. If that's right, I generally compile a debug version of xterm
(configure --enable-trace) and check the initialization of the modifiers.
I did check over this recently and recall that there was some issue where
one could accidentally setup a conflict that would make xterm not do meta.
But that also showed up in xmodmap's display.
--=20
Thomas E. Dickey
http://
ftp://invisible
--UugvWAfsgieZRqgk
Content-Type: application/
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://
iD8DBQFA/
32H2OggHID+
=vLtv
-----END PGP SIGNATURE-----
--UugvWAfsgieZR
Debian Bug Importer (debzilla) wrote : | #4 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 08:45:49 +0200
From: Guido Guenther <email address hidden>
To: Thomas Dickey <email address hidden>, <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
Hi Thomas,
On Mon, Jul 19, 2004 at 02:58:34PM -0400, Thomas Dickey wrote:
> > the above is no longer working after an upgrade to the versions below.
> > Before that I could use: Alt-f, Alt-b to jump whole words forward or
> > backward in a bash running within xterm. This doesn't work anymore,
> > ESC-f, ESC-b still works though. Any ideas where to start digging?
>
> man xterm
> metaSendsEscape
I'm not sure I understand this. I have this on, and it stopped working
recently, I can't find any hint in the manpage, for the cause of this.
Cheers,
-- Guido
Debian Bug Importer (debzilla) wrote : | #5 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 08:57:09 +0200
From: Guido Guenther <email address hidden>
To: Thomas Dickey <email address hidden>, <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
On Mon, Jul 19, 2004 at 04:24:08PM -0400, Thomas Dickey wrote:
> I don't think the problem is within xterm (it's been a while since I tweaked
> the logic for this). More likely something in the keyboard configuration
> has separated the definitions that you were relying upon. What I do to
> debug this is to use xev and ensure that it's reporting "Meta_L" for the
> key. If that's right, I generally compile a debug version of xterm
It is. I already checked this before sending the report.
> (configure --enable-trace) and check the initialization of the modifiers.
Thanks, I'll try that.
As a related problem mouse button emulation also stopped working in
xterm. Mouseemu is a user space programm using the kernel's
/dev/input/event layer to emulate say right mouseclicks using e.g.
<CTRL>-<left click>. This still works in GTK based apps but no longer
in xterm. I don't intend to mix bug reports here, but showed up at the
same time and is also related to "modifier" keys.
Cheers,
-- Guido
Debian Bug Importer (debzilla) wrote : | #6 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 09:13:59 +0200
From: Guido Guenther <email address hidden>
To: Thomas Dickey <email address hidden>, <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--f2QGlHpHGjS2mn6Y
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Mon, Jul 19, 2004 at 04:24:08PM -0400, Thomas Dickey wrote:
> I don't think the problem is within xterm (it's been a while since I twea=
ked
> the logic for this). More likely something in the keyboard configuration
> has separated the definitions that you were relying upon. What I do to
> debug this is to use xev and ensure that it's reporting "Meta_L" for the
> key. If that's right, I generally compile a debug version of xterm
> (configure --enable-trace) and check the initialization of the modifiers.
Trace says about Meta:
=20
~Meta<KeyPress>: insert-seven-bit()
Meta<KeyPress>: insert-eight-bit()
~Meta<ButtonPre
Button1~
~Ctrl~Meta<
Meta<ButtonPre
~Ctrl~Meta<
~Ctrl~Meta<
Button3~
~Meta<KeyPress>: insert-seven-bit()
Meta<KeyPress>: insert-eight-bit()
~Meta<ButtonPre
Button1~
~Ctrl~Meta<
Meta<ButtonPre
~Ctrl~Meta<
~Ctrl~Meta<
Button3~
Anything else I can provide?
Cheers,
-- Guido
--f2QGlHpHGjS2mn6Y
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA/
OZdUfOtLG+
=0QVG
-----END PGP SIGNATURE-----
--f2QGlHpHGjS2m
Debian Bug Importer (debzilla) wrote : | #7 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 05:38:21 -0400
From: Thomas Dickey <email address hidden>
To: Guido Guenther <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Tue, Jul 20, 2004 at 09:13:59AM +0200, Guido Guenther wrote:
> On Mon, Jul 19, 2004 at 04:24:08PM -0400, Thomas Dickey wrote:
> > I don't think the problem is within xterm (it's been a while since I tw=
eaked
> > the logic for this). More likely something in the keyboard configurati=
on
> > has separated the definitions that you were relying upon. What I do to
> > debug this is to use xev and ensure that it's reporting "Meta_L" for the
> > key. If that's right, I generally compile a debug version of xterm
> > (configure --enable-trace) and check the initialization of the modifier=
s.
> Trace says about Meta:
> =20
> ~Meta<KeyPress>: insert-seven-bit()
Trace-parent.out has a lot of information - the fragment you're showing
tells what it can find about the translations resource. The piece I'm
interested in corresponds to the xmodmap settings, e.g., (starting with
"VTInitModifiers"):
looking for style 'Root'
VTInitModifiers
alt_left mask 0x8 is Mod1 modifier
alt_right mask 0x8 is Mod1 modifier
TranslationsUse
xterm looks to see which modifiers are associated with the Alt, Meta and
NumLock keys so that when it gets a keypress event, it can look at the
modifier information in that event and determine which of those keys
might have been used for modifying the key. (Technically, I should also
look for the control and shift keys, but it is unusual for someone to
change _those_ with xmodmap). In the example I just gave, there's no
Meta key associated with a modifier - so metaSendsEscape wouldn't work.
The trace is there of course for debugging - it's also possible that
xterm would find the modifiers but do something unexpected with them.
All of the logic dealing with the modifiers is in input.c, so it's not
hard to follow...
--=20
Thomas E. Dickey
http://
ftp://invisible
--dDRMvlgZJXvWKvBx
Content-Type: application/
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://
iD8DBQFA/
L3SS0zhcqQ9RHjS
=jh7i
-----END PGP SIGNATURE-----
--dDRMvlgZJXvWK
Debian Bug Importer (debzilla) wrote : | #8 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 13:10:56 +0200
From: Guido Guenther <email address hidden>
To: Thomas Dickey <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--2Z2K0IlrPCVsbNpk
Content-Type: text/plain; charset=us-ascii
Content-
On Tue, Jul 20, 2004 at 05:38:21AM -0400, Thomas Dickey wrote:
> looking for style 'Root'
> VTInitModifiers
> alt_left mask 0x8 is Mod1 modifier
> alt_right mask 0x8 is Mod1 modifier
> TranslationsUse
Mine says:
VTInitModifiers
meta_left mask 0x8 is Mod1 modifier
alt_right mask 0x8 is Mod1 modifier
num_lock mask 0x10 is Mod2 modifier
meta_right mask 0x40 is Mod4 modifier
Which looks sane as far as I can tell. I don't think that this helps
much, but it seems that gnome-terminal still handels this correctly.
Let me know if I can provide any more interesting data.
Cheers,
-- Guido
--2Z2K0IlrPCVsbNpk
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA/
3p6mlkbTduw+
=PzEq
-----END PGP SIGNATURE-----
--2Z2K0IlrPCVsb
Debian Bug Importer (debzilla) wrote : | #9 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 07:44:52 -0400
From: Thomas Dickey <email address hidden>
To: Guido Guenther <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--envbJBWh7q8WU6mo
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Tue, Jul 20, 2004 at 01:10:56PM +0200, Guido Guenther wrote:
> On Tue, Jul 20, 2004 at 05:38:21AM -0400, Thomas Dickey wrote:
> > looking for style 'Root'
> > VTInitModifiers
> > alt_left mask 0x8 is Mod1 modifier
> > alt_right mask 0x8 is Mod1 modifier
> > TranslationsUse
> Mine says:
>=20
> VTInitModifiers
> meta_left mask 0x8 is Mod1 modifier
> alt_right mask 0x8 is Mod1 modifier
> num_lock mask 0x10 is Mod2 modifier
> meta_right mask 0x40 is Mod4 modifier
>=20
> Which looks sane as far as I can tell. I don't think that this helps
> much, but it seems that gnome-terminal still handels this correctly.
> Let me know if I can provide any more interesting data.
for now that looks like enough - I'll look closer when I get home (and
can look up the history of that slice of code). Just reading the source
right now, I do see a couple of things to investigate.
--=20
Thomas E. Dickey
http://
ftp://invisible
--envbJBWh7q8WU6mo
Content-Type: application/
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://
iD8DBQFA/
1FZ2ZPjcz2D0+
=lcxS
-----END PGP SIGNATURE-----
--envbJBWh7q8WU
Debian Bug Importer (debzilla) wrote : | #10 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 20:15:28 -0400
From: Thomas Dickey <email address hidden>
To: Guido Guenther <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Tue, Jul 20, 2004 at 01:10:56PM +0200, Guido Guenther wrote:
> On Tue, Jul 20, 2004 at 05:38:21AM -0400, Thomas Dickey wrote:
> > looking for style 'Root'
> > VTInitModifiers
> > alt_left mask 0x8 is Mod1 modifier
> > alt_right mask 0x8 is Mod1 modifier
> > TranslationsUse
> Mine says:
>=20
> VTInitModifiers
> meta_left mask 0x8 is Mod1 modifier
> alt_right mask 0x8 is Mod1 modifier
> num_lock mask 0x10 is Mod2 modifier
> meta_right mask 0x40 is Mod4 modifier
>=20
> Which looks sane as far as I can tell. I don't think that this helps
> much, but it seems that gnome-terminal still handels this correctly.
> Let me know if I can provide any more interesting data.
One possibility (which I read on one of the newsgroups a few years ago)
is that detecting modifiers doesn't work if you try using one of the
pairs of keys such as Alt_L as a meta key. (I don't recall the explanation,
other than that it was a limitation of the way the modifier information is
stored).
I just setup a case like that, and indeed it doesn't work. For instance,
using this with xmodmap:
keycode 115 =3D Meta_L
add mod1 =3D Meta_L
remove mod1 =3D Alt_L
produces this output from xmodmap (but I'm puzzled by the stray "," which
looks as if I have more work to do):
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_R (0x71), Meta_L (0x73)
mod2 Num_Lock (0x4d)
mod3
mod4 Meta_L (0x73), Super_R (0x74)
mod5
and in xterm's trace I have
VTInitModifiers
alt_right mask 0x8 is Mod1 modifier
meta_left mask 0x8 is Mod1 modifier
num_lock mask 0x10 is Mod2 modifier
meta_left mask 0x48 is Mod1 modifier
TranslationsUse
so that might be roughly what you have. Checking the rest of Trace-parent.=
out,
I don't see any modifiers when I press left-alt (meta). The lines beginning
"Input keysym" would show any modifiers that are in the event. In the
text below, I pressed left-alt + 'm' twice (no mod1), but pressing right-alt
with 'm' got a modifier.
Input keysym 0xFFE9, 0:'' 7bit
Input keysym 0x006D, 1:'m' 7bit
Input keysym 0x006D, 1:'m' 7bit
Input keysym 0xFFEA, 0:'' 7bit
Input keysym 0x006D, 1:'m' 7bit
Input keysym 0x006D, 1:'m' 7bit
Input keysym 0xFFE4, 0:'' 7bit
Input keysym 0x006D, 1:'^M' Control 7bit
Input keysym 0x006D, 1:'^M' Control 7bit
Input keysym 0xFFE7, 0:'' 7bit
Input keysym 0x006D, 1:'m' Mod1 Mod4 8bit
Input keysym 0x006D, 1:'m' Mod1 Mod4 8bit
Input keysym 0xFFE3, 0:'' 7bit
Input keysym 0x0064, 1:'^D' Control 7bit
Input keysym 0x0064, 1:'^D' Control 7bit
gnome-terminal might be trapping the keypress events (something to check on=
),
or getting the inf...
Debian Bug Importer (debzilla) wrote : | #11 |
Message-ID: <email address hidden>
Date: Tue, 20 Jul 2004 20:50:53 -0400
From: Thomas Dickey <email address hidden>
To: Guido Guenther <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Backing up a little, I did this:
keycode 0x40 =3D Meta_L Alt_L
and got xmodmap's output a little saner:
xmodmap: up to 2 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 Meta_L (0x40), Alt_R (0x71)
mod2 Num_Lock (0x4d)
mod3
mod4 Super_L (0x73), Super_R (0x74)
mod5
and my resulting trace is working fine:
VTInitModifiers
meta_left mask 0x8 is Mod1 modifier
alt_right mask 0x8 is Mod1 modifier
num_lock mask 0x10 is Mod2 modifier
TranslationsUse
and (using left-alt as meta):
Handle 8bit-key
Input keysym 0x006D, 1:'m' Mod1 8bit
=2E..input-char is modified by META =20
I also see right-alt interpreted as meta since they have the same modifier.
That could be surprising if one isn't reading the debug trace.
I don't use xmodmap often, so it does take some practice and experimentatio=
n.
On my keyboard, I don't see a Meta_L or Meta_R by default, so adding it does
require xmodmap.
--=20
Thomas E. Dickey
http://
ftp://invisible
--zYM0uCDKw75PZbzx
Content-Type: application/
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://
iD8DBQFA/
CRgcaVMXRv3wSw3
=8yRI
-----END PGP SIGNATURE-----
--zYM0uCDKw75PZ
Debian Bug Importer (debzilla) wrote : | #12 |
Message-ID: <email address hidden>
Date: Wed, 21 Jul 2004 11:19:30 +0200
From: Guido Guenther <email address hidden>
To: Thomas Dickey <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--pf9I7BMVVzbSWLtt
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Hi Thomas,
On Tue, Jul 20, 2004 at 08:50:53PM -0400, Thomas Dickey wrote:
> shift Shift_L (0x32), Shift_R (0x3e)
> lock Caps_Lock (0x42)
> control Control_L (0x25), Control_R (0x6d)
> mod1 Meta_L (0x40), Alt_R (0x71)
> mod2 Num_Lock (0x4d)
> mod3
> mod4 Super_L (0x73), Super_R (0x74)
> mod5
Mine always looked like this:
xmodmap: up to 2 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 Meta_L (0x40), Alt_R (0x71)
mod2 Num_Lock (0x4d)
mod3 =20
mod4 Multi_key (0x73), Meta_R (0x74)
mod5 Scroll_Lock (0x77)
which looks sane to me. Here's the (maybe) interesting part: When I
press <ALT>, I see:
=20
Input keysym 0xFFE7, 0:'' 7bit
Handle 7bit-key
But when I then press f (while holding down ALT) no output appears in
the log at all, although I have:
meta_left mask 0x8 is Mod1 modifier
alt_right mask 0x8 is Mod1 modifier
num_lock mask 0x10 is Mod2 modifier
meta_right mask 0x40 is Mod4 modifier
in my logs, which looks also okay to me.
Puzzled,
-- Guido
--pf9I7BMVVzbSWLtt
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA/
oEWfC2yA5NS+
=KWYj
-----END PGP SIGNATURE-----
--pf9I7BMVVzbSW
Debian Bug Importer (debzilla) wrote : | #13 |
Message-ID: <email address hidden>
Date: Wed, 21 Jul 2004 05:44:32 -0400
From: Thomas Dickey <email address hidden>
To: Guido Guenther <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Wed, Jul 21, 2004 at 11:19:30AM +0200, Guido Guenther wrote:
> Hi Thomas,
> On Tue, Jul 20, 2004 at 08:50:53PM -0400, Thomas Dickey wrote:
> > shift Shift_L (0x32), Shift_R (0x3e)
> > lock Caps_Lock (0x42)
> > control Control_L (0x25), Control_R (0x6d)
> > mod1 Meta_L (0x40), Alt_R (0x71)
> > mod2 Num_Lock (0x4d)
> > mod3
> > mod4 Super_L (0x73), Super_R (0x74)
> > mod5
> Mine always looked like this:
yes (am not at home, but from memory): your Meta_L looks like my Alt_L
before I reassigned it. Reading last night, I see some comments that
give me the impression that the order of definition (i.e., which xmodmap
command was done first) is the problem, that the last one is the one
that takes effect.
I've seen a few comments by Branden Robinson which seem to indicate that
some change has been made in the keyboard configuration (perhaps that's
related to this). I'm cc'ing him to see if he has any insight on this.
When I started looking into this a week ago, I could see that (for my
keyboard at least), the left/right Alt keys are used for the cases where
the *VT100.translations resource says "Meta". Looking at the X library
code, that seems consistent. Google finds a large number of comments that
indicate that Alt and Meta have been used almost interchangeably, and that
depending on the keyboard configuration they're sometimes just interchanged
at the whim of the person doing the keyboard support.
=20
> xmodmap: up to 2 keys per modifier, (keycodes in parentheses):
>=20
> shift Shift_L (0x32), Shift_R (0x3e)
> lock Caps_Lock (0x42)
> control Control_L (0x25), Control_R (0x6d)
> mod1 Meta_L (0x40), Alt_R (0x71)
> mod2 Num_Lock (0x4d)
> mod3 =20
> mod4 Multi_key (0x73), Meta_R (0x74)
> mod5 Scroll_Lock (0x77)
>=20
> which looks sane to me. Here's the (maybe) interesting part: When I
> press <ALT>, I see:
> =20
> Input keysym 0xFFE7, 0:'' 7bit
> Handle 7bit-key
Is that <ALT> the same as one of your Meta_L or Alt_R keys?
xev could identify that. What your trace seems to indicate to me
is that the mod1 for Meta_L isn't having a real effect, so the literal
key is sent to xterm. That should show up in xev's trace (though xev
doesn't show the modifier information, it should show a "Alt_L" or "Meta_L"=
).
=20
> But when I then press f (while holding down ALT) no output appears in
> the log at all, although I have:
>=20
> meta_left mask 0x8 is Mod1 modifier
> alt_right mask 0x8 is Mod1 modifier
> num_lock mask 0x10 is Mod2 modifier
> meta_right mask 0x40 is Mod4 modifier
>=20
> in my logs, which looks also okay to me.
> Puzzled,
> -- Guido
--=20
Thomas E. Dickey
http://
ftp://invisible
--ik...
Debian Bug Importer (debzilla) wrote : | #14 |
Message-ID: <email address hidden>
Date: Wed, 21 Jul 2004 15:14:07 +0200
From: Guido Guenther <email address hidden>
To: Thomas Dickey <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--+g7M9IMkV8truYOl
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Wed, Jul 21, 2004 at 05:44:32AM -0400, Thomas Dickey wrote:
> > which looks sane to me. Here's the (maybe) interesting part: When I
> > press <ALT>, I see:
> > =20
> > Input keysym 0xFFE7, 0:'' 7bit
> > Handle 7bit-key
>=20
> Is that <ALT> the same as one of your Meta_L or Alt_R keys?
I mean the key labeled "alt" on the keyboard. On my Mac Keyboard:
keycode 64, keysym 0xffe7. It has the modifier ALT_L assigned by default
and I change that via:
keysym Alt_L =3D Meta_L Alt_L
which works according to xev.
> xev could identify that. What your trace seems to indicate to me
> is that the mod1 for Meta_L isn't having a real effect, so the literal
> key is sent to xterm. That should show up in xev's trace (though xev
> doesn't show the modifier information, it should show a "Alt_L" or "Meta_=
L").
When I do:
xmodmap -e 'keycode 64 =3D Alt_L' (removing the Meta_L) *it works* again.
So it seems it's actually not "Meta sends escape" anymore but rather
"Alt sends escape".
This is a change in behaviour which we should at least document somewhere
in the debian package before closing the bug.
I'm still having some problems with my <apple-key>-click =3D "middle
click" emulation, which completely confuses xterm at the moment (and
which showed up at the same time than the above problem), but I'll have
to dig deeper into this before reporting this as a bug.
Thanks _very_ much for your help,
-- Guido
--+g7M9IMkV8truYOl
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA/
MaOwN86/
=Fhq5
-----END PGP SIGNATURE-----
--+g7M9IMkV8tru
Debian Bug Importer (debzilla) wrote : | #15 |
Message-ID: <email address hidden>
Date: Wed, 21 Jul 2004 09:49:08 -0400
From: Thomas Dickey <email address hidden>
To: Guido Guenther <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Wed, Jul 21, 2004 at 03:14:07PM +0200, Guido Guenther wrote:
> On Wed, Jul 21, 2004 at 05:44:32AM -0400, Thomas Dickey wrote:
> > > which looks sane to me. Here's the (maybe) interesting part: When I
> > > press <ALT>, I see:
> > > =20
> > > Input keysym 0xFFE7, 0:'' 7bit
> > > Handle 7bit-key
> >=20
> > Is that <ALT> the same as one of your Meta_L or Alt_R keys?
> I mean the key labeled "alt" on the keyboard. On my Mac Keyboard:
> keycode 64, keysym 0xffe7. It has the modifier ALT_L assigned by default
> and I change that via:
> keysym Alt_L =3D Meta_L Alt_L
> which works according to xev.
ok - that (difference in PC versus other keyboards) was one of the comments
that google found which illustrates the alt/meta issue.
=20
> > xev could identify that. What your trace seems to indicate to me
> > is that the mod1 for Meta_L isn't having a real effect, so the literal
> > key is sent to xterm. That should show up in xev's trace (though xev
> > doesn't show the modifier information, it should show a "Alt_L" or "Met=
a_L").
> When I do:
> xmodmap -e 'keycode 64 =3D Alt_L' (removing the Meta_L) *it works* again.
> So it seems it's actually not "Meta sends escape" anymore but rather
> "Alt sends escape".
ok. I don't see anyplace in xterm that I could improve on here
(since it sees only one of the alt/meta definitions). There is
some provision for keys having more than one name and modifier
(which may have issues to resolve).
Does gnome-terminal still work if you remove the definition for Meta_L?
> This is a change in behaviour which we should at least document somewhere
> in the debian package before closing the bug.
>=20
> I'm still having some problems with my <apple-key>-click =3D "middle
> click" emulation, which completely confuses xterm at the moment (and
> which showed up at the same time than the above problem), but I'll have
> to dig deeper into this before reporting this as a bug.
>=20
> Thanks _very_ much for your help,
no problem (though it doesn't seem that it's solved yet)
--=20
Thomas E. Dickey
http://
ftp://invisible
--Qxx1br4bt0+wmkIi
Content-Type: application/
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://
iD8DBQFA/
ndNosq9wKel0YhO
=gyXa
-----END PGP SIGNATURE-----
--Qxx1br4bt0+
Debian Bug Importer (debzilla) wrote : | #16 |
Message-ID: <email address hidden>
Date: Wed, 21 Jul 2004 15:48:57 +0200
From: Guido Guenther <email address hidden>
To: Thomas Dickey <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--WChQLJJJfbwij+9x
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Wed, Jul 21, 2004 at 09:49:08AM -0400, Thomas Dickey wrote:
> ok. I don't see anyplace in xterm that I could improve on here
> (since it sees only one of the alt/meta definitions). There is
> some provision for keys having more than one name and modifier
> (which may have issues to resolve).
>=20
> Does gnome-terminal still work if you remove the definition for Meta_L?
Yes.
-- Guido
--WChQLJJJfbwij+9x
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA/
JUCF+IwRua4nZvB
=bzea
-----END PGP SIGNATURE-----
--WChQLJJJfbwij
Debian Bug Importer (debzilla) wrote : | #17 |
Message-ID: <email address hidden>
Date: Wed, 21 Jul 2004 21:57:33 -0500
From: Branden Robinson <email address hidden>
To: Thomas Dickey <email address hidden>
Cc: Guido Guenther <email address hidden>, <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--fckbADODYWZD5TdN
Content-Type: text/plain; charset=us-ascii
Content-
Content-
On Wed, Jul 21, 2004 at 05:44:32AM -0400, Thomas Dickey wrote:
> I've seen a few comments by Branden Robinson which seem to indicate that
> some change has been made in the keyboard configuration (perhaps that's
> related to this). I'm cc'ing him to see if he has any insight on this.
Yes; it's a long, complex story.
Basically, in 4.3.0.dfsg.1-5 we backported from XFree86 CVS a fix by Ivan
Pascal for problems with modifier keys when using multiple keyboard layouts
at once.
A kludge to restore the most grievously affected functionality was applied
in -6, but a real fix is still forthcoming.
The details are absurdly technical (and in part have to do with a lot of
clients using only core X protocol functions for querying the keyboard
despite this XKB era), and I don't have a full command of them myself, but
I think I know what to do to make some better headway.
I've begun consulting with Ivan Pascal on this subject, and he's been quite
helpful.
--=20
G. Branden Robinson | I am only good at complaining.
Debian GNU/Linux | You don't want me near your code.
<email address hidden> | -- Dan Jacobson
http://
--fckbADODYWZD5TdN
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iEYEARECAAYFAkD
ph8AoIMCXSA52jG
=SZB+
-----END PGP SIGNATURE-----
--fckbADODYWZD5
Debian Bug Importer (debzilla) wrote : | #18 |
Message-ID: <email address hidden>
Date: Tue, 27 Jul 2004 01:39:40 -0500
From: Branden Robinson <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--4Ycl1UgPPPgGZoSL
Content-Type: text/plain; charset=us-ascii
Content-
Content-
tag 260232 + moreinfo
thanks
On Mon, Jul 19, 2004 at 04:06:28PM +0200, Guido Guenther wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-6
> Severity: normal
>=20
> Hi,
> the above is no longer working after an upgrade to the versions below.
> Before that I could use: Alt-f, Alt-b to jump whole words forward or
> backward in a bash running within xterm. This doesn't work anymore,
> ESC-f, ESC-b still works though. Any ideas where to start digging?
> Cheers,
> -- Guido
>=20
> P.S.: I'm additionally using:
> keysym Alt_L =3D Meta_L Alt_L
> to make the above work.
Try downgrading xlibs to 4.3.0.dfsg.1-4.
If that fixes it, this bug is the probably the same as #256706.
--=20
G. Branden Robinson | I just wanted to see what it looked
Debian GNU/Linux | like in a spotlight.
<email address hidden> | -- Jim Morrison
http://
--4Ycl1UgPPPgGZoSL
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iEYEARECAAYFAkE
9SwAn3hssPDU08J
=vxYY
-----END PGP SIGNATURE-----
--4Ycl1UgPPPgGZ
Debian Bug Importer (debzilla) wrote : | #19 |
Message-ID: <email address hidden>
Date: Tue, 27 Jul 2004 11:41:23 +0200
From: Guido Guenther <email address hidden>
To: Branden Robinson <email address hidden>,
<email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--WIyZ46R2i8wDzkSu
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Hi,
On Tue, Jul 27, 2004 at 01:39:40AM -0500, Branden Robinson wrote:
> Try downgrading xlibs to 4.3.0.dfsg.1-4.
>=20
> If that fixes it, this bug is the probably the same as #256706.
Downgrading to the above version "fixes" it.
Cheers,
-- Guido
--WIyZ46R2i8wDzkSu
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBBiNDn88
jqgk6/Pb9P65Q3e
=OKuk
-----END PGP SIGNATURE-----
--WIyZ46R2i8wDz
Debian Bug Importer (debzilla) wrote : | #20 |
Message-ID: <email address hidden>
Date: Thu, 12 Aug 2004 17:06:29 -0500
From: Branden Robinson <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#260232: xterm: XTerm*metaSends
--C1iGAkRnbeBonpVg
Content-Type: text/plain; charset=us-ascii
Content-
Content-
retitle 256706 xlibs: attaching multiple modifiers to the same key wreaks h=
avoc; breaks Win+Tab switching in many window managers
retitle 260232 xlibs: modifier madness breaks XTerm*metaSends
reassign 260232 xlibs
severity 260232 serious
merge 256706 260232
On Tue, Jul 27, 2004 at 11:41:23AM +0200, Guido Guenther wrote:
> Hi,
> On Tue, Jul 27, 2004 at 01:39:40AM -0500, Branden Robinson wrote:
> > Try downgrading xlibs to 4.3.0.dfsg.1-4.
> >=20
> > If that fixes it, this bug is the probably the same as #256706.
> Downgrading to the above version "fixes" it.
Thanks for the feedback!
I'm merging this bug with an identical issue.
--=20
G. Branden Robinson |
Debian GNU/Linux | Please do not look directly into
<email address hidden> | laser with remaining eye.
http://
--C1iGAkRnbeBonpVg
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iEYEARECAAYFAkE
9f4AnjM21B/
=vmKB
-----END PGP SIGNATURE-----
--C1iGAkRnbeBon
Debian Bug Importer (debzilla) wrote : | #21 |
Marking as duplicate based on debbugs merge (256706,260232)
This bug has been marked as a duplicate of bug 6890.
Debian Bug Importer (debzilla) wrote : | #22 |
Message-Id: <email address hidden>
Date: Sat, 21 Aug 2004 23:54:19 -0500
From: Branden Robinson <email address hidden>
To: <email address hidden>
Subject: severity of 263073 is serious, severity of 263076 is normal, merging 256706 263073
# Automatically generated email from bts, devscripts version 2.8.4
severity 263073 serious
severity 263076 normal
merge 256706 263073
Debian Bug Importer (debzilla) wrote : | #23 |
Message-ID: <email address hidden>
Date: Thu, 26 Aug 2004 01:49:07 +0200
From: <email address hidden> (Denis Barbier)
To: <email address hidden>
Cc: <email address hidden>
Subject: Patch to solve XKB mess about modifiers
--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-
tags 256706 + patch
thanks
The bugs described in these merged bugreports were fixed upstream, see
http://
(numbers slightly differs in XFree86 CVS logs and Debian changelogs):
646. Fix for XKB map 'altwin' to avoid one keysym to more than one modifier
mapping (Ivan Pascal).
635. Fix xmodmap's output of the modifiers map when the first column keysym
is empty (Ivan Pascal).
634. Fixes for XKB keyboard maps:
- fix Meta, Super, Hyper keysyms interpretation
- fix typo in rules/xfree86.xml (Ivan Pascal).
Oddly debian/
but not the other 2 chunks. The missing pieces are in modifiers.patch.
I checked that when applied, xmodmap displays the right modifiers and
Meta_L is no more bound to Mod1.
Few days later, Ivan Pascal committed (attached in none.patch)
667. Fixes and updates for XKB keyboard maps:
...
- Fix wrong key type in the 'keymap without special keys' (Ivan Pascal).
I do not know what this does fix, but it looks pretty sane, maybe it
should go also.
Denis
--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-
Index: programs/
=======
RCS file: /cvs/xc/
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- programs/
+++ programs/
@@ -1,4 +1,4 @@
-// $XFree86: xc/programs/
+// $XFree86: xc/programs/
partial modifier_keys
xkb_symbols "meta_alt" {
@@ -15,7 +15,7 @@
key <LWIN> { [ Meta_L ] };
key <RWIN> { [ Meta_R ] };
modifier_map Mod1 { Alt_L, Alt_R };
- modifier_map Mod4 { Meta_L, Meta_R };
+ modifier_map Mod4 { <META>, Meta_L, Meta_R };
};
partial modifier_keys
@@ -23,7 +23,7 @@
key <LALT> { [ Alt_L, Alt_L ] };
key <LWIN> { [ Meta_L ] };
modifier_map Mod1 { Alt_L };
- modifier_map Mod4 { Meta_L };
+ modifier_map Mod4 { <META>, Meta_L };
};
partial modifier_keys
Index: programs/
=======
RCS file: /cvs/xc/
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- programs/
+++ programs/
@@ -56,7 +56,7 @@
* Author: Jim Fulton, MIT X Consortium; derived from parts of the
* original xmodmap, written by David Rosenthal, of Sun Microsystems.
*/
-/* $XFree86: xc/programs/
Debian Bug Importer (debzilla) wrote : | #24 |
Message-Id: <email address hidden>
Date: Mon, 30 Aug 2004 23:17:42 -0500
From: Branden Robinson <email address hidden>
To: <email address hidden>
Subject: tagging 256706
# Automatically generated email from bts, devscripts version 2.8.4
# fixed in Debian X Strike Force XFree86 repository; to view, run "svn diff -r 1772:1773 svn://necrotic.
tags 256706 + pending
Debian Bug Importer (debzilla) wrote : | #25 |
Message-Id: <email address hidden>
Date: Mon, 30 Aug 2004 23:35:34 -0500
From: Branden Robinson <email address hidden>
To: <email address hidden>
Subject: tagging 256706
# Automatically generated email from bts, devscripts version 2.8.4
# that which is pending does not need more info or help
tags 256706 - moreinfo help
Debian Bug Importer (debzilla) wrote : | #26 |
Message-ID: <20040909014725
Date: Wed, 8 Sep 2004 18:47:25 -0700
From: Scott Robinson <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#259740 acknowledged by developer (Bug#256706: fixed in xfree86 4.3.0.dfsg.1-7)
--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-
Content-
reopen 259740
thanks
This bug still occurs in the latest version.
Scott.
--=20
http://
--IJpNTDwzlM2Ie8A6
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iEYEARECAAYFAkE
5xcAn3OsKUSbOgL
=sKpg
-----END PGP SIGNATURE-----
--IJpNTDwzlM2Ie
Debian Bug Importer (debzilla) wrote : | #27 |
Message-ID: <email address hidden>
Date: Thu, 9 Sep 2004 17:19:57 +0200 (CEST)
From: Fabio Massimo Di Nitto <email address hidden>
To: <email address hidden>
Subject: Closing.
Hi,
you are more than welcome to reopen RC bugs, but please add
information on why. Failing to do so makes me feel that you did not bother
to read the contents of the different bugs, that explain (inclusing
upstream notes) that the behaviour of the keys will not be fully reverted
to avoid reintroducing other bugs.
Fabio
--
<user> fajita: step one
<fajita> Whatever the problem, step one is always to look in the error log.
<user> fajita: step two
<fajita> When in danger or in doubt, step two is to scream and shout.
Debian Bug Importer (debzilla) wrote : | #28 |
Message-ID: <email address hidden>
Date: Fri, 10 Sep 2004 01:20:27 +0200
From: <email address hidden> (Denis Barbier)
To: Scott Robinson <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: Bug#259740: Fw:Bug#259740: xlibs: Windows key no longer treated as modifer,
just as Super_L
unmerge 259740
reopen 259740
severity 259740 normal
tags 259740 - patch
thanks
Rationale: This bugreport was merged with others; some issues are fixed,
but others like this one are still under discussion.
On Thu, Sep 09, 2004 at 08:37:00AM -0700, Scott Robinson wrote:
> -- 1
> 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)
> -- 1
>
> -- 2
>
> -- 2
> (nothing outputs from 'xkbcomp :0')
I asked you to send the generated server-0.xkb file, but Sebastien
Bacher told me on IRC how to reproduce this bug, so this is no more
necessary.
> 3. As for the altwin:meta_win, that is not what I want. I want the Windows
> key to be a modifier other than Meta. My alt key is already Meta, and that's
> just fine.
>
> If the modifier was Mod4, that would be best. If it is something else, I
> could handle that too. Right now, it appears the key is simultaneously Mod4
> and a normal keypress.
I ran
$ METACITY_VERBOSE=1 METACITY_
then launched
$ gnome-keybindin
and changed switching between windows by trying to map this action
to Super_L+Tab (as I tried several times, it may not have the
default value).
The log file contains (my comments are prefixed by a dash sign)
Window manager: Metacity version 2.8.1 running on 09.09.2004
...
KEYBINDINGS: Binding "switch_windows" has new gconf value "Super_L"
KEYBINDINGS: New keybinding for "switch_windows" is keysym = 0xffeb mods = 0x0
# xev tells that Super_L is indeed 0xffeb, but modifiers are 0x40.
# this output means that the Super_L key is pressed without modifiers,
# so in fact it is not seen as a modifier, see <Alt>Tab below for
# another example.
...
SM: Initializing session with save file '(none)'
SM: Obtained session ID 'xxxxxxxxxxxxxx
Window manager: Opening display ':0.0'
KEYBINDINGS: Display has keycode range 8 to 255
KEYBINDINGS: Keysym Alt_L bound to modifier 0x8
KEYBINDINGS: Keysym Meta_L bound to modifier 0x8
KEYBINDINGS: Keysym Alt_L bound to modifier 0x8
KEYBINDINGS: Keysym Meta_L bound to modifier 0x8
KEYBINDINGS: Keysym Num_Lock bound to modifier 0x10
KEYBINDINGS: Keysym Pointer_EnableKeys bound to modifier 0x10
KEYBINDINGS: Keysym Super_L bound to modifier 0x40
# as said above, so this binding is correct here
KEYBINDINGS: Keysym Hyper_L bound to modifier 0x40
KEYBINDINGS: Keysym Mode_switch bound to modifier 0x80
KEYBINDINGS: Keysym ISO_Level3_Shif...
Changed in xorg: | |
status: | Unknown → Fix Released |
Message-ID: <email address hidden> Escape no longer working
Date: Mon, 19 Jul 2004 16:06:28 +0200
From: Guido Guenther <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: xterm: XTerm*metaSends
Package: xterm
Version: 4.3.0.dfsg.1-6
Severity: normal
Hi,
the above is no longer working after an upgrade to the versions below.
Before that I could use: Alt-f, Alt-b to jump whole words forward or
backward in a bash running within xterm. This doesn't work anymore,
ESC-f, ESC-b still works though. Any ideas where to start digging?
Cheers,
-- Guido
P.S.: I'm additionally using:
keysym Alt_L = Meta_L Alt_L
to make the above work.
-- System Information: en_US.UTF- 8
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.8-rc2-albook12
Locale: LANG=en_US.UTF-8, LC_CTYPE=
Versions of packages xterm depends on:
hi libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an
ii libexpat1 1.95.6-8 XML parsing C library - runtime li
ii libfontconfig1 2.2.3-1 generic font configuration library
ii libfreetype6 2.1.7-2.1 FreeType 2 font engine, shared lib
ii libice6 4.3.0.dfsg.1-6 Inter-Client Exchange library
ii libncurses5 5.4-4 Shared libraries for terminal hand
ii libsm6 4.3.0.dfsg.1-6 X Window System Session Management
ii libxaw7 4.3.0.dfsg.1-6 X Athena widget set library
ii libxext6 4.3.0.dfsg.1-6 X Window System miscellaneous exte
ii libxft2 2.1.2-6 FreeType-based font drawing librar
ii libxmu6 4.3.0.dfsg.1-6 X Window System miscellaneous util
ii libxpm4 4.3.0.dfsg.1-6 X pixmap library
ii libxrender1 0.8.3-7 X Rendering Extension client libra
ii libxt6 4.3.0.dfsg.1-6 X Toolkit Intrinsics
ii xlibs 4.3.0.dfsg.1-6 X Window System client libraries m
ii xlibs-data 4.3.0.dfsg.1-6 X Window System client data
-- no debconf information