KeyCode not sent for modified keys? #600
Comments
|
Which platforms? |
francesca64
added
F - question
|
Only looked at Linux+X11. Let me check Windows. |
|
Ok, on Windows, it uses SDL2's behavior; 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. |
|
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.
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
added
B - bug
|
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 . |
|
Well The |
|
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? :-) |
|
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 It looks like 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). |
|
This issue appears to be related to the following issues in projects which depend on winit: rust-windowing/glutin#979 On the winit side, this appears related to: |
Overhaul the keyboard API in winit to mimic the W3C specification
to achieve better crossplatform parity. The `KeyboardInput` event
is now uses `KeyEvent` which consists of:
- `physical_key` - a cross platform way to refer to scancodes;
- `logical_key` - keysym value, which shows your key respecting the
layout;
- `text` - the text produced by this keypress;
- `location` - the location of the key on the keyboard;
- `repeat` - whether the key was produced by the repeat.
And also a `platform_specific` field which encapsulates extra
information on desktop platforms, like key without modifiers
and text with all modifiers.
The `Modifiers` were also slightly reworked as in, the information
whether the left or right modifier is pressed is now also exposed
on platforms where it could be queried reliably. The support was
also added for the web and orbital platforms finishing the API
change.
This change made the `OptionAsAlt` API on macOS redundant thus it
was removed all together.
Co-Authored-By: Artúr Kovács <kovacs.artur.barnabas@gmail.com>
Co-Authored-By: Kirill Chibisov <contact@kchibisov.com>
Co-Authored-By: daxpedda <daxpedda@gmail.com>
Fixes: #2631.
Fixes: #2055.
Fixes: #2032.
Fixes: #1904.
Fixes: #1810.
Fixes: #1700.
Fixes: #1443.
Fixes: #1343.
Fixes: #1208.
Fixes: #1151.
Fixes: #812.
Fixes: #600.
Fixes: #361.
Fixes: #343.
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 pressshift-/(aka?), SDL sends you theSlashkeycode and Winit gives you the scancode butNonefor the keycode. Not sure what the "correct" approach is, so, is this intentional?The text was updated successfully, but these errors were encountered: