Xfree86 and the Meta key (+patch)

* Xfree86 and the Meta key (+patch)
@ 2004-10-01 21:00 Jérôme Marant
  2004-10-02 23:06 ` Kim F. Storm
  0 siblings, 1 reply; 22+ messages in thread
From: Jérôme Marant @ 2004-10-01 21:00 UTC (permalink / raw)


[-- Attachment #1: Type: text/plain, Size: 3456 bytes --]


Hi,

The recent XFree86 recently broke the meta key for Emacs.
Some debian Xkb specialist worked on the problem and issued a patch. It has
been tested and we need to apply it before Debian sarge is release.

Has this already been fixed in the trunk in another way? If so how?

Here is the bug report, and the patch (against 21.3) attached.

Thanks in advance for reviewing.

--------------
To: debian-emacsen@lists.debian.org
Subject: Solving the modifiers issue with emacs and XFree86 4.3
From: barbier@linuxfr.org (Denis Barbier)
Date: Wed, 22 Sep 2004 22:56:27 +0200

Hi,

as explained in #255286, bug submitter has problems with his
configuration, logo keys are bound to Meta, but emacs believes that they
are bound to Meta+Super+Hyper, and of course shortcuts do not work as
expected.

The root of the problem is that XFree86 4.3 (in fact future versions,
but patches were backported by XFree86 Debian maintainers) introduced
the so called 'fake keys' which do not correspond to any real key, but
are internally used by XKB to trigger specific events.  This was meant
to solve problems with multiple layouts (like us,ru) when modifiers are
bound to different keys for each national layout.

So people claim that this is an XFree86 issue.  But Debian packages
won't get fixed, otherwise the problems described above will reappear.
There is another solution, I supplied a patch to #255286, which is
really safe, which means that a working configuration cannot break,
most broken configurations will be fixed (I checked with all altwin:*
options), and few broken configurations will still get broken (the
latter is just for completeness, I did not try to find examples).
Moreover this patch is very small, so it can easily be reviewed.

What is this patch about?
This is pretty simple, the x_find_modifier_meanings function in
src/xterm.c scan all keycodes bound to mod[1-5], get all their
KeySyms, and look for XK_{Alt,Meta,Super,Hyper}_{L,R} Keysyms.
A bit mask is set, and (in short) due to altwin:meta_win XKB option:
   alt_mod_mask = mod1
   meta_mod_mask = mod1 | mod4
   super_mod_mask = hyper_mod_mask = mod4
When emacs receives a KeyPress/KeyRelease with mod4 set, it activates
Meta+Hyper+Super modifiers.

But whenever different KeySyms are bound to the same modifier mod[1-5],
emacs is confused and unable to process these shortcuts.  So instead of
collecting all KeySyms, a smarter way is to stop scanning KeySyms when
one is found.  There is a special treatment for Alt+Meta in original
source code, so I had to handle this specific case too in order to be
compatible with the current behavior.

This paragraph is no longer true, since someoone managed to test
(see bug report)
[Unfortunately I was unable to build emacs21 on my old slow computer, and
isolated this function to display the mentioned bit masks when this patch
is applied, so I am pretty sure that it works fine.
Please consider applying this patch to emacs21, I see no other way to
solve this annoying bug for sarge.
If xemacs21 maintainer is willing to solve this issue as well, let me
know and I will have a look, but sources are very different.
]


At the moment, only altwin:super_win and altwin:hyper_win options can be
tested, there is a bug in xlibs which prevents altwin:meta_win to work
correctly, but it will be fixed by a coming soon upload.

Denis
---------------

--
Jérôme Marant

[-- Attachment #2: emacs-mods.patch --]
[-- Type: application/octet-stream, Size: 1659 bytes --]

--- emacs-21.3/src/xterm.c.orig	2004-09-14 19:06:11.000000000 +0200
+++ emacs-21.3/src/xterm.c	2004-09-16 22:23:24.000000000 +0200
@@ -6380,8 +6380,11 @@
      Alt keysyms are on.  */
   {
     int row, col;	/* The row and column in the modifier table.  */
+    int found_alt_or_meta;
 
     for (row = 3; row < 8; row++)
+    {
+      found_alt_or_meta = 0;
       for (col = 0; col < mods->max_keypermod; col++)
 	{
 	  KeyCode code
@@ -6403,33 +6406,44 @@
 		  {
 		  case XK_Meta_L:
 		  case XK_Meta_R:
+		    found_alt_or_meta = 1;
 		    dpyinfo->meta_mod_mask |= (1 << row);
 		    break;
 
 		  case XK_Alt_L:
 		  case XK_Alt_R:
+		    found_alt_or_meta = 1;
 		    dpyinfo->alt_mod_mask |= (1 << row);
 		    break;
 
 		  case XK_Hyper_L:
 		  case XK_Hyper_R:
-		    dpyinfo->hyper_mod_mask |= (1 << row);
+		    if (!found_alt_or_meta)
+		      dpyinfo->hyper_mod_mask |= (1 << row);
+		    code_col = syms_per_code;
+		    col = mods->max_keypermod;
 		    break;
 
 		  case XK_Super_L:
 		  case XK_Super_R:
-		    dpyinfo->super_mod_mask |= (1 << row);
+		    if (!found_alt_or_meta)
+		      dpyinfo->super_mod_mask |= (1 << row);
+		    code_col = syms_per_code;
+		    col = mods->max_keypermod;
 		    break;
 
 		  case XK_Shift_Lock:
 		    /* Ignore this if it's not on the lock modifier.  */
-		    if ((1 << row) == LockMask)
+		    if (!found_alt_or_meta && ((1 << row) == LockMask))
 		      dpyinfo->shift_lock_mask = LockMask;
+		    code_col = syms_per_code;
+		    col = mods->max_keypermod;
 		    break;
 		  }
 	      }
 	  }
 	}
+    }
   }
 
   /* If we couldn't find any meta keys, accept any alt keys as meta keys.  */

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 22+ messages in thread