Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent virtual_keycode on macOS and OpenBSD #2032

Closed
afh opened this issue Oct 5, 2021 · 2 comments
Closed

Inconsistent virtual_keycode on macOS and OpenBSD #2032

afh opened this issue Oct 5, 2021 · 2 comments

Comments

@afh
Copy link
Contributor

afh commented Oct 5, 2021

While using alacritty on macOS and OpenBSD I notice a difference in the keybinding configuration, where some keybindings working on macOS are not working on OpenBSD.
The helpful folks in the #alacritty Libera.Chat channel pointed me to this repository and suggested that the issue that I run into might be related to a missing (platform) mapping in this repository, which alacritty uses as a dependency.

I modified the examples/resizable.rs in order to provide a Minimal Working Example (MWE) (see below).

Note that on OpenBSD I am using the us.swapctrlcaps keyboard layout, have assigned the physical Control left of the spacebar to Hyper_L using keycode 37 = Hyper_L in ~/.Xmodmap (this should not matter though as the tests below only use the Command key), and have swapped the left logo key with the left alt key in order to match macOS' layout where the left Command key is left of the space bar and the left Alt (Option) key is to the left of the left Command key resulting in: Alt Command Space

OpenBSD macOS
sw_vers -productVersion 11.6
uname -r 6.9 20.6.0
rustc --version 1.51.0 1.51.0

I've tested the MWE on both macOS and OpenBSD as follows:

  • Place the Cargo.toml and src/main.rs files (see below) in a separate directory for testing
  • Build and run the MWE: cargo build && ./target/debug/winit-key-test on macOS and OpenBSD
  • Press the keys as shown in the table below and compare the output of the MWE on macOS and OpenBSD
  • I would expect the following keycodes (also highlighted in bold in the MWE Keycode Comparison table below) to be the same across platforms:
Key(s) OpenBSD macOS
Shift + 8 Asterisk Key8
Command + Shift + 8 Asterisk Key8
Shift + [ None LBracket
Shift + ] None RBracket
Command + Shift + [ None LBracket
Command + Shift + ] None RBracket
Detailed MWE Keycode Comparison Between OpenBSD and macOS
Key(s) OpenBSD macOS
Command (Key left of the spacebar) scancode: 56, keycode: None, modifiers: LOGO scancode: 55, keycode: Some(LWin), modifiers: LOGO
Alt (Key left of Command) scancode: 107, keycode: Some(LAlt), modifiers: ALT scancode: 58, keycode: Some(LAlt), modifiers: ALT
Shift scancode: 42, keycode: Some(LShift), modifiers: SHIFT scancode: 56, keycode: Some(LShift), modifiers: SHIFT
8 scancode: 9, keycode: Some(Key8), modifiers: (empty) scancode: 28, keycode: Some(Key8), modifiers: (empty)
Shift + 8 scancode: 9, keycode: Some(Asterisk), modifiers: SHIFT scancode: 28, keycode: Some(Key8), modifiers: SHIFT
Command + Shift + 8 scancode: 9, keycode: Some(Asterisk), modifiers: SHIFT | LOGO scancode: 28, keycode: Some(Key8), modifiers: SHIFT | LOGO
[ scancode: 26, keycode: Some(LBracket), modifiers: (empty) scancode: 33, keycode: Some(LBracket), modifiers: (empty)
] scancode: 27, keycode: Some(LBracket), modifiers: (empty) scancode: 30, keycode: Some(LBracket), modifiers: (empty)
Shift + [ scancode: 26, keycode: None, modifiers: SHIFT scancode: 33, keycode: Some(LBracket), modifiers: SHIFT
Shift + ] scancode: 26, keycode: None, modifiers: SHIFT scancode: 30, keycode: Some(LBracket), modifiers: SHIFT
Command + Shift + [ scancode: 26, keycode: None, modifiers: SHIFT | LOGO scancode: 33, keycode: Some(LBracket), modifiers: SHIFT | LOGO
Command + Shift + ] scancode: 27, keycode: None, modifiers: SHIFT | LOGO scancode: 30, keycode: Some(LBracket), modifiers: SHIFT | LOGO

Minimal Working Example

Cargo.toml
[package]
name = "winit-key-test"
version = "0.1.0"
edition = "2018"

[dependencies]
winit = "0.25.0"
src/main.rs
// Adapted from examples/resizable.rs
use winit::{
    dpi::LogicalSize,
    event::{ElementState, Event, KeyboardInput, VirtualKeyCode, WindowEvent},
    event_loop::{ControlFlow, EventLoop},
    window::WindowBuilder,
};

fn main() {
    let event_loop = EventLoop::new();

    let mut resizable = false;

    let window = WindowBuilder::new()
        .with_title("Displaying KeyboardInput")
        .with_inner_size(LogicalSize::new(400.0, 200.0))
        .with_resizable(resizable)
        .build(&event_loop)
        .unwrap();

    event_loop.run(move |event, _, control_flow| {
        *control_flow = ControlFlow::Wait;

        match event {
            Event::WindowEvent { event, .. } => match event {
                WindowEvent::CloseRequested => *control_flow = ControlFlow::Exit,
                WindowEvent::KeyboardInput {
                    input, ..
                } => {
                    if input.state != ElementState::Pressed {
                        return;
                    }
                    println!("scancode: {scancode:>sw$}, keycode: {keycode:?}, modifiers: {modifiers:?}"
                             , scancode=input.scancode, sw=3
                             , keycode=input.virtual_keycode
                             , modifiers=input.modifiers);
                }
                _ => (),
            },
            _ => (),
        };
    });
}
@afh
Copy link
Contributor Author

afh commented Oct 6, 2021

Going through the list of existing issues it seems that this issue should probably be included in the Meta Issue: Keyboard input #1806 and is possibly related to No character getting received on international keyboard on macOS #1208.

kchibisov added a commit that referenced this issue May 28, 2023
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 <[email protected]>
Co-Authored-By: Kirill Chibisov <[email protected]>
Co-Authored-By: daxpedda <[email protected]>
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.
@afh
Copy link
Contributor Author

afh commented May 29, 2023

Thanks you so very much for addressing this! 🎉 I look forward to the next release of winit and update software (e.g. alacritty) using winit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants