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?

If there's an xkbcomp patch to be applied, link it here and I'll happily apply it and make a release.

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.

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

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.

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.

I think it is a bad idea to introduce Private section here. Could you pls give reference to the bug against xkbcomp?

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

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

Daniel, can the minimalistic solution be implemented? It would make using Private section unnecessary.

im quite surprised that this bug has not been fixed yet it is still present in almost all the linux ? whats is going on ?

Daniel, any comments on that?

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.

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

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.

I'm totally fine with Ran's review of these, and they should go in.

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.

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

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/312.