Re: Xfree86 and the Meta key (+patch)

Re: Xfree86 and the Meta key (+patch)

[Denis Barbier]

[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

Re: Xfree86 and the Meta key (+patch)

[Jan D.]

>> 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.

I understand that.  I just mentioned as a fix when upgrading to a 
patched
Emacs is not an option.

> 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 ;)

No, it is mostly Greek to me :-).  Anyway, that does not fix non-debian
systems.

> 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.

I am testing the patch and something like it will be checked in.  But
it would be nicer if Emacs could determine that Hyper and Super
is bound to fake keys and just ignore them.  I'm currently using XKB
to get geometry info to determine that, but I wonder if there is a 
better
way.  The reason I want this is that with the proposed patch the logo
key becomes Super on my system, which is not really helpful either.
If we could determine that Super is a fake key it would become Meta 
which
is so much better.

	Jan D.

Re: Xfree86 and the Meta key (+patch)

[Denis Barbier]

On Tue, Oct 05, 2004 at 12:56:09AM +0200, Jan D. wrote:
> >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.
> 
> I am testing the patch and something like it will be checked in.  But
> it would be nicer if Emacs could determine that Hyper and Super
> is bound to fake keys and just ignore them.  I'm currently using XKB
> to get geometry info to determine that, but I wonder if there is a 
> better way.  The reason I want this is that with the proposed patch
> the logo key becomes Super on my system, which is not really helpful
> either.

Can you please tell me what your configuration is?  I am quite surprised
that it does not work as expected, doesn't xev also report that your
logo key is Super_{L,R}?

> If we could determine that Super is a fake key it would become Meta
> which is so much better.

Fake keys have no symbol at level 0, so before the
  for (code_col = 0; code_col < syms_per_code; code_col++)
loop, you can test whether
  syms[((code - min_code) * syms_per_code)] == NoSymbol
and skip this key in this case.
I did not want to go this way because it is XFree86-centric, the other
solution is more generic.

Denis

Re: Xfree86 and the Meta key (+patch)

[Jan D.]

>>
>> I am testing the patch and something like it will be checked in.  But
>> it would be nicer if Emacs could determine that Hyper and Super
>> is bound to fake keys and just ignore them.  I'm currently using XKB
>> to get geometry info to determine that, but I wonder if there is a
>> better way.  The reason I want this is that with the proposed patch
>> the logo key becomes Super on my system, which is not really helpful
>> either.
>
> Can you please tell me what your configuration is?  I am quite 
> surprised
> that it does not work as expected, doesn't xev also report that your
> logo key is Super_{L,R}?

It was a Solaris machine.  There was no xev on it.  It may be a bad
configuration anyway, it was not my machine.


>> If we could determine that Super is a fake key it would become Meta
>> which is so much better.
>
> Fake keys have no symbol at level 0, so before the
>   for (code_col = 0; code_col < syms_per_code; code_col++)
> loop, you can test whether
>   syms[((code - min_code) * syms_per_code)] == NoSymbol
> and skip this key in this case.
> I did not want to go this way because it is XFree86-centric, the other
> solution is more generic.

I'll go ahead and check in the original patch, checking for fake keys
required more logic anyway to do the right thing, so in the end it ended
up being larger than your patch.

	Jan D.

Re: Xfree86 and the Meta key (+patch)

[Denis Barbier]

On Tue, Oct 05, 2004 at 12:43:23PM +0200, Jan D. wrote:
> >>I am testing the patch and something like it will be checked in.  But
> >>it would be nicer if Emacs could determine that Hyper and Super
> >>is bound to fake keys and just ignore them.  I'm currently using XKB
> >>to get geometry info to determine that, but I wonder if there is a
> >>better way.  The reason I want this is that with the proposed patch
> >>the logo key becomes Super on my system, which is not really helpful
> >>either.
> >
> >Can you please tell me what your configuration is?  I am quite
> >surprised that it does not work as expected, doesn't xev also report
> >that your logo key is Super_{L,R}?
> 
> It was a Solaris machine.  There was no xev on it.  It may be a bad
> configuration anyway, it was not my machine.

