all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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
[parent not found: <20041003233940.JVGC27821.mxfep02.bredband.com@coolsville.localdomain>]
* Re: Xfree86 and the Meta key (+patch)
@ 2004-10-04  0:08 Jan D.
  0 siblings, 0 replies; 22+ messages in thread
From: Jan D. @ 2004-10-04  0:08 UTC (permalink / raw)


> "Jan D." <jan.h.d@swipnet.se> writes:
> 
> > I think there is something "wrong" in Xorg also.  It behaves exactly as
> > described in the bug report.  Andreas, do you have an unmodified Xorg,
> > with standard xkb maps and no xmodmap settings, and still manage to get
> > Meta on the "Windows"-key using altwin:meta_win (i.e. assigning Meta to
> > the "Windows"-key) as an option to xkb?
> 
> What does altwin:meta_win do exactly in terms of modifier keys?  Actually
> I'm using a modified keymap with some modifier keys remapped: <LMTA> and
> <RMTA> are emitting Alt_L and Alt_R, resp., and <LALT> is changed to emit
> Meta_L (the unmodified map has them the other way round).

altwin:meta_win assignes Meta_L/R to the "Window"-keys (<LWIN> and <RWIN>,
default is Super_L/Multi_Key) and Meta_L/R is added to Mod4 (Mod1 is Alt_L/R).

Previously Mod4 was Super_L on <LWIN>, and when altwin:meta_win was set
Mod4 became Meta_L/R.

Now Mod4 is Super_L and Hyper_L on "fake" keys.  altwin:meta_win then
just adds Meta_L/R, so Emacs sees Mod4 as Hyper-Super-Meta.

If there is no need for these fake keys (I am not sure what they do),
you could set altwin:meta_win and then do

% xmodmap -e 'remove mod4 = Hyper_L' -e 'remove mod4 = Super_L'

and get the same behaviour as previous X versions.

I'm not sure why your modification works with Xorg, probably your Meta_L/R
are on a different modifier (Mod3 for example).  Or maybe your keymap
does not have them.

	Jan D.

^ permalink raw reply	[flat|nested] 22+ messages in thread
* Re: Xfree86 and the Meta key (+patch)
@ 2004-10-04 21:30 Denis Barbier
  2004-10-04 22:56 ` Jan D.
  0 siblings, 1 reply; 22+ messages in thread
From: Denis Barbier @ 2004-10-04 21:30 UTC (permalink / raw)


[I am not subscribed to this list and am browsing archives online;
as Message-ID is not available, I am sorry for breaking this thread]

Jan D. wrote:
> altwin:meta_win assignes Meta_L/R to the "Window"-keys (<LWIN> and
> <RWIN>,
> default is Super_L/Multi_Key) and Meta_L/R is added to Mod4 (Mod1 is
> Alt_L/R).
> 
> Previously Mod4 was Super_L on <LWIN>, and when altwin:meta_win was set
> Mod4 became Meta_L/R.
> 
> Now Mod4 is Super_L and Hyper_L on "fake" keys.  altwin:meta_win then
> just adds Meta_L/R, so Emacs sees Mod4 as Hyper-Super-Meta.

This can be shown by typing "C-h k" and then any combination with a
logo key, e.g. H-x displays "H-M-s-x is undefined".
Please note also that even with standard pc104 US configuration, logo
keys cannot be used for shortcuts because emacs believe that they
are bound to Hyper and Super.

> If there is no need for these fake keys (I am not sure what they do),
> you could set altwin:meta_win and then do
> 
> % xmodmap -e 'remove mod4 = Hyper_L' -e 'remove mod4 = Super_L'
> and get the same behaviour as previous X versions.

Since XFree86 4.3, major changes were introduced in XKB configuration
which are incompatible with emacs.  Our problem in Debian is that many
users complain about this incompatiblity, and we want to fix it so that
these users do not have to run xmodmap themselves.
A solution is to change modifier mappings in XKB files.  If you are
an XKB guru and are able to hack configuration files so that all
combinations of keymaps still work, please join us ;)
As shortcuts cannot work if a modifier is bound to different symbols,
another solution is to let emacs handle this case in a smarter way.
This is the purpose of the patch sent by Jerome; when a modifier is
bound to different symbols, only one is taken into account.  There is no
change for working configurations, and many configurations which are
currently broken will work out of the box without having to run xmodmap.

Denis

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

end of thread, other threads:[~2004-10-05 21:15 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-01 21:00 Xfree86 and the Meta key (+patch) Jérôme Marant
2004-10-02 23:06 ` Kim F. Storm
2004-10-03  7:34   ` Jérôme Marant
2004-10-04 15:18     ` Richard Stallman
2004-10-04 15:55       ` Jérôme Marant
2004-10-05 18:05         ` Richard Stallman
2004-10-05 21:07           ` Jérôme Marant
2004-10-05 21:15             ` Jan D.
2004-10-03  8:11   ` Frank Schmitt
2004-10-03 12:00     ` Jan D.
2004-10-03 17:54       ` Andreas Schwab
2004-10-03 19:10         ` Jérôme Marant
2004-10-03 21:07           ` Andreas Schwab
2004-10-03 21:52           ` Jan D.
2004-10-03 22:48             ` Andreas Schwab
     [not found] <20041003233940.JVGC27821.mxfep02.bredband.com@coolsville.localdomain>
2004-10-03 23:52 ` Andreas Schwab
  -- strict thread matches above, loose matches on Subject: below --
2004-10-04  0:08 Jan D.
2004-10-04 21:30 Denis Barbier
2004-10-04 22:56 ` Jan D.
2004-10-05  5:53   ` Denis Barbier
2004-10-05 10:43     ` Jan D.
2004-10-05 19:50       ` Denis Barbier

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.