Winit: KeyCode not sent for modified keys?

Created on 13 Jul 2018 · 9Comments · Source: rust-windowing/winit

Basically this is a question about "is this behavior intended?"

Using SDL2, when I press / then SDL sends a Slash keycode. Winit does the same. But if you press shift-/ (aka ?), SDL sends you the Slash keycode and Winit gives you the scancode but None for the keycode. Not sure what the "correct" approach is, so, is this intentional?

X11 needs investigation bug platform parity

Source

icefoxen

Most helpful comment

As a rule of thumb with X11, information is sparse and unverifiable. You have the API docs, but those aren't prescriptive, and often aren't helpful until after you understand the problem. You have StackOverflow questions, but those usually only get one answer, and nothing spectacular... so, I almost always end up rummaging through the source code of Xlib, GLFW, GTK, etc.

GLFW is usually the best place to look, since GTK is pretty labyrinthian. SDL is easy enough to follow too, though I usually only check there if GLFW lets me down... I haven't checked out Qt, but I imagine it's slightly cleaner (but bigger) than GTK. Qt supposedly contains the arcane secrets of how to unify KeyboardInput with ReceivedCharacter on Windows, but, that's only a rumor.

It looks like XLookupString actually isn't deprecated? XKeycodeToKeysym is though, but I guess that doesn't matter here. Using XLookupString seems like it was a hack in the first place, since it's not really intended for getting keysyms, I don't think.

If your travels take you to XKB, you've gone too far. While using XKB would modernize our X11 keyboard stack, it would be a project... it has no interoperability with Xlib's built-in XIM client, so we'd have to write our own XIM client. While a pure Rust XIM client would be quite sexy compared to Xlib's globally-stateful thread-unsafe deadlock-happy dumpster-fire client, it would be a major pain to make. libxkbcommon-x11 also isn't always installed, so it would have to be reimplemented too... it was a total bummer when I realized all of this (especially since it wasn't until after trial-and-erroring my way through switching winit to using XKB).

Since XInput2 and XKB go hand in hand, this means solutions involving XInput2 are also out, though there's no risk of you finding those! The full extent of XInput2's documentation is a few blogspot posts by the guy who designed it (I'm not joking).

francesca64 on 13 Jul 2018

👍2

All 9 comments

Which platforms?

francesca64 on 13 Jul 2018

Only looked at Linux+X11. Let me check Windows.

icefoxen on 13 Jul 2018

Ok, on Windows, it uses SDL2's behavior; shift-/ produces a Slash keycode.

It didn't occur to me that there would be platform-specific differences/bugs. XD Linux is using xorg 1.19.6 on Debian Buster. Unfortunately I can't check Wayland or MacOS.

icefoxen on 13 Jul 2018

Looks like macOS has the same behavior as SDL too. Wayland just uses libxkbcommon, so it probably works too, though I can check with Weston I think.

It didn't occur to me that there would be platform-specific differences/bugs. XD

Much of winit's development history was pretty disjointed (since most people only contribute to one platform) so things like this are still pretty common, despite my best efforts.

francesca64 on 13 Jul 2018

Well, I'll see if I can submit a PR then. Likely culprits appear to be around https://github.com/tomaka/winit/blob/master/src/platform/linux/x11/mod.rs#L579 or https://github.com/tomaka/winit/blob/master/src/platform/linux/x11/mod.rs#L1031 . keysym_to_element() seems to mostly just do what it should be doing, I need to dig through X docs (start at man xkeyevent?) to figure out the details of what's going on.

icefoxen on 13 Jul 2018

Well XLookupString is objectively terrible, or something like that (very deprecated). Since that's how we get the keysym, and we use the keysym to get the virtual keycode, that's an easy hole for problems.

The XI_Raw* stuff is for DeviceEvent, which use XInput2. If you want to know what that entails, well, I can tell you that too... XKeycodeToKeysym is probably deprecated too.

francesca64 on 13 Jul 2018

Well, okay then, that gives me some idea of how things are. Where should I start for non-objectively terrible X input documentation, if such a thing even exists? :-)

icefoxen on 13 Jul 2018