It reminds me something I forgot to mention.  My initial intention was
to swap loops on col and code_col in order to first look for a modifier
symbol at level 0 for all keys from mods->modifiermap, then level 1,
etc.  This seems very logical, and I thought that it was needed to have
logo keys bound to Hyper, since this binding is declared after fake keys.
But my tests with XFree86 showed that this patch works without swapping
loops, so I preferred keeping it minimal.  For other X servers, swapping
these loops may be necessary.
Just a thought in case you receive future reports telling that some X
configurations do still not work with this patch applied.
Thanks for taking care.

Denis

Re: Xfree86 and the Meta key (+patch)

[Jan D.]

> "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.

Re: Xfree86 and the Meta key (+patch)

[Andreas Schwab]

I just checked again, the X server I'm runnings is still at 6.8.0, only
the libs are from 6.8.1.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Xfree86 and the Meta key (+patch)

[Jérôme Marant]

[-- 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

Re: Xfree86 and the Meta key (+patch)

[Kim F. Storm]

Jérôme Marant <jmarant@free.fr> writes:

> 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.

Are you saying that all releases of Emacs, including 21.3, will
not run correctly on current XFree86 ?

If that's true, we could be forced to to issue a 21.4 bug fix release
(based on 21.3) real soon !?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Xfree86 and the Meta key (+patch)

[Jérôme Marant]

Quoting "Kim F. Storm" <storm@cua.dk>:

> Jérôme Marant <jmarant@free.fr> writes:
>
> > 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.
>
> Are you saying that all releases of Emacs, including 21.3, will
> not run correctly on current XFree86 ?

>From now on, Emacs will have such a problem with upcoming XFree86
and Xorg releases. Rob and I really need to apply a fix for Debian
quickly. So, if you have a better fix, please tell us.

> If that's true, we could be forced to to issue a 21.4 bug fix release
> (based on 21.3) real soon !?

I don't know. I guess it will be fixed in the trunk like the other
bugs.

--
Jérôme Marant

Re: Xfree86 and the Meta key (+patch)

[Richard Stallman]

    >From now on, Emacs will have such a problem with upcoming XFree86
    and Xorg releases.

There are several variants of XFree86 now, but I have heard that most
of them are not likely to be used much.  For instance, people told me
that the one called XFree86 is not likely to be used much.

I don't know what Xorg is.  Does Xorg have the same licence change
that XFree86 has?  All else being equal, we would prefer to recommend
releases which don't have that license change.

Re: Xfree86 and the Meta key (+patch)

[Jérôme Marant]

Quoting Richard Stallman <rms@gnu.org>:

>     >From now on, Emacs will have such a problem with upcoming XFree86
>     and Xorg releases.
>
> There are several variants of XFree86 now, but I have heard that most
> of them are not likely to be used much.  For instance, people told me
> that the one called XFree86 is not likely to be used much.

Debian currently ships XFree86 4.3 plus patches that were applied to the
the XFree86 before the license change.

> I don't know what Xorg is.  Does Xorg have the same licence change
> that XFree86 has?  All else being equal, we would prefer to recommend
> releases which don't have that license change.

Xorg is a fork of the Xfree86 tree which does not have licensing problems.
It is maintained by freedesktop.org. Everyone is going in this direction.

Cheers,

--
Jérôme Marant

Re: Xfree86 and the Meta key (+patch)

[Richard Stallman]

    > I don't know what Xorg is.  Does Xorg have the same licence change
    > that XFree86 has?  All else being equal, we would prefer to recommend
    > releases which don't have that license change.

    Xorg is a fork of the Xfree86 tree which does not have licensing problems.
    It is maintained by freedesktop.org. Everyone is going in this direction.

In that case, we do care about it.

Why did they make the change?  Is it a clear improvement, in general?
In other words, should we ask them to revert it, or should we accept
it as an improvement in X?

Re: Xfree86 and the Meta key (+patch)

[Jérôme Marant]

Selon Richard Stallman <rms@gnu.org>:

>     > I don't know what Xorg is.  Does Xorg have the same licence change
>     > that XFree86 has?  All else being equal, we would prefer to recommend
>     > releases which don't have that license change.
>
>     Xorg is a fork of the Xfree86 tree which does not have licensing
> problems.
>     It is maintained by freedesktop.org. Everyone is going in this direction.
>
> In that case, we do care about it.
>
> Why did they make the change?  Is it a clear improvement, in general?

Yes, it is a clear improvement for people using multiple keyboard
layouts.

> In other words, should we ask them to revert it, or should we accept
> it as an improvement in X?

The latter. Jan D. did some tests and commited the patch. As far as I know,
it is backward compatible. Jan, do you confirm?


--
Jérôme Marant

Re: Xfree86 and the Meta key (+patch)

[Jan D.]

>
>> In other words, should we ask them to revert it, or should we accept
>> it as an improvement in X?
>
> The latter. Jan D. did some tests and commited the patch. As far as I 
> know,
> it is backward compatible. Jan, do you confirm?

Yes, with a possible reservation for that Solaris machine.  I did test
Solaris on x86, and it was OK there, so the Sparc machine may have been
a bad configuration.  I'll try to get access to it again.

	Jan D.

Re: Xfree86 and the Meta key (+patch)

[Frank Schmitt]

storm@cua.dk (Kim F. Storm) writes:

>> 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.
>
> Are you saying that all releases of Emacs, including 21.3, will
> not run correctly on current XFree86 ?
>
> If that's true, we could be forced to to issue a 21.4 bug fix release
> (based on 21.3) real soon !?

I run xorg 6.8.1 and don't see any problems.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Xfree86 and the Meta key (+patch)

[Jan D.]

>>> 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.
>>
>> Are you saying that all releases of Emacs, including 21.3, will
>> not run correctly on current XFree86 ?
>>
>> If that's true, we could be forced to to issue a 21.4 bug fix release
>> (based on 21.3) real soon !?
>
> I run xorg 6.8.1 and don't see any problems.

Me too.  But it works only because Emacs does not find a Meta key and
then uses the Alt key as Meta.  Thus you can't have both a Meta and an 
Alt.

There is no difference between 21.3 and CVS for this problem.

	Jan D.

Re: Xfree86 and the Meta key (+patch)

[Andreas Schwab]

"Jan D." <jan.h.d@swipnet.se> writes:

>> I run xorg 6.8.1 and don't see any problems.
>
> Me too.  But it works only because Emacs does not find a Meta key and
> then uses the Alt key as Meta.  Thus you can't have both a Meta and an
> Alt.

I don't have any problem either, and I have both Alt and Meta keys.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Xfree86 and the Meta key (+patch)

[Jérôme Marant]

Quoting Andreas Schwab <schwab@suse.de>:

> "Jan D." <jan.h.d@swipnet.se> writes:
>
> >> I run xorg 6.8.1 and don't see any problems.
> >
> > Me too.  But it works only because Emacs does not find a Meta key and
> > then uses the Alt key as Meta.  Thus you can't have both a Meta and an
> > Alt.
>
> I don't have any problem either, and I have both Alt and Meta keys.

Did you test with the latest XFree86 releases? Since I haven't tested with
Xorg, I'm glad nothing wrong there.

Cheers,

--
Jérôme Marant

Re: Xfree86 and the Meta key (+patch)

[Andreas Schwab]

Jérôme Marant <jmarant@free.fr> writes:

> Did you test with the latest XFree86 releases?

I'm using 6.8.1 as well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Xfree86 and the Meta key (+patch)

[Jan D.]

Jérôme Marant wrote:
> Quoting Andreas Schwab <schwab@suse.de>:
> 
> 
>>"Jan D." <jan.h.d@swipnet.se> writes:
>>
>>
>>>>I run xorg 6.8.1 and don't see any problems.
>>>
>>>Me too.  But it works only because Emacs does not find a Meta key and
>>>then uses the Alt key as Meta.  Thus you can't have both a Meta and an
>>>Alt.
>>
>>I don't have any problem either, and I have both Alt and Meta keys.
> 
> 
> Did you test with the latest XFree86 releases? Since I haven't tested with
> Xorg, I'm glad nothing wrong there.

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?

It is of course possible to get Meta and Alt keys on other keys than the 
"Windows"-key.  As I read this bug report, it only applies to the "Windows"-key 
and only when using altwin:meta_win as an option to xkb.  In that case, Emacs 
thinks the "Windows"-key sends Hyper-Super-Meta.

	Jan D.

Re: Xfree86 and the Meta key (+patch)

[Andreas Schwab]

"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).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."