Different Keyboard Layout Problem

[Tahinli]

Problem is my keyboard is Turkish and buttons are not correctly working. If change my layout to English UK, it works without any problem. So this problem can be caused in any other keyboard layouts which are different then English.

This layout should work properly but as i said because of keyboard layout, "equal" behave like minus and "dot" behave like "comma".

My idea about solution is. Keeping code in fixed layout even OS has different layout. Maybe we can use ASCII.

[iamkroot]

Looks like asus-numberpad-driver uses X11 APIs to query the actual keys-
https://github.com/asus-linux-drivers/asus-numberpad-driver/blob/fc78b5c06ca161d8d316a6b07b13445cc81a5369/asus_touchpad.py#L365-L392

We would need to do something similar to get this to work.

For a quick and dirty solution, you could clone this repo and edit the source code yourself (replacing the KPDOT value with the correct one for your layout).

[Tahinli]

Looks like asus-numberpad-driver uses X11 APIs to query the actual keys- https://github.com/asus-linux-drivers/asus-numberpad-driver/blob/fc78b5c06ca161d8d316a6b07b13445cc81a5369/asus_touchpad.py#L365-L392

We would need to do something similar to get this to work.

For a quick and dirty solution, you could clone this repo and edit the source code yourself (replacing the KPDOT value with the correct one for your layout).

i fixed "equal" with KEY_KPEQUAL, trying to find right dot :D.

Btw we can solve this problem with downloading "xdotool" and using with system calls.

Command::new("xdotool")
    .args(&["keydown", &format!("{}", ascii_code)])
    .spawn()
    .expect("Failed to execute xdotool");

Command::new("xdotool")
    .args(&["keyup", &format!("{}", ascii_code)])
    .spawn()
    .expect("Failed to execute xdotool");

like this. But most probably we can find some better solution.

[iamkroot]

trying to find right dot

You could probably get this by adding a print(key) after https://github.com/asus-linux-drivers/asus-numberpad-driver/blob/fc78b5c06ca161d8d316a6b07b13445cc81a5369/asus_touchpad.py#L377 to log the final key codes that get used.

[Tahinli]

Okay "KEY_SLASH" is "dot". It makes sense when we compare Turkish and English keyboard. Also if there is someone who want to find right key,

Install evtest
sudo evtest
select right device
{
In mine there were 2 keyboard. If I select 20 which is physical keyboard, it just prints all keys but if I select 2 which is, , Translated set, it captures and show what i press.

}

then change in code, you can find buttons in https://docs.rs/input-event-codes/latest/input_event_codes/index.html

[Tahinli]

trying to find right dot

You could probably get this by adding a print(key) after https://github.com/asus-linux-drivers/asus-numberpad-driver/blob/fc78b5c06ca161d8d316a6b07b13445cc81a5369/asus_touchpad.py#L377 to log the final key codes that get used.

also this solution makes sense.

[ldrahnik]

@Tahinli xdotool looks like the wrapper above functions that I use in the code mentioned by @iamkroot - anyway remember still it is X11 lib dependency so does not support distros with Wayland

[Tahinli]

@Tahinli xdotool looks like wrapper above functions what I use in code mentioned by @iamkroot - so it might be cleaner solution use it - but I have no exp - anyway remember still it is X11 lib dependency so does not support distros with Wayland I guess

It can be as you said. So in this situation, just need to find universal solution. I think it can be ascii, we just need to simulate button press with ascii codes.

[kamack38]

Just to add our recent findings at asus-numberpad-driver, I'd like to say that getting the correct keys is possible using libxkbcommon which has both Wayland and X11 bindings.