awesome

Welcome to awesome bug tracking system.
Tasklist

FS#982 - Mouse events under non-English keyboard layout

Attached to Project: awesome
Opened by Roman Kosenko (kite) - Monday, 26 March 2012, 12:38 GMT
Task Type Bug Report
Category Core
Status Unconfirmed
Assigned To No-one
Operating System Linux
Severity Medium
Priority Normal
Reported Version git/3.4
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 20
Private No

Details

After recent updates of ArchLinux (that include some xorg-* packages and a bit early lua and xcb) awesome WM became ignore all mouse clicks on wiboxes (that are mapped using awful.button) when I change keyboard layout to some non-English one. Keyboard bindings (awful.key(...)) work fine at the same time. Have anybody noticed such behavior?
This task depends upon

Comment by Roman Kosenko (kite) - Monday, 26 March 2012, 13:19 GMT
I understand the reason - that's because (ev->state == 132) for such events. Why?
Comment by Uli Schlachter (psychon) - Monday, 26 March 2012, 13:32 GMT
132 is 128 + 4 is XCB_MOD_MASK_5 + XCB_MOD_MASK_CONTROL. According to that you are pressing modifier 5 and ctrl. The default config wants the key events to be without any modifiers. However, that doesn't explain what arch did to break your keyboard layout.
Comment by Roman Kosenko (kite) - Monday, 26 March 2012, 13:50 GMT
I know that this is XCB_MOD_MASK_5 | XCB_MOD_MASK_CONTROL. But I doesn't press Control. And my keyboard layout is not broken - all other applications work fine. If I use xev (that use xcb through xlib) to see keycodes, there are no ControlMask or Mod5Mask in state mask.
Comment by Uli Schlachter (psychon) - Monday, 26 March 2012, 13:52 GMT
How did you get that info from awesome? gdb?
And what does awesome do differently that makes it deserve wrong events? :-/
Comment by Roman Kosenko (kite) - Monday, 26 March 2012, 14:09 GMT
> How did you get that info from awesome? gdb?
No, insert printf in event_button_match() and compile as release.

xlib event state for left button in english layout: 0x100 == Button1Mask
xlib event state for left button in russian layout: 0x2100 == Button1Mask | (1<<13)
I didn't find any mention of (1<<13) for result event in X.h
May this superfluous bit influence and is misinterpreted?
Comment by Uli Schlachter (psychon) - Monday, 26 March 2012, 14:15 GMT
0x2100 would mean that button 1 and button 6 are pressed. The protocol only allows 5 mouse buttons, but where possible the server inserts foo for higher mouse buttons, too.

However, in event.c awesome does:

/* ev->state is
* button status (8 bits) + modifiers status (8 bits)
* we don't care for button status that we get, especially on release, so
* drop them */
ev->state &= 0x00ff;

So those high bits shouldn't influence any mouse button bindings...?
Comment by Roman Kosenko (kite) - Monday, 26 March 2012, 14:52 GMT
If xcb event is so wrong, how xlib can almost rightly interpret it?
Comment by Roman Kosenko (kite) - Monday, 26 March 2012, 16:17 GMT
I found that this is occurs after updating xorg-xkbcomp 1.2.3->1.2.4.
Bit XCB_MOD_MASK_CONTROL occurs in case when in xorg.conf there is Option "XkbOptions" "ctrl:nocaps,grp:lctrl_toggle"
But how xlib understand this and doesn't set ControlMask, Mod5Mask?
Comment by Damjan (gdamjan) - Tuesday, 03 April 2012, 21:25 GMT
Having the same problem, also on Arch but...

I just noticed another change that might help in figuring this out.

Previously in the run prompt (mod4-r) when I typed with my cyrillic (mk) layout nothing would show up.

Now, I get some strange characters (they look as they are from latin1 but have no idea on the layout).
Comment by Roman Kosenko (kite) - Tuesday, 03 April 2012, 21:56 GMT
I have posted bugreport to Arch - https://bugs.archlinux.org/task/29123
You can use patch from there to fix this issue.
Comment by Uli Schlachter (psychon) - Friday, 06 April 2012, 10:01 GMT
So does that mean this is a bug in xkbcomp and not in awesome?
Comment by Nikolaj Sjujskij (krigstask) - Wednesday, 11 April 2012, 16:27 GMT
The same in Gentoo Linux, by the way.
Comment by Uli Schlachter (psychon) - Wednesday, 11 April 2012, 16:29 GMT
So does the patch from arch work on gentoo then?
Comment by Alexander Yakushev (Alex.yakushev) - Friday, 13 April 2012, 11:42 GMT
I confirm that the downgrading to xorg-xkbcomp to 1.2.3 fixes the issue in Arch Linux.
Comment by Roman Kosenko (kite) - Sunday, 15 April 2012, 14:25 GMT
> So does that mean this is a bug in xkbcomp and not in awesome?
It seems so... But other applications work fine - awesome is one of a few applications that directly use xcb. Xlib uses xcb in some other way and there are no problems.
Comment by Ladislav Laska (Krakonos) - Tuesday, 05 June 2012, 08:54 GMT
Hello,

I've just tried the patch from arch bug on Gentoo, against xkbcomp 1.2.4. It seems to work fine, I'll report if something goes wrong.

Also, here are some other bugs tracking this issue:
https://bugs.gentoo.org/show_bug.cgi?id=415267
https://bugs.freedesktop.org/show_bug.cgi?id=50611
Comment by Alexander Yakushev (Alex.yakushev) - Tuesday, 27 November 2012, 16:16 GMT
This bug magically disappeared for me at some point. I guess something in X itself was changed because xorg-xkbcomp is still at its old version.

Anyways, I guess we can close this now; but just to be sure let someone report this issue to be solved as well.
Comment by Damjan (gdamjan) - Tuesday, 27 November 2012, 16:19 GMT
When did it disappear?
As recently as 2 weeks ago we had to recompile xorg-xkbcomp with a patch in order to fix this issue. On Archlinux.
Comment by Alexander Yakushev (Alex.yakushev) - Tuesday, 27 November 2012, 16:50 GMT
Not sure, I just tried it now and it worked.
Comment by Roman Kosenko (kite) - Tuesday, 27 November 2012, 18:11 GMT
Alexander Yakushev, what distro do you use?
Comment by Alexander Yakushev (Alex.yakushev) - Tuesday, 27 November 2012, 18:48 GMT
Arch Linux as well.
Comment by Alexander Yakushev (Alex.yakushev) - Wednesday, 28 November 2012, 16:58 GMT
I guess I should provide more info about my setup. So:
* Arch Linux, kernel 3.5.6-1-ARCH
* Awesome from git, built today
* xorg-server 1.13.0-4
* xorg-xkbcomp 1.2.4-1

I don't know what else might matter, but recently I switched to systemd. Could it be the case?
Comment by Nikolaj Sjujskij (krigstask) - Sunday, 12 May 2013, 12:06 GMT
Bug persists in Gentoo, and Xorg guys conclude that bug lurks in awesome: https://bugs.freedesktop.org/show_bug.cgi?id=50611#c7
Comment by Boris Petrov (Alien282) - Monday, 23 September 2013, 11:46 GMT
I'm on Arch Linux too. This was fixed for me in the version before 3.5.0, then 3.5.0 broke it again and it's still an issue on 3.5.1. It's definitely really annoying so please fix it! :)
Comment by Andrew (GriwMF) - Tuesday, 01 October 2013, 08:32 GMT
Have same issue on arch. really annoying indeed
Comment by Panos M. (pmav99) - Tuesday, 08 October 2013, 13:13 GMT
I confirm this too on Archlinux.

$ awesome -v
awesome v3.5.1 (Ruby Tuesday)
• Build: Sep 25 2013 21:15:32 for x86_64 by gcc version 4.8.1 (nobody@)
• Compiled against Lua 5.2.2 (running with Lua 5.2)
• D-Bus support: ✔

