Bug 8996 - Patch to map Control to the Win-keys
Summary: Patch to map Control to the Win-keys
Status: RESOLVED FIXED
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high enhancement
Assignee: xkb
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-12 11:56 UTC by Stephen Gildea
Modified: 2006-11-14 09:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Patch to map Control to the Win-keys (2.07 KB, patch)
2006-11-12 11:58 UTC, Stephen Gildea
Details | Splinter Review
Remove the Alt key mappings from altwin(ctrl_win) (736 bytes, patch)
2006-11-13 20:32 UTC, Stephen Gildea
Details | Splinter Review

Description Stephen Gildea 2006-11-12 11:56:52 UTC
The XKB symbols mappings of the Alt and Windows-logo keys support
many options for the Windows-logo keys: as Meta, Super, or Hyper.
It's almost a complete list, but missing from it is the option I
prefer: Control.

I like mapping the Windows-logo keys as additional Control keys
because having both Control and Alt keys nearer the center of the
keyboard on each side means less reaching with my little fingers.

The attached patch adds this feature.  The gist of the patch is
this new paragraph:

partial modifier_keys 
xkb_symbols "ctrl_win" {
    key <LALT> {        [       Alt_L           ]       };
    key <RALT> {        [       Alt_R           ]       };
    key <LWIN> {        [       Control_L       ]       };
    key <RWIN> {        [       Control_R       ]       };
    modifier_map Control { <LWIN>, <RWIN> };
    modifier_map Mod1   { Alt_L, Alt_R };
};

My patch is against symbols/altwin rev 1.8, shipped with
xkeyboard-config 0.9 (aligned with Xorg 7.1.0).
Comment 1 Stephen Gildea 2006-11-12 11:58:57 UTC
Created attachment 7760 [details] [review]
Patch to map Control to the Win-keys
Comment 2 Sergey V. Udaltsov 2006-11-12 12:09:51 UTC
thanks, committed.
Comment 3 Denis Barbier 2006-11-12 13:32:51 UTC
Is there a reason why this patch does modify Alt keys? This will cause
trouble, e.g. many layouts map Alt_R to ISO_Level3_Shift.
Comment 4 Sergey V. Udaltsov 2006-11-12 13:57:58 UTC
(In reply to comment #3)
> Is there a reason why this patch does modify Alt keys? This will cause
> trouble, e.g. many layouts map Alt_R to ISO_Level3_Shift.

Oops, sorry I overlooked it. Yes, it looks like modifying ALT keys should not be
there...
Comment 5 Stephen Gildea 2006-11-12 16:32:59 UTC
(In reply to comment #3)

There are two reasons why I think it does make sense to include
setting the Alt keys in this option.

Some of the layouts one might want to use this option with rely on
generating Meta or Alt with the Windows-logo keys.  Since I'm
removing that, I need to ensure Alt is on the Alt keys.

Second, the motivator for this layout option--having both Alt and
Control conveniently close on each side of the keyboard--seems
consistent and unifying enough to justify wrapping this as a
single option.  In particular, I do want to defeat mapping Alt_R
to ISO_Level3_Shift, because a second Alt key is more useful for
minimizing finger motion,

Having made those points, I'll grant your point that maybe not
everyone wants Alt keys.  We could make two options out of this,
one with and one without the Alt keys mappings.

(Thank you for applying my patch so promptly!)
Comment 6 Denis Barbier 2006-11-13 02:27:35 UTC
By default, layouts do not modify Alt or Logo keys, except for
Alt_R.  If Logo keys are mapped to Alt or Meta, this is done
through XKB options.
I fail to see why resetting Alt_L and Alt_R does any good, but
can easily see why it it troublesome ;)
Stephen, can you please give examples of configuration which
would be broken without resetting these keys?
Comment 7 Stephen Gildea 2006-11-13 20:32:42 UTC
Created attachment 7779 [details] [review]
Remove the Alt key mappings from altwin(ctrl_win)

Denis is correct, and I do not need to modify the Alt keys.

I had done some testing with XFree86 4.3, and there the
U.S. Dvorak layout mapped Alt_R to ISO_Level3_Shift, with 
no way to undo that.  I thought I needed to fix that here,
but I now see that it was a bug in the old mappings.

The current xkeyboard-config Dvorak does not touch Alt_R;
instead you use a separate level3 option to say whether you
want ISO_Level3_Shift and if so where (e.g., on Alt_R).
With the clean separation between the basic layout, the
altwin options, and the level3 options, each layout and
option can be simpler and orthogonal, and they still
combine nicely.  I believe this is what Denis was arguing
for in my patch.

(I see some other layouts (that I don't use) still do
include "level3(ralt_switch)".	Since, as I found out,
there is no way to undo this layout choice once made, I
wonder if that isn't a bug.  Perhaps it's a convenient
default, in which case it seems to me there should be a
"level3(ralt_alt)" option to explicitly undo it.  (But I'm
wandering from the topic; this discussion could carry on in
a new bug report.))

I have attached a patch to my patch that removes the Alt
key mappings from the ctrl_win logo key mappings.
Comment 8 Denis Barbier 2006-11-14 01:15:59 UTC
> With the clean separation between the basic layout, the
> altwin options, and the level3 options, each layout and
> option can be simpler and orthogonal, and they still
> combine nicely.  I believe this is what Denis was arguing
> for in my patch.

You are fully right :)

> (I see some other layouts (that I don't use) still do
> include "level3(ralt_switch)".  Since, as I found out,
> there is no way to undo this layout choice once made, I
> wonder if that isn't a bug.  Perhaps it's a convenient
> default, in which case it seems to me there should be a
> "level3(ralt_alt)" option to explicitly undo it.  (But I'm
> wandering from the topic; this discussion could carry on in
> a new bug report.))

Yes, there is no clean way to undo some changes, this is why
we try to only modify what is really necessary.  Layouts
include "level3(ralt_switch)" for convenience when they define
keys with more than 2 levels, so that everything works out of
the box.  But indeed this can cause trouble, and maybe it
would have been better to not include it, this is a very
legitimate question.

> I have attached a patch to my patch that removes the Alt
> key mappings from the ctrl_win logo key mappings.

Thanks.
Comment 9 Sergey V. Udaltsov 2006-11-14 09:27:14 UTC
Lads, I am glad we got quick consensus here. I wish it would be that easy every
time:)
Thanks, the last patch is committed.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.