Bug 1303307
| Summary: | Awesome WM: Some key bindings (e.g. window close) sporadically stop to work for already open clients | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Martin Ueding <mu> |
| Component: | awesome | Assignee: | Thomas Moschny <thomas.moschny> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 23 | CC: | mu, thomas.moschny |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | awesome-3.5.8-1.fc23 awesome-3.5.8-1.fc22 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-02-04 23:23:04 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This problem also affects moving clients to the other screen with [Mod4]+[O]. The mouse problem is not cured by restarting Awesome WM, so this cannot directly be the same cause, I think. awesome-3.5.8-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5c4b725bf awesome-3.5.8-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-6e58ca0128 awesome-3.5.8-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5c4b725bf awesome-3.5.8-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5c4b725bf (In reply to Martin Ueding from comment #1) > This problem also affects moving clients to the other screen with [Mod4]+[O]. > > The mouse problem is not cured by restarting Awesome WM, so this cannot > directly be the same cause, I think. According to upstream, this is a different issue, see https://github.com/awesomeWM/awesome/issues/635 https://github.com/awesomeWM/awesome/issues/415 and https://bugreports.qt.io/browse/QTBUG-49952 If I read the Qt issue correctly, a fix will be in Qt 5.6.0. A workaround is to set QT_XCB_NO_XI2_MOUSE=1. awesome-3.5.8-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5c4b725bf awesome-3.5.8-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-6e58ca0128 awesome-3.5.8-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. awesome-3.5.8-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: I use Awesome WM as my windows manager. My configuration file (`rc.lua`) has been working just fine with a couple of tweaks. Since about yesterday the command for closing windows (killing clients) does not work in same cases. Usually this functionality is mapped to [Mod4]+[Shift]+[C], I have mapped it to [Mod4]+[C] in my configuration. So I would want to close some Konsole (KDE terminal) window and the text cursor there would just blink but the windows is not closed. This blinking suggests that the window looses focus for the duration of that keypress so I assume that Awesome WM still catches that key. Keybindings that move the window still work. The strange thing is that this does not apply to new clients. When I open a new Konsole window, I can close it just fine. All windows that were already open when this bug happened cannot be closed as well. Another thing that does not work any more is making a window the main window with [Mod4]+[Control]+[Space]. From that I would guess that *some* functions that are bound to each window get unmapped for some reason at some point. The way I currently deal with the issue is a plain restart of Awesome WM using [Mod4]+[Shift]+[R]. This takes less than a second and is a manageable workaround. However I would prefer for this to be resolved. I suspect that this was caused by an update to Awesome WM on Fri Jan 29 09:56:28 2016. I have automatic updates enabled (`dnf-automatic`) and this is the transaction I get with `dnf history info awesome`. Judging from the [package website][1] I guess that there was indeed an update that introduced this glitch. [1]: https://apps.fedoraproject.org/packages/awesome/ Version-Release number of selected component (if applicable): 3.5.7 How reproducible: It happens at undefined time intervals, but it has happened every now and then and it is annoying. Steps to Reproduce: 1. Open a couple windows 2. Work for a while 3. Note that closing a window does not work. Also note that making a window the main window does not work either. Actual results: Windows that were open before the glitch cannot be closed or made the main window. Expected results: Keybindings should do their job. Additional info: There has been a similar behavior in Awesome WM for a longer time which broke mouse bindings. So for some reason I could still perform all the commands with they keyboard but clicking on tags in the wibox did not have any effect. This must have been introduced in an earlier update but might be related as it (1) also occurs after some time of using the session and (2) is about the binding of functions to input events. The second screen on my display is rotated quite often, but I have not found that this rotation using `xrandr` has a strong correlation. Another soft correlation seems to be with suspend-to-ram. In both cases the window manager has to adjust to the new layout of the screens.