|Summary:||xkbcomp-1.2.4 breaks mouse events with non-english layouts|
|Product:||xorg||Reporter:||Maxim Koltsov <maksbotan>|
|Component:||App/xkbcomp||Assignee:||Xorg Project Team <xorg-team>|
|Status:||RESOLVED NOTABUG||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
|Bug Depends on:|
Description Maxim Koltsov 2012-06-02 04:59:52 UTC
With xkbcomp-1.2.4 awesome's panel does not recieve mouse events when russian layout is selected. xkbcomp-1.2.3 is ok. Other cases of breakage are reported too. Please take look at reports on Gentoo Bugzilla (https://bugs.gentoo.org/show_bug.cgi?id=415267) and Arch Linux bug tracker (https://bugs.archlinux.org/task/29123).
Comment 1 Marko Doda 2012-11-01 15:42:23 UTC
Created attachment 69395 [details] [review] compat patch
Comment 2 Marko Doda 2012-11-01 15:44:38 UTC
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)
Comment 3 anarcat 2012-11-24 16:50:56 UTC
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.
Comment 4 anarcat 2012-11-24 17:49:05 UTC
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.
Comment 5 anarcat 2012-11-24 18:31:15 UTC
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 <firstname.lastname@example.org> 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 <email@example.com> Reviewed-by: Daniel Stone <firstname.lastname@example.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...
Comment 6 Andreas Wettstein 2012-11-25 10:58:51 UTC
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).
Comment 7 Andreas Wettstein 2012-11-25 16:23:00 UTC
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.
Comment 8 Dmitry Klimov 2012-12-15 18:38:16 UTC
commit 1447071942dbbbfc37b08417c74c8a1d302c1626 broke stumpwm (which uses clx/xlib) too
Comment 9 Andreas Wettstein 2012-12-16 17:32:27 UTC
> 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).
Comment 10 Andreas Wettstein 2012-12-16 17:33:47 UTC
Sorry, the workaround is in comment #6, of course.
Comment 11 Dmitry Klimov 2013-03-27 08:36:46 UTC
Thanks, Andreas xkbcomp $DISPLAY - | egrep -v "group . = AltGr;" | xkbcomp - $DISPLAY helps
Comment 12 Andreas Wettstein 2013-04-12 18:11:04 UTC
Thank you, Dmitry. This confirms that xkbcomp works as it should, and the problem is with stumpwm/CLX.