If you need help on debugging/reproducing please tell us what you need.
Comment by Panos M. (pmav99) - Saturday, 12 October 2013, 22:41 GMT
Just tried the workaround proposed here and it seems to work fine.
https://bugs.freedesktop.org/show_bug.cgi?id=50611#c6
Comment by Boris Petrov (Alien282) - Monday, 14 October 2013, 10:05 GMT
Yep, I can confirm this fixes the issue in my case too, but this seems like a "hack" (not that I understand what this "fix" does). As I said, the version of awesome before 3.5.0 fixed it without requiring such changes to X11 files, so I guess the problem is elsewhere... :)
Comment by Uli Schlachter (psychon) - Monday, 14 October 2013, 13:48 GMT
Are you really sure that this does not affect 3.4? Did you try 3.5, noticed that things were broken, then restarted into 3.4 and everything worked?

(Answering "but it used to work a year ago when I was using 3.4" doesn't count. The xkbcomp change could be newer than that)
Comment by Boris Petrov (Alien282) - Monday, 14 October 2013, 14:25 GMT
I'm just sure that it was broken since I started using awesome until the last version before 3.5.0 (which was 3.4.something) where it suddenly started working. After that 3.5.0 came and it broke again. So that particular version was the only one where this worked fine. I'm really not sure whether it has anything to do with anything else, sorry.
Comment by Nikolaj Sjujskij (krigstask) - Monday, 14 October 2013, 14:30 GMT
Not upgrading xkbcomp lets me not to expirience this issue with 3.5.* just like with 3.4.
Comment by J. Stamp (Yu-Yu) - Thursday, 28 November 2013, 21:52 GMT
Affects me also.

Ubuntu 13.10, x86_32, reproduced transparently as filed in this bug.

$ awesome --version

awesome v3.4.15 (Never Gonna Give You Up)
• Build: Apr 28 2013 18:50:10 for i686 by gcc version 4.8.0 (buildd@komainu)
• D-Bus support: ✔

xkbcomp 1.2.4
Comment by J. Stamp (Yu-Yu) - Thursday, 28 November 2013, 21:54 GMT
Looks like actually it's all about xkbcomp.
Comment by Alexander Yakushev (Alex.yakushev) - Saturday, 07 December 2013, 14:56 GMT
At some point the bug appeared again, and I fixed it by following the link provided by Panos M.: https://bugs.freedesktop.org/show_bug.cgi?id=50611#c6
Comment by Uli Schlachter (psychon) - Sunday, 05 January 2014, 12:35 GMT
Not a fix, but a work around:

Edit /usr/share/awesome/lib/awful/key.lua and button.lua. Change this line

local ignore_modifiers = { "Lock", "Mod2" }

into this:

local ignore_modifiers = { "Lock", "Mod2", "Ctrl", "Mod5" }

("Ctrl" and "Mod5" come from the first and second comment to this bug)
(Please note that completely ignoring the Ctrl key sounds like a stupid idea...)
Comment by umod.47 (umod.47) - Wednesday, 05 February 2014, 11:24 GMT
The problem exists. The best solution for now is the link, provided by Alexander Yakushev (Alex.yakushev):

>> At some point the bug appeared again, and I fixed it by following the link provided by Panos M.: https://bugs.freedesktop.org/show_bug.cgi?id=50611#c6

But after every system update I have to fix this file again, as long as update rewrites it back.
Comment by umod.47 (umod.47) - Thursday, 06 February 2014, 10:47 GMT
The problem exists. The best solution for now is the link, provided by Alexander Yakushev (Alex.yakushev):

>> At some point the bug appeared again, and I fixed it by following the link provided by Panos M.: https://bugs.freedesktop.org/show_bug.cgi?id=50611#c6

But after every system update I have to fix this file again, as long as update rewrites it back.

Loading...