Bug 50611

Created attachment 69395 [details] [review]
compat patch

I tried setting us and gb layouts, seems like the issue is with having a second layout, independent of the type of the layout, fixed it by apllying a patch from here https://bugs.archlinux.org/task/29123, but that patch isn't in upstream (last xkbcomp realase was in march)

Bug also filed at...

* Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=415267
* Awesome: https://awesome.naquadah.org/bugs/index.php?do=details&task_id=982
* Debian: http://bugs.debian.org/684605

Seems to me this should be dealt with already. I understand it's a bit of a corner case for english speakers, but for us non-english speakers (that is, 95% of the people on earth), it is really annoying.

So the patch that gets carried around? I couldn't make it work. While the test program provided in the Arch bug does change its output, it doesn't resolve the regression for me.

Disregard last commit, the patch is correct.

I have bisected the 1.2.3 and 1.2.4 releases and it seems that the commit that broke this is:

anarcat@marcos:xkbcomp$ git bisect good 5fd14db5b2cc0c2c43f7a1ddefd6f9991eb1dcc2
1447071942dbbbfc37b08417c74c8a1d302c1626 is the first bad commit
commit 1447071942dbbbfc37b08417c74c8a1d302c1626
Author: Andreas Wettstein <wettstein509@solnet.ch>
Date:   Fri Dec 2 20:10:06 2011 +0000

    include resets group compatibility modifiers #43091

    This change makes sure that include does not overwrite previous
    compatibility modifier settings when the included files does not
    explicitly specify them.

    Signed-off-by: Andreas Wettstein <wettstein509@solnet.ch>
    Reviewed-by: Daniel Stone <daniel@fooishbar.org>

:100644 100644 759535a38108cf88b5b97d69d7ce6de10d54796e 2b00142441c91fce7e1877681386c0aef7913d0f M      compat.c

That is pretty much the compat patch that is floating around. As mentionned about, this was done in order to fix another bug (#43091) so I am not sure how to deal with this...

I tried out the program x.c that provided in one of the links.  Indeed, when I click the mouse and the active layout is not the primary one, Mod5 is set in the state.

When I use xev instead, Mod5 it is not set.  Rather, the group modifier bit is set in the state.

My suspicion is that x.c (and awesome, for which the actual problem occurs) are not XKB-aware, and I hope someone knowledgeable in xcb can check this suspicion.

The reason of the patch that "breaks" xkbcomp is as follows: Clients that do not know about XKB do not know about the group bits in the state field, as those were only with XKB.  Before XKB, group switching was indicated by one of the Mod1-Mod5 modifiers.  Now, XKB offers the possibility to let the server signal a group switch by one of Mod1-Mod5 ("compatibility modifier") to clients that are not XKB-aware. The patch fixes a bug that prevented the specification of the compatibility modifier, so that it always remained empty, so Mod5 was not set.  In effect, this means that non-XKB aware clients could only one group with 2 levels.

The simplest workaround is to leave the compatibility modifier unset.  This is achieved by removing

    group 2 = AltGr;
    group 3 = AltGr;
    group 4 = AltGr;

in xkb/compat/basic (located under /usr/share/X11 or a similar place).

I used xscope to look at the traffic between the example program x.c and the server, and compared it to the traffic between xev and the server.  Clearly, x.c does not request X Keyboard extension.  "The X Keyboard Extension: Protocol Specification", section 16.3.1, states: "Until a client explicitly and successfully requests the XKB extension, an XKB capable server reports compatibility state in all core protocol events and requests."

Conclusion: The observed behaviour observed with x.c is in agreement with the specification.  If x.c properly models the behaviour of awesome, commit 1447071942dbbbfc37b08417c74c8a1d302c1626 just exposes a bug in awesome that went unnoticed thanks to the bug that this commit fixed.

commit 1447071942dbbbfc37b08417c74c8a1d302c1626 broke stumpwm (which uses clx/xlib) too

> commit 1447071942dbbbfc37b08417c74c8a1d302c1626 broke stumpwm (which uses clx/xlib) too

This is too broad a statement to draw conclusions from it.

I have been told that CLX does not support XKB, so I wonder, when you try the workaround suggested in comment #7, do whatever problems you might have encountered with stumpwm still persist?  (After the change to xkb/compat/basic, it should be sufficient to use setxkbmap to activate the change, but I recommend to restart the X server to be really sure).

Sorry, the workaround is in comment #6, of course.

Thanks, Andreas

xkbcomp $DISPLAY - | egrep -v "group . = AltGr;" | xkbcomp - $DISPLAY

helps

Thank you, Dmitry.  This confirms that xkbcomp works as it should, and the problem is with stumpwm/CLX.