Bug 56491

Summary: Option to apparently unlock the Lock modifier on press of Caps Lock
Product: xorg Reporter: Andreas Wettstein <wettstae>
Component: Server/Input/XKBAssignee: Xorg Project Team <xorg-team>
Status: NEW --- QA Contact: Xorg Project Team <xorg-team>
Severity: enhancement    
Priority: medium CC: daniel, wordwhirl
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Unlock 'Lock' on key press rather than release none

Description Andreas Wettstein 2012-10-28 13:15:36 UTC
Created attachment 69187 [details]
Unlock 'Lock' on key press rather than release

In bug 27903, it was requested that unlocking of the 'Lock' modifier already happen upon the second press of the Caps Lock key, rather than on the second release.  The basic support to approximate this behaviour (for ALPHABETIC keys) was added to the Xorg server version 1.12. The attached patch adds the missing support in xkeyboard-config, and makes the feature available for average users.
Comment 1 Ran Benita 2012-10-30 14:22:09 UTC
Hi Andreas,

I have tested the patch, and it works as expected. However, I would like to object to Private being used like this:

1. With this option in effect, xkbcomp $DISPLAY gives:
        actions[Group1]= [ LockMods(modifiers=Lock), LockMods(modifiers=Shift+Lock) ]
So you should at least update libxkbfile.

2. In libxkbcommon, we have changed to memory layout of actions, so we can't support stuff like this, which assume that the action structs are set up exactly as specified. I understand this is backed by the XKB specification, but I still think this is ugly, and I don't think anyone has used Private with actual SetMods, LockGroup etc. actions like this before.

So, is there any reason not to apply the trivial patch to xkbcomp, to do it properly?
Comment 2 Daniel Stone 2012-10-30 21:52:40 UTC
If there's an xkbcomp patch to be applied, link it here and I'll happily apply it and make a release.
Comment 3 Ran Benita 2012-10-31 13:12:32 UTC
Hi Daniel,
I now see that the linked bug
https://bugs.freedesktop.org/show_bug.cgi?id=27903
has patches for libxkbfile and xkbcomp, thry look good to me. I think the server also needs a patch, AFAICT it duplicates the code from libxkbfile in order to write the keymap to xkbcomp over the pipe.
Comment 4 Andreas Wettstein 2012-11-05 20:33:33 UTC
> 2. In libxkbcommon, we have changed to memory layout of actions, so we can't support stuff like this, which assume that the action structs are set up exactly as specified. I understand this is backed by the XKB specification, but I still think this is ugly, and I don't think anyone has used Private with actual SetMods, LockGroup etc. actions like this before.

On the long run, we certainly should get rid of Private. But as far as I understand, we cannot expect that each system that has a new version of xkeyboard-config also has a new version of xkbcomp.  How can we deal with that?  I think we have at least to avoid that users with an old xkbcomp that do not want to use the new feature have problems.
Comment 5 Sergey V. Udaltsov 2012-11-06 00:42:04 UTC
There is already relatively bad hack:

# xkeyboard-config does not have build-time dependencies. However, it does
# have run-time dependencies and keyboard layouts may not work without the
# right libX11 or xproto installed.

We could add xkbcomp here as well.
Comment 6 Andreas Wettstein 2013-01-08 19:53:54 UTC
The next release of xkeyboard-config is approaching.  I send a patch for xkbcomp to xorg-devel, but it has not yet been integrated.  I therefore believe it is best to merge the patch as is, with the Private actions.  As far as I understood Ran, the worst thing about it is that it does not do anything with libxkbcommon, which is less severe than not having the feature at all. I can provide an augmented patch with LockMods when xkbcomp has been updated.
Comment 7 Sergey V. Udaltsov 2013-01-12 01:20:03 UTC
I think it is a bad idea to introduce Private section here. Could you pls give reference to the bug against xkbcomp?
Comment 8 Daniel Stone 2013-01-12 01:29:37 UTC
Here's the most recent part of the thread:
http://lists.freedesktop.org/archives/xorg-devel/2013-January/035046.html

Basically, I think we'd need to bump the XKB protocol version to make this
workable for X11.  I've been meaning to look at this for a while now, but
have ended up much busier with travel than hoped. :\


On 11 January 2013 17:20, <bugzilla-daemon@freedesktop.org> wrote:

