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.