What has happened here is that mod1 is now associated with keycode
<ALT> (a key which does not appear to exist on a PC keyboard) instead
of keysyms Alt_L and Alt_R.
Magic elsewhere in the keymap causes Alt_L and Alt_R to still generate
modifier state 1 - but that's not enough. Here's what KDE wants to do:
KeyPress mod1-TAB: display the window selection widget, and shift to the next window, focussing it
KeyRelease mod1: remove the window selection widget, raise the focussed window
Here's what they actually see:
KeyPress Alt_L: (no binding, ignored)
KeyPress mod1-TAB: <...>
KeyRelease mod1-TAB: (no binding, ignored)
KeyRelease Alt_L: (no binding, ignored)
Since Alt_L is not part of mod1 (it just happens to coincidentally
generate it inside XKB).
I'm not really sure what the right fix to this is, because I don't
understand why the change was made in the first place. Absent a better
explanation, I'd back out this change:
Message-ID: <email address hidden>
Date: Sat, 26 Jun 2004 22:11:51 +0100
From: Andrew Suffield <email address hidden>
To: <email address hidden>
Subject: alt modifier issues
--huq684BweRXVnRxX Disposition: inline Transfer- Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Content-
Content-
Figured out the cause of the problem, if not the "right"
solution. It's this change (-4 to -5):
diff -ru ./symbols/pc/pc /etc/X11/ xkb/symbols/ pc/pc xkb/symbols/ pc/pc 2004-06-16 08:12:52.000000000 +0100
--- ./symbols/pc/pc 2004-05-29 08:51:29.000000000 +0100
+++ /etc/X11/
@@ -170,13 +170,28 @@
key <KPDL> { [ KP_Delete, KP_Decimal ] };
// End "Keypad" section
=20
-
// begin modifier mappings
modifier_map Shift { Shift_L, Shift_R };
modifier_map Lock { Caps_Lock, ISO_Lock };
modifier_map Control{ Control_L, Control_R };
- modifier_map Mod1 { Alt_L, Alt_R };
modifier_map Mod2 { Num_Lock };
+
+ // Fake keys for virtual<->real modifiers mapping=20
+ key <LVL3> { [ ISO_Level3_Shift ] };
+ key <MDSW> { [ Mode_switch ] };
+ modifier_map Mod5 { <LVL3>, <MDSW> };
+
+ key <ALT> { [ Alt_L ] };
+ modifier_map Mod1 { <ALT> };
+
+ key <META> { [ Meta_L ] };
+ modifier_map Mod1 { <META> };
+
+ key <SUPR> { [ Super_L ] };
+ modifier_map Mod4 { <SUPR> };
+
+ key <HYPR> { [ Hyper_L ] };
+ modifier_map Mod4 { <HYPR> };
};
=20
// definition for the PC-AT type 101 key keyboard
What has happened here is that mod1 is now associated with keycode
<ALT> (a key which does not appear to exist on a PC keyboard) instead
of keysyms Alt_L and Alt_R.
Magic elsewhere in the keymap causes Alt_L and Alt_R to still generate
modifier state 1 - but that's not enough. Here's what KDE wants to do:
KeyPress mod1-TAB: display the window selection widget, and shift to
the next window, focussing it
KeyRelease mod1: remove the window selection widget, raise the
focussed window
Here's what they actually see:
KeyPress Alt_L: (no binding, ignored)
KeyPress mod1-TAB: <...>
KeyRelease mod1-TAB: (no binding, ignored)
KeyRelease Alt_L: (no binding, ignored)
Since Alt_L is not part of mod1 (it just happens to coincidentally
generate it inside XKB).
I'm not really sure what the right fix to this is, because I don't
understand why the change was made in the first place. Absent a better
explanation, I'd back out this change:
- modifier_map Mod1 { Alt_L, Alt_R };
Restoring that line should fix the problem.
--=20 www.debian. org/ |
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://
`. `' |
`- -><- |
--huq684BweRXVnRxX pgp-signature; name="signature .asc" Description: Digital signature Disposition: inline
Content-Type: application/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
98RSteX8RAgcNAJ 4nMK2s/ X4wPKmkrD70SNti 0UyTFwCgksFx PVN6DP6NaCNCw=
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA3eaXlpK
wwH6Ln9ie+
=dssj
-----END PGP SIGNATURE-----
--huq684BweRXVn RxX--