After upgrading to version x11-apps/xkbcomp-1.2.4 switching on Russian layout breaks handle events for click of the mouse on the panel of avesome window manager. Reverting to version x11-apps/xkbcomp-1.2.3 solves the problem. A similar bug occurred in ArchLinux Bugzilla — https://bugs.archlinux.org/task/29123#comment91576
I can confirm it, i have same problem with russian or hebrew layout
I can confirm this too.
It seems that this bug was not reported to upstream. Someone who experiences this issue needs to open a bug report on https://bugs.freedesktop.org/ or it won't be fixed.
I have reported it upstream: https://bugs.freedesktop.org/show_bug.cgi?id=50611
According to upstream, the bug is in awesome and not in xkbcomp.
See also: http://stackoverflow.com/questions/16246144/awesome-wm-ignores-input-in-non-us-layout https://bugs.archlinux.org/task/29123 https://awesome.naquadah.org/bugs/index.php?do=details&task_id=982 https://bugs.freedesktop.org/show_bug.cgi?id=50611 Maybe related upstream patch: http://git.naquadah.org/?p=awesome.git;a=commit;h=03759b48478eb716af8b62e01ef3b5140c582f58
(In reply to Pavel Šimerda from comment #6) > Maybe related upstream patch: > > http://git.naquadah.org/?p=awesome.git;a=commit; > h=03759b48478eb716af8b62e01ef3b5140c582f58 Unfortunately the patch doesn't apply to x11-wm/awesome 3.4.15.
(In reply to Pavel Šimerda (pavlix) from comment #8) > (In reply to Pavel Šimerda from comment #6) > > Maybe related upstream patch: > > > > http://git.naquadah.org/?p=awesome.git;a=commit; > > h=03759b48478eb716af8b62e01ef3b5140c582f58 > > Unfortunately the patch doesn't apply to x11-wm/awesome 3.4.15. I'm not sure if 3.4 branch is still being supported or not. I'd like to get gentoo moved up to 3.5.2-r1 soon. Can anyone replicate this issue against 3.5.x??
I wouldn't consider this bug a blocker anyway. However, judging by still following comments in awesome's Flyspray, the issue isn't fixed. You can try yourself: % setxkbmap -layout "us,ru" -option "grp:alt_shift_toggle" Then switch to russian layout with Alt-Shift (try it in text editor or something), test clicking on wiboxes, switch back by the same Alt-Shift, then drop it: % setxkbmap -layout "us" (s/us/<WHATEVER-LAYOUT-YOU-USE>) I'm not yet sure awesome 3.5 is ready for stable, though. With lgi 0.6.x it was quite slow, for example, and 0.7 is just a month and a bit in ~arch. Widget capabilities of 3.5 aren't quite on par with 3.4, too. All in all, I'm a bit sceptical about stable 3.5.x
(In reply to Nikolaj Sjujskij from comment #10) > I wouldn't consider this bug a blocker anyway. Yes, it just breaks the keyboard and mouse until the user switches layout back to the default one. Nothing serious ;). (In reply to Bombino from comment #9) > I'm not sure if 3.4 branch is still being supported or not. Apparantly it's considered a Gentoo stable branch and would be nice to fix. Let me know if you need help with that. > I'd like to get gentoo moved up to 3.5.2-r1 soon. Looking at Nikolaj's view on 3.5.2, I'm curious about the actual meaning of 'soon', here.
(In reply to Pavel Šimerda (pavlix) from comment #11) > (In reply to Nikolaj Sjujskij from comment #10) > > I wouldn't consider this bug a blocker anyway. > Yes, it just breaks the keyboard and mouse until the user switches layout > back to the default one. Nothing serious ;). But it breaks 3.4 as well as 3.5, so isn't a regression -> not blocker of 3.5 going stable. I can't try it out at the moment, but as far as I remember, keyboard isn't blocked. > (In reply to Bombino from comment #9) > > I'm not sure if 3.4 branch is still being supported or not. > Apparantly it's considered a Gentoo stable branch and would be nice to fix. > Let me know if you need help with that. Fixing that in 3.4 would be nice indeed. > > I'd like to get gentoo moved up to 3.5.2-r1 soon. > Looking at Nikolaj's view on 3.5.2, I'm curious about the actual meaning of > 'soon', here. Well, I don't think we should rush this. Installing 3.5 on stable system is just a matter of unmasking awesome and one dependency (I wonder how lgi maintainer feels about stabilizing it) if user so desires. But if we stabilize it, then stable users will upgrade to version which is hungry for CPU (if it isn't fixed in lgi 0.7) and requires cairo magic to do simple 3.4 stuff: https://bitbucket.org/skrattaren/awesome/commits/7815e038a95d9f7872375e63eed4fe6ece41d42a https://bitbucket.org/skrattaren/awesome/commits/bbb68b2ecbcdb74ff290e7924dc7399690d43670 I for one don't consider it a good user expirience (-:E
Hi all. I'm seeing this assigned to me, so I'll post an update. The issue is still not fixed, see upstream bug report https://github.com/awesomeWM/awesome/issues/196 The fix is promised for awesome-3.6 release, but its date is still not set. As for now, users can use 9999 or try the workaround described in https://bugs.freedesktop.org/show_bug.cgi?id=50611#c6
Dropping x11@ from cc, since the conclusion of $URL is "This confirms that xkbcomp works as it should, and the problem is with stumpwm/CLX."
Awesome-4 does not have this issue and Awesome-3.5 is soon to be removed from the tree. Closing this bug.
