I noticed the same.  
it seems to be a problem in xkeyboard-config. 

A git bisect points to this commit in xkeyboard-config:

commit 1371636923fc2dce373cdbc9bee30287ebfddf51
Author: Sergey V. Udaltsov <svu@gnome.org>
Date:   Tue Jan 11 13:39:54 2011 +0000

    fixing "both shifts together"
    
    https://bugs.freedesktop.org/show_bug.cgi?id=30898

That original patch was fixed since. Could you please check the version from git?

I've just (Mar 17 11:10 MDT) built the git version - the same behavior with Caps_Lock...

Did you try new xkb option caps:ctrl_modifier ?

(In reply to comment #4)
> Did you try new xkb option caps:ctrl_modifier ?

Yes. That does work. But I'm switching Meta to Caps_Lock, so that doesn't really help too much.

Would you be able to attach the results of "xkbcomp :0 -xkb out.xkb" for two scenarios: "good" and "bad" - the mapping that worked for you (so you could do "xmodmap -e 'clear Lock'") and the mapping that did not.

Created attachment 44558 [details]
"xkbcomp :0 -xkb out-good.xkb"

Created attachment 44559 [details]
"xkbcomp :0 -xkb out-bad.xkb"

(In reply to comment #6)
I've attached those files.

The substantial difference I see:
963,965d962
<     interpret Shift_L+AnyOfOrNone(all) {
<         action= SetMods(modifiers=Shift,clearLocks);
<     };
1039,1041d1035
<     interpret Caps_Lock+AnyOfOrNone(all) {
<         action= LockMods(modifiers=Lock);
<     };
These actions are in the "bad" mapping. The 2nd one is really caused by that change in bug #30898, but I cannot figure out where the first section comes from....

What you could try is creating another xkb option (just do not contribute it please!) that sets action to NoAction on caps lock:

interpret Caps_Lock+AnyPfOrNone(all) { action = NoAction(); }

You can put it into symbols/capslock, then add to rules/base.o_s.part

Would that work for you?

I understand your inconvenience, I just do not see a way to make everybody happy here.

I'm not sure I understand why this breakage is necessary.  I have caps lock mapped to mod3, which is use for all my xmonad keycombos.  As a result, when I installed the new xkeyboard-config, I became unable to use my window manager at all - no launching programs, no switching windows, nothing - effectively rendering my system unusable until I reverted to the prior version.  While my use is admittedly a bit of an edge case, it shows that this breakage has the potential to severely affect users and should not be taken lightly.  I don't understand all the xkb jargon in this report and bug #30898, so could someone please explain to me in clear terms why this breakage was deemed necessary?

Well, the bugs in that bug are real - as well as yours. I am definitely not taking those cases lightly - I am just in the position of manager who has to define the priorities. IMNSHO that bug mentioned in #30898 has slightly higher priority (you admitted the "edge case") - so reverting the old behavior would be worse than keeping the things as they are now. The BEST option would be do have everybody happy. ATM I am thinking about that - but till we find some solution that would cover all our bases I would prefer not to introduce changes (even revert) into the relevant bits of code.

I hope you understand my position.

It's certainly a tricky situation, and I understand your reluctance to move too quickly.  What makes this particularly bad though is that 1) There's no error telling the user that this option doesn't work anymore, and 2) There's apparently no way to regain this functionality by an alternate syntax or using a different tool than xmodmap.  Again, I don't really understand the technical details here, but if we could at least address one or both of those two points it would make things much less harrowing for users like me who DO fall into the edge case.

The mentioned commit sets an action to the keysym Caps_Lock to lock the Lock modifier. Up to then the lock behavior was created by just binding the whole key to the real modifier “Lock”.
But there are cases, where binding the whole key is not what you want (e.g. different behavior on different levels).

Basically the use of the Caps_Lock keysym was intended to be what it says.

Now there are people, who are using their <CAPS> key for other things (which is reasonable). But with xmodmap solely, there are no ways of redefining the standard actions which were set on Caps_Lock by the mentioned commit.
You can perfectly modify your <CAPS> key as long as you keep in mind, that the keysym Caps_Lock is intended for lock behavior and you have to change it if you don't want this behavior.

Examples with xmodmap:

I want my <CAPS> key to be an “a”-key:
xmodmap -e 'remove lock = Caps_Lock' -e 'keysym Caps_Lock = a'

I want my <CAPS> key to be a Control key:
xmodpam -e 'remove lock = Caps_Lock' -e 'keysym Caps_Lock = Control_L' -e 'add control = Control_L'

I want my <CAPS> key to be bound to Mod3 modifier:
xmodmap -e 'remove lock = Caps_Lock' -e 'keysym Caps_Lock = ISO_Level5_Shift' -e 'add mod3 = ISO_Level5_Shift'
(note that I used ISO_Level5_Shift as a keysym, which is generally used together with mod3. But it doesn't really matter: just don't use Caps_Lock or else you will have your lock back)

As a side-note: you can do some common changes through xkb alone by specifying options. This is generally preferred to xmodmap.


Now for those few people who don't want to change the Caps_Lock keysym (for a reason see #30898).

If you want your <CAPS> key to act as a Control key, then you are lucky. Just use the newly created xkb-option “caps:ctrl_modifier”.

To all the others: as of now there is no way to do that.
At the moment you can create your own custom rule similar to caps:ctrl_modifier and achieve your goal. Before you do that ask yourself: “Do I really need a Caps_Lock keysym on a key, which I don't use as one?”


If everyone wants to keep his Caps_Lock keysym and doing other things with it, we probably need something like a NoAction() for Caps_Lock to make it possible for xmodmap to change its behavior. I'm thinking of an additional xkb-option …

Stephan, thanks for such a thorough explanation, I think I understand much better now. I have no particular objection to changing my keysyms for this functionality and your xmodmap examples work perfectly, so I think that provides an adequate solution for most use cases here. It's unfortunate this had to break existing setups and guides, but such is unavoidable sometimes.

> You can perfectly modify your <CAPS> key as long as you keep in mind,
> that the keysym Caps_Lock is intended for lock behavior and you have
> to change it if you don't want this behavior.

If keysym Caps_Lock is intended for lock anyway, why the lock functionality (which can be removed by "xmonad -e "remove Lock = Caps_Lock'") has been ever implemented?

Now I've just changed keysym Caps_Lock to something "non-existing", namely F20, and that configuration works for me after remapping keys (in my xmonad.hs).

But anyway is it a good idea to brake the many-years-old functionality?

Thanks, Stephan, your explanation is very clear and hopefully closes the issue.

> for xmodmap to change its behavior. I'm thinking of an additional xkb-option …
I would prefer to avoid that, if possible to hack all those strange scenarios with local .xmodmap. We have more than enough options as it is.

@Sergey: I would say it was a bug, with some useful "side effect". Bugs are to be fixed.

Anyway, I am closing this now.