In Linux implementation some keys have the same codes as Numpad keys

[positiveway]

In the scan_code and other functions

0x47 => Some(HomeKey),
0x4b => Some(LeftKey),
0x4d => Some(RightKey),
0x48 => Some(UpKey),
0x50 => Some(DownKey),
0x52 => Some(InsertKey),
0x53 => Some(DeleteKey),

0x52 => Some(Numpad0Key),
0x50 => Some(Numpad2Key),
0x4b => Some(Numpad4Key),
0x4d => Some(Numpad6Key),
0x47 => Some(Numpad7Key),
0x48 => Some(Numpad8Key),

Gonna investigate further and create a PR

[positiveway]

This issue is a more detailed duplicate of #37 and #19 . I will leave it open for discussion. Because not only some keys are repeated but some crucial ones like Super are missing.

Seems like the author of #37 added some bindings in his fork. Gonna look into that.

[positiveway]

The solution was easy:
uinput is used for simulating events, it internally uses uinput-sys.
Here is the list of proper codes from that library

Replacing codes with proper ones indeed solves the issue.
Like 108 for DownKey instead of 80 (0x50)

@obv-mikhail will you be able to copy proper codes from that list? And maybe add some new useful ones. They are all listed in an easy-to-read format.

[positiveway]

@obv-mikhail does it make sense to continue using hexadecimal notation?
It would be simpler and easier to read/maintain if we replace all codes with decimal values from uinput-sys list.
Because that's where these codes come from anyways and they are organized neatly.

I think it would be more reliable not to copy specific values but to have a mapping like this in
inputs.rs

extern crate uinput_sys;
use uinput_sys::*;
...
pub fn key_to_scan_code(key: &KeybdKey) -> i32 {
    match key {
        LeftKey => KEY_LEFT,
        DownKey => KEY_DOWN,
        ...
    }
}

in Cargo.toml

[dependencies]
uinput = { version = "0.1.3", default-features = false }
uinput-sys = "*"

to always match uinput-sys version with what's used in uinput

[obv-mikhail]

@positiveway yes, the approach of using the consts from uinput-sys by name sounds good to me.