>   *Comment # 7 <https://bugs.freedesktop.org/show_bug.cgi?id=56491#c7> on bug
> 56491 <https://bugs.freedesktop.org/show_bug.cgi?id=56491> from Sergey V.
> Udaltsov <svu@gnome.org> *
>
> I think it is a bad idea to introduce Private section here. Could you pls give
> reference to the bug against xkbcomp?
>
>  ------------------------------
> You are receiving this mail because:
>
>    - You are on the CC list for the bug.
>
>
Comment 9 Andreas Wettstein 2013-01-12 16:12:48 UTC
> Could you pls give reference to the bug against xkbcomp?

The original request is bug 27903.  A real bug in xkbcomp (and the server) it is in the sense that the NoLock/NoUnlock was not supported.  This is fixed in the server since version 1.12, but not yet in xkbcomp.

> Basically, I think we'd need to bump the XKB protocol version to make this
> workable for X11.

Actually, the request at hand only needs support for NoLock/NoUnlock, flags that the protocol already specifies.  My patch combined this with an extension to XKB for bug 865, which might have not been a smart move...
Comment 10 Sergey V. Udaltsov 2013-01-14 23:19:12 UTC
Daniel, can the minimalistic solution be implemented? It would make using Private section unnecessary.
Comment 11 Zain 2014-08-03 12:19:12 UTC
im quite surprised that this bug has not been fixed yet it is still present in almost all the linux ? whats is going on ?
Comment 12 Sergey V. Udaltsov 2014-08-17 22:55:51 UTC
Daniel, any comments on that?
Comment 13 Andreas Wettstein 2014-08-18 14:03:08 UTC
There is an already reviewed patch that adds the missing support for nolock/nounlock to xkbcomp:
 
  http://patchwork.freedesktop.org/patch/20376/

Support for output (libxkbfile and xserver) is in these patches, which also have already been reviewed:

  http://patchwork.freedesktop.org/patch/203777/
  http://patchwork.freedesktop.org/patch/20380/

I hope these patchen can be merged.
Comment 14 S├ębastien Leblanc 2015-05-01 15:24:30 UTC
I disagree; this is not a bug, simply on the basis that keyboards inherit from traditional typewriters. The caps lock on a typewriter (at the time called a shift lock since it shifted all the keys, not just the letters) used to work on a toggle principle:

 - Starting from the disengaged state, typing will result in lowercase letters;
 - Pressing and holding the button engages the mechanism: at this point, typing will produce uppercase letters;
 - Releasing the button does not disengage the mechanism: uppercase letters are still rendered;
 - Pressing the button again does not disengage the mechanism, but you can feel or hear that the latch holding the mechanism has been removed: typing still produces uppercase letters;
 - Finally, releasing the button will disengage the mechanism: now the typewriter writes in lowercase letters.

The same behaviour can be observed with other devices such as mechanical power switches. If you have an older CRT monitor lying around, or a computer with an AT power supply, or a car with a mechanical defro you can try it out. When it is turned on, pressing and holding down the power switch will only produce a click, while the monitor will stay on. It will turn off when the switch is released.

I think the confusion stems from more popular operating systems having removed this logic, whether by choice or by omission.

In my opinion, whether the default behaviour should be changed is a question of taste; however having the option to select one versus the other is definitely desirable. I doubt this post will gain much traction, but if anyone is interested in discussing it, I would be glad to take it to the mailing list (please CC me).
Comment 15 Andreas Wettstein 2015-05-01 15:49:33 UTC
S├ębastien, thank you for the nice explanation why locks behave as they do.

> In my opinion, whether the default behaviour should be changed is a question of > taste; however having the option to select one versus the other is definitely 
> desirable.

The default definitely should not be changed.  The XKB specification specifies the behaviour of locks, so changing this would be a bug.  And my proposed workaround will not always behave intuitively.  In particular, it will only work for ALPHABETIC keys to which alphabetic characters are mapped.  It's not something for everybody.

Still, I think my workaround will be useful, and I hope that the patches mentioned in comment #13 will eventually be applied so that I can move on submitting a patch not using Private.
Comment 16 Daniel Stone 2015-05-01 15:51:57 UTC
I'm totally fine with Ran's review of these, and they should go in.
Comment 17 wordwhirl 2017-05-05 17:22:02 UTC
Any update on this? If this goes in using Ubuntu on Windows is gonna be a heck more fun. Right now it is frustrating that I cannot just change the "compat/caps" file to fix this issue :/

Please merge the patches.
Comment 18 Andreas Wettstein 2017-05-05 18:06:39 UTC
> Any update on this?

No update so far, sorry.  I really would be appreciate if the patches from comment #13 could be merged.  By the way, the second link (for libxkbfile) was wrong and should point to http://patchwork.freedesktop.org/patch/20377/.

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.