x11: Don't panic when using dead keys

[francesca64]

Fixes #366

I was originally planning to fix this by rewriting keyboard handling to use XInput2+XKB+libxkbcommon, and I do indeed have a fully functional implementation of that. However, I never managed to figure out how to handle IME, and I could seldom find the motivation to try to conquer yet another dimension of X11 eroticism. That only got worse when I discovered older libxkbcommon versions, which are still in use, don't support compose sequences. As a result, this fairly important issue has gone unresolved for much longer than I ever intended.

This PR fixes the issue using a bold new solution: a single if that checks if the keycode is non-zero. A KeyPress with a keycode of 0 is received at the end of compose sequences and pre-edit sequences, which has our desired UTF8 string associated with it. The panic was simply the result of trying to send a KeyboardInput event for this input, which involved trying to calculate a scancode for this nonexistent key. So, now we just don't try to send a KeyboardInput event in that case, and just like that, everything works.

I should note that the behavior of the X11 backend isn't consistent with the expectations laid out in #343. While I was able to easily achieve that behavior using XInput2, vanilla X11 seems less cooperative. For individual keys pressed during a compose/pre-edit sequence, X11 only generates KeyRelease events, so the user receives KeyboardInput events for key releases with no corresponding press events. In the case of compose, the ReceivedCharacter is sent to the user before the KeyboardInput for the release of the final key in the sequence. For pre-editing, a KeyboardInput for the release of the return key is sent after the ReceivedCharacter.

[b-r-u]

Thanks for wandering through the arcane landscape of X11 APIs!
Despite the drawbacks from your last paragraph, this looks like a really simple solution to the problem.

[Ralith]

However, I never managed to figure out how to handle IME

If it's any consolation, that's why I gave up on xkbcommon-ifying the main keyboard input code path myself. It may simply be impossible to support anything other than XCompose with that approach, which I imagine eastern users would be rather unsatisfied with. At this point I'm 100% approving of bodging X11 support into something approximately sane and focusing on Wayland for doing it Right™.

[tomaka]

Thanks. I guess it's better this kind of hack than things not working. Also needs a changelog entry.

[francesca64]

I wouldn't say this is a hack, since as far as I can tell, this is the correct way to implement this. As outlined here, the composed character is injected using a "fake" KeyPress with a keycode of 0, and all this PR does is prevent us from treating it like an ordinary KeyPress.

Anyway, I also solved the problems outlined in my last paragraph! The X11 backend now fully conforms to #343, thanks to some changes in how events are filtered.

[francesca64]

The event filtering hack unfortunately had to go. It resulted in backspace and arrow key inputs being doubled, so the original proviso once again